Re: [LuaJIT] Building with the Windows SDK

[Dimiter 'malkia' Stanev <malkia@...>]

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.