lua-users home
lua-l archive

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


Here is my knowledge on the subject:

It's fine for a DLL to statically link to the CRT library (e.g. contain it in itself), but lots of precaution has to be taken.

A handle of file opened with fopen(), and even open() can't be handed over a different DLL or the EXE as it's running with it's own copy of the runtime library.

The same would be the case even if you have linked to MSVCR100.DLL, but the executable or some other DLL links to say MSVCR71.DLL (This happens a lot with plugins, and 3rd party libs - like perforce for example).

So if you isolate yourself to use only KERNEL functions (CreateFile, instead of fopen) you would be fine.

That's not all though (file handles) - there are more cases where it's problematic.

Actually that is the reason, why I went through the pains of making sure that every DLL that I link is linked to MSVCRT.DLL that is shipped with the System since XP (though it's not the same MSVCRT.DLL).

The "pain" is to the use Windows WDK, and link with msvcrt_2003.obj:

E:\apps\wdk>call dir msvcrt_*.obj /s/b
E:\apps\wdk\lib\win7\amd64\msvcrt_win2003.obj
E:\apps\wdk\lib\win7\i386\msvcrt_win2000.obj
E:\apps\wdk\lib\win7\i386\msvcrt_win2003.obj
E:\apps\wdk\lib\win7\i386\msvcrt_winxp.obj
E:\apps\wdk\lib\win7\ia64\msvcrt_win2003.obj
E:\apps\wdk\lib\wlh\amd64\msvcrt_win2003.obj
E:\apps\wdk\lib\wlh\i386\msvcrt_win2000.obj
E:\apps\wdk\lib\wlh\i386\msvcrt_win2003.obj
E:\apps\wdk\lib\wlh\i386\msvcrt_winxp.obj
E:\apps\wdk\lib\wlh\ia64\msvcrt_win2003.obj
E:\apps\wdk\lib\wnet\amd64\msvcrt_win2003.obj
E:\apps\wdk\lib\wnet\i386\msvcrt_win2003.obj
E:\apps\wdk\lib\wnet\ia64\msvcrt_win2003.obj
E:\apps\wdk\lib\wxp\i386\msvcrt_winxp.obj

and then more mumbo, jumbo and various tricks. Some stuff is not implemented correctly in Windows XP Service Pack 3. it's MSVCRT.DLL is not the same as Vista, or Windows 7. Sometimes the import.lib for MSVCRT.DLL does not have it all, and needs to be extended.

For a project that goes with that effort, look at XCHAT-WDK:
http://code.google.com/p/xchat-wdk/

I got inspired by it, and made my UFO bindings the same way:
https://github.com/malkia/ufo/tree/master/build/Windows

The ugly batch files are there, especially wdk/setup.cmd

I did it all, because:

1. I wanted each DLL to be able to cooperate with each other, through common runtime library, and this includes the main luajit executable. 2. I had to settle on which CRT that would be. And there is MSVCR71, MSVCR80, MSVCR90, MSVCR100 - I hate this crap. If I settle on one, it still not going to be good enough for others to cooperate. Worse then, I had to force people to install the Runtime version before using my stuff. 3. Hence, I installed WDK, and SDK (they can work together), and did some tricks to link to WDK, so it runs on XP (Service Pack 3) and above. 4. There are some hacks to be done, I had to lie to luajit that it MSC_VER is 1399, so that no 64-bit IO operations are done (XP MSVCRT.DLL does not correctly support 64-bit offsets - there are some tricks (posted here) - but not enough). I feel that for the time being, limiting to 32-bit offsets is fine. 5. I also like linking to MSVCRT.DLL rather than the newer style MSCRxx - as it does not invovle WinSxS - Windows Side By Side crap. I hate manifests, because I don't think they solve the problem.

Also this should be easier to cooperate with MINGW, which also uses MSVCRT.DLL (but haven't tried it fully). I can't provide DLL for every library out there, and especially for Gnome - there are already couple of places providing such DLL's (32-bit, 64-bit) - OpenSUSE Factory, Gnome itself, and others. I can reuse those, and hope that MINGW + MSVC would work together (mainly "C" code, so no exceptions, same MSVCRT, just few libs internally written in C++ - libzmq/libxs and AntTweakBar).


On 4/19/2012 10:35 AM, steve donovan wrote:
On Thu, Apr 19, 2012 at 7:24 PM, Mike Pall<mikelu-1204@mike.de>  wrote:
But ... you realize, you won't be able to load any C modules
anymore? Because they'll need to link to the DLL and AFAIK that
doesn't mix well with an embedded static copy of the library.

I recall that it's possible for a C module to link against a Windows
executable (e.g. for use by an application with embedded Lua like
SciTE). Could this not be a solution?

steve d.