This is something I prototyped sometimes ago(3y) for squirrel 1.x, but I thought it wasn't fit for the core release. I think supporting something like this as official add-on is fine. I'd rather not write platform specific code in the core library. Maybe could end up in the 'etc' directory.
I personally think that the lua solution is very naive, the fact that every module is required to link against lua is just nonsense; plus, there's no way to build any kind of backward compatibilty between module/VMs.
BTW I digged you my old design notes about the topic.
*HOW DYNAMIC MODULES WORK
-2 kind of modules binary and squirrel only(the user is not aware of that)
-every module has a stub ".nut" file to initialize himself and load a binary module if needed
so if is a squirrel only module, the stub can be the implementaion as well.
-the stub is called "modulename_stub.nut" or something like that
-the stub file of a binary module does the actual module loading(so can check also for other resources than the dll)
**BYNARY MODULES
a binary module exports 4 functions:
int sq_module_getapiversion()
return the API version the the module requires to work propetly
int sq_module_supportcharsize(int charsize)
charsize can be 8, 16 the module can implement both or just fail if the char size is not supported
int sq_module_open(HSQUIRRELVM v,SQModuleAPI *api)
loadmodule push the target table in the stack(the one that will contain the module api functions)
and calls this function.
SQModuleAPI is a pointer to a structure containing function pointers to
the squirrel API and the std lib utilities function(file creation, blob creation etc..)
so a module can use stl lib compliant types.
struct SQModuleAPI {
p_sq_getinteger sq_getinteger;
p_sq_newclosure sq_newclosure;
...
...
}
new version of the module api will add the new functions at the bottom of the structure in order to be able to load old modules with a newer version.
modules do not link any squirrel related lib all is passed through this struct, hopefully if the std api is good enough a module could avoid to link the CRT lib as well(in most of the cases).
a set of macros is provided to be able to transparently link the module statically or dynamically.
int sq_module_close()
called before unloading the module.
.TO SOLVE can modules be unloaded runtime in a safe way?
.TO SOLVE
to resolve the physical location of a module
.IDEA maybe a central db based system like MS COM or .NET?
should be cool if an embedded version could kind of set is own policy
what about passing an modulelocator callback when the module library is registered?
sq_register_modulelib(v,locator);
int locator(HSQUIRRELVM v,const SQChar *modulename)
-API
loadmodule("inet") //register the module globally
local s = socket();
inet <- loadmodule("inet",{}) //register the module in the table passed as second param
local s = inet.socket();
ciao
Alberto