RE: [ANNOUNCE] Lua 5.0 (pre-release) now available

["Brett Kapilik" <brett@...>]

> > > Some platforms may not allow loaded objects to reference 
> symbols in the 
> > > main program at all; I think AIX is or was such a platform.
> > 
> > As is Windows.
> 
> I am not a Windows expert, but as far as I know, this is not 
> completely
> true. In Linux (and I guess all Unix) there is no problem if a program
> uses multiple copies of the same code; equal code means equal results.
> So, there is no difference whether a loaded object shares the Lua code
> from the main program or loads its own copy.
> 
> In Windows, blocks created by a dll cannot be free in a different dll
> (is that right?), even if both dlls contain exactly the same code.

I have recently dealt with this issue on Windows.  What you say is true if the c run-time is linked statically.  If the c run-time library is linked dynamically by ALL modules that share the code, I believe it is possible to create memory in one module and free it in another because the c run-time library will properly manage a single heap across the modules.

We ran into this problem with our MFC app that statically links to the MFC libraries and therefore statically to the c run-time library.  We then wanted to be able to use loadmodule.c to extend Lua in our app but because of the way malloc and free work, when the c run-time library is statically linked, we were getting memory access crashes.

We resolved this problem by tweaking lmem.c to use HeapAlloc(), HeapReAlloc() and HeapFree() (from Windows.h).  Using these functions forces the modules to all use a commonly accessible heap.  The down-side is that extension DLLs must be statically linked with our modified version of the Lua engine.  So, our product will not be able to be extended with generic extension libaries (like the SQL and sockets ones) without modifiying and re-compiling them.  But we can live with this since we will just provide an SDK to our users that includes our modified version of the Lua engine.

Unless, of course, the Lua authors consider using the HeapAlloc memory functions when compiled for Windows.  I don't know if this would cause other problems or not.  I imagine that HeapAlloc is a bit slower than malloc, but I am not sure.  This addition to Lua shoudl be seriously considered, IMHO, if one goal of it is to be able to be extended with DLLs more and more as time goes on (such as in the LuaCheia project).

> So, to avoid problems in Windows, the "correct" way to use loaded
> objects is to make Lua itself a dll loaded by the main program,
> so that the main program, Lua, and any extra module all share a single
> copy of Lua.

I don't think that this is neccesarily true.  I think even with a DLL version of Lua, all involved modules would still have to dynamically link to the c run-time library.  If someone knows otherwise, I would be overjoyed to hear about it. :)

BTW, the Lua 5.0 pre-release version compiles beautifully on Visual C++ 6.0 (SP3) on Windows 2000.

Regards,

Brett Kapilik