[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Is a Lua system easily embeddable?
- From: "John Hind" <john.hind@...>
- Date: Mon, 7 Sep 2009 09:50:47 +0100
Of course, another approach is to use virtual file systems (such as FUSE or Windows 7 VHD). The "EXE" would actually be a VFS with code to mount it and then start a secondary EXE within the VFS. The secondary EXE then transparently sees the VFS and can load DLL files (and Lua scripts) without even knowing the file system is virtual. The outer process would need to monitor the inner one and automatically dismount the VFS when the inner process terminates.
However the approach you suggest might be more efficient or more easily implemented. Can you point me to this code ("some libraries out there") as I have not come across it in my searches.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:lua-
> email@example.com] On Behalf Of Jerome Vuarand
> Sent: 07 September 2009 02:03
> To: Lua list
> Subject: Re: Is a Lua system easily embeddable?
> 2009/9/5 John Hind <firstname.lastname@example.org>:
> > This is easily fixed on the Windows environment because Windows
> > have support for embedded resources and it is straightforward to
> provide a
> > loader so Lua "require" looks for Lua code in resources.
> Unfortunately, this
> > is not portable to other platforms. Also unfortunately you cannot
> load dll
> > files from resources, so you still must statically link the C parts
> > composite libraries (not usually any problem, but it would be nice
> > This problem is not unique to Lua and it afflicts all "scripting"
> > (just look at how many files the Firefox browser tips into your file
> > system!). What's needed is a generic "meta-executable" format that
> embeds a
> > virtual file system and makes it available to a normal executable (in
> > case a Lua runtime) stored in the same file. Any examples of such
> systems I
> > can find extract content out to temporary files, which rather spoils
> > point!
> Just for the sake of precision, I'd like to point that while the
> standard Windows DLL loader is not capable of loading DLLs from
> another DLL resource, afaik all its features are reproducible in user
> code (it's not using kernel black magic). Therefore it's possible to
> load DLLs from anywhere. Some libraries out there allow loading DLLs
> from in-memory buffers with the exact same capabilities and interface
> as the standard win32 LoadLibrary+GetProcAddress.