lua-users home
lua-l archive

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



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.