[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: dynamic x static (win32)
- From: Asko Kauppi <asko.kauppi@...>
- Date: Tue, 7 Dec 2004 11:15:24 +0200
Sure, why not, thanks for asking..
First of all, although LuaX is the only implementation that follows
this scheme, the concept itself had been discussed and introduced
before. Since it's some extra work "under the hood", I think no-one
else had gone through the trouble of actually doing it. For the average
user, the complexities are completely hidden.
So.. it works with a C function table. Any vital Lua features are
exposed (by the main app) via such table, and addon dll's are linked to
this table. In practise, the host loads in a dll, passes it the pointer
to the function table, and the dll is able to use it in order to
connect to the Lua engine.
In practise, this means extension modules are completely unaware of the
underlying Lua engine's version and other details. In fact, they can be
compiled without having the Lua sources around. Only the host deals
with Lua directly.
In addition to making things easier on the Win32/CE platforms (the
original issue of this thread) this same mechanism could basically be
used to provide for language independent extension modules (use the
same .dll in Python, Ruby, too?). Currently, this has not been done and
some Lua-isms are visible in the function table interface, but.. it
_could_ be done. What this also means, is that people won't be so
totally tied to having Lua as their language (you know, in 10+ years,
things might change? :)
Well.. before I get carried away.. This linkage system is the thing
called GluaX, and is actually only a few source files within the LuaX
implementation (gluax.h, gluax.c, gluahost.c). Anyone can use it with
or without LuaX, and the license is Zlib (Lua4 license).
Gluax linkage has been used with both Lua 4 and Lua 5, but I'm no
longer actively testing against 4. It should work, though, and the same
modules will run without recompilation.
One last thing.. Since there's no direct connection from the modules to
the Lua engine, the C/Lua API has been redesigned (for the better,
imho). It uses C macros s.a. 'glua_getInteger()' and 'glua_pushTable()'
of which you can read more in the gluax documentation:
Thanks for reading, and having interest in this way of seeing things..
7.12.2004 kello 04:28, David Burgess kirjoitti:
Would you like to elaborate on how this is achieved?
On Tue, 7 Dec 2004 00:19:30 +0200, Asko Kauppi <firstname.lastname@example.org>
You'll stone me for saying this, but..
If you're using LuaX, you skip this problem. There the linkage system
is different, and there's no lua.dll at all; modules link directly to
the main core. So, if it doesn't matter, you might consider that as
6.12.2004 kello 23:24, David Burgess kirjoitti:
What can happen if I compile my application with lua statically
load a lua module that is dynamically linked to lua.dll?
Should (or must) both be linked the same way?
"Must" is the answer.