lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

well I've gotten so far as to knowing that lua uses the MSVCR100.DLL and my application uses the D3DX9D_41.DLL wich in turn uses MSVCRT.DLL. I'm assuming this could lead to errors, especially when using require. Is that correct?

How do i make either of them use the other's .dll instead?

On Thu, Sep 8, 2011 at 11:52 PM, Ross Berteig <> wrote:
At 11:25 PM 9/7/2011, malkia wrote:
>What Ross said, but also check what actual DLLs have been loaded
>once your application starts with PROCEXP....

There's no question that Process Explorer should be on any
Windows developer's machine. Developers should also be aware of
the other SysInternals utilities. Most answer questions that are
difficult or impossible to answer without the utility. For
answering detailed questions related to files, the registry, and
related Windows API calls, SysInternal Process Monitor is
invaluable, for example.

Find all the SysInternals tools at [1].



>Also sometimes DependancyWalker cannot display the actual DLL
>loaded (side by side assemblies) - there can be the same
>MSVCR90.DLL but from different assembly (different version of the
>same runtime)....

For an application that loads DLLs at runtime (as with the
require() function in Lua) then the static analysis that
DependencyWalker starts with won't get the whole story. In some
cases, especially with SxS assemblies, the static analysis will
even name the wrong DLL entirely.

DependencyWalker is a lot more reliable if you use its Profile
feature to run the application while it monitors all DLL loads.
In that case, it will discover the actual file name of even SxS
assembly DLLs.

When I've integrated it in a build process, I've used command
line options to have DEPENDS.EXE launch my application, monitor
all DLL loads, and produce a log file. A script then
post-processes the log file to validate that only "expected" DLLs
are referenced, and to verify that all Lua modules and the DLLs
they depend on are included in the shipment.

A typical command looks like:

DEPENDS.EXE /c /a:0 /f:1 /u:1 /pa:0 /ps:1 /pf:1 /sm:2
  /pd:C:\Path\To\Project\Build\ship /pb
  C:\Path\To\Project\Build\ship\lua.exe shipcheck-3960-lua.tmp

where lua.exe would be your application that hosts Lua and can
run an arbitrary lua script when invoked from the command line. I
have a utility that writes the lua script to execute based on the
list of known lua modules that my application will require. The
script largely consists of a long list of require() calls
followed by a call to print() so that there's evidence in the log
file that it actually ran.

The command line options to DEPENDS are documented at [2]. The
key options here are /c which causes it to remain a command line
program and never show a GUI, /ot which names the log file to
write, /f:1 and /pf:1 which force all file names to be fully
qualified in the output, /pd which names the current directory of
the profiled process, and /pb which causes it to load the named
application and run it under the profiler.

The log file will show all the DLLs loaded along with full path
names. It is straightforward to parse the log and validate that
every DLL either comes from a system source, or is part of the
shipment package. I do that check with a utility that writes a
report file and lets make know whether the build is ok or not
through its exit status.

Ross Berteig                     
Cheshire Engineering Corp.