lua-users home
lua-l archive

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


What Ross said, but also check what actual DLLs have been loaded once your application starts with PROCEXP.

If your application starts and crashes (and no dialog appears) that would be hard, but if there such dialog, run SysInternals ProcExp, then press Ctrl+D - and see the list of the DLLS.

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).

Or you can try running with F7 in Dependency Walker and see where it might crash (a better free debugger would be WinDBG - it takes some time
to get used to, but it's more powerfull than MSVC's one, and free).

Cheers!

On 9/8/11 12:16 AM, Ross Berteig wrote:
At 12:13 PM 9/7/2011, Oskar Forsslund wrote:
ok, thats a relief then i guess =)

so if i want it to work should i try and rebuild the libraries i need
somehow or am I up the creek without a paddle?

Use Dependency Walker [1] to verify the implicit requirements of every
library you are including in your project that you do not build
yourself. The best practice is to make certain that every DLL and your
EXE depend on the same C runtime version, and where appropriate, the
same Lua VM (e.g. LUA51.DLL).

[1]: See http://www.dependencywalker.com/ for the latest build, an
earlier build is usually included with the distribution of Visual Studio.

You will almost certainly have trouble if you mix CRT versions. Linking
the Lua VM more than once is even more likely to cause trouble. (I would
say "certain to cause trouble" except that it is technically possible to
contrive cases where it works to have multiple CRT versions and/or
multiple Lua VMs. It requires more care and effort than is typical so
don't try it unless you know what you are doing.)

I've usually integrated a scripted run of Dependency Walker into my
release process, where I skim its log file for a run of my program to
verify that all loaded DLLs are either part of a system distribution or
are part of my release, and that none of them are the non-shipping debug
builds of the CRT. That has saved me from embarrassment on several
occasions.

The Lua for Windows distribution is handy because every binary is built
against a common Lua VM DLL and based on the same CRT version.
Unfortunately, that CRT version is no longer the current Visual Studio
release, and there are rumblings of a plan to change Lua for Windows to
use MinGW instead of VS2005 real soon now.

If you are building a product in VS2010 and need to include libraries
that are shipped with LfW, my recommendation would be to build those
libraries and Lua itself with VS2010. If you run into trouble building a
specific library, then this list is usually quick to provide good advice.

Ross Berteig Ross@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/