Re: dynamic x static (win32)

[Asko Kauppi <asko.kauppi@...>]

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:

	http://luaforge.net/docman/view.php/21/19/manual.html

Thanks for reading, and having interest in this way of seeing things.. 
;)

-asko


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 <asko.kauppi@sci.fi> 
> wrote:
> > 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 
> > an
> > option.
> >
> > http://luaforge.net/project/showfiles.php?group_id=21&release_id=111
> >
> > -ak
> >
> > 6.12.2004 kello 23:24, David Burgess kirjoitti:
> >
> >
> >
> > > >  What can happen if I compile my application with lua statically
> > > > linked, and
> > > > load a lua module that is dynamically linked to lua.dll?
> > > >
> > > > Should (or must) both be linked the same way?
> > >
> > > "Must" is the answer.