Any large application benefits from being able to load DLLs, sooner or
later. Some applicatons seem to do it effortlessly, even in very
disparate environments. For example, the Lua interpreter appears to
consider it a trivial excercise.
An excerpt from the manual:
For instance, if the C path is the string
"./?.so;./?.dll;/usr/local/?/init.so"
the searcher for module foo will try to open the files ./foo.so,
./foo.dll, and /usr/local/foo/init.so, in that order. Once it finds a C
library, this searcher first uses a dynamic link facility to link the
application with the library. Then it tries to find a C function inside
the library [...].
This is useful even when you are simply using the Lua interpreter, when
you want to use C libraries. But it becomes extremely useful when using
Lua as a scripting language within your own application. (In that case,
of course, D would not even have to do the loading.)
But, for D-only applications, such DLL loading would be just as useful.
To fix this simply cannot be as difficult as it might seem from the
persistent lack of a final solution.
If I understand correctly, the Lua licence does allow it to be used,
modified, even sold, freely.
My question: would it be worthwhile to take a peek at the library
loading code in Lua sources, to see if we can implement it (possibly as
such, since much of the loading is non-Lua specific) into D?
(In case there is rampant paranoia about licences, I think a simple
e-mail to Roberto, (home page: www.inf.puc-rio.br/~roberto/) would
dissolve any doubts.)
