• Georg Wrede (27/27) Apr 07 2009 Any large application benefits from being able to load DLLs, sooner or
• Tim Matthews (8/8) Apr 07 2009 I may be missunderstanding the question but just trying to be helpfull
• Jarrett Billingsley (20/46) Apr 07 2009 l,

Georg Wrede <georg.wrede iki.fi> writes:

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.)

Tim Matthews <tim.matthews7 gmail.com> writes:

I may be missunderstanding the question but just trying to be helpfull
does either

http://www.britseyeview.com/dml/
http://dsource.org/projects/ddl

or

http://dsource.org/projects/lualib
http://dsource.org/projects/dlua

solve antyhing here?

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Tue, Apr 7, 2009 at 5:13 AM, Georg Wrede <georg.wrede iki.fi> wrote:
 Any large application benefits from being able to load DLLs, sooner or
 later. Some applicatons seem to do it effortlessly, even in very disparat=

e
 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

 =A0 =A0 "./?.so;./?.dll;/usr/local/?/init.so"

 the searcher for module foo will try to open the files ./foo.so, ./foo.dl=

l,
 and /usr/local/foo/init.so, in that order. Once it finds a C library, thi=

s
 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 y=

ou
 want to use C libraries. But it becomes extremely useful when using Lua a=

s 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. T=

o
 fix this simply cannot be as difficult as it might seem from the persiste=

nt
 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, sin=

ce
 much of the loading is non-Lua specific) into D?

 (In case there is rampant paranoia about licences, I think a simple e-mai=

l
 to Roberto, (home page: www.inf.puc-rio.br/~roberto/) would dissolve any
 doubts.)

There's no difficulty in _loading_ DLLs or shared libraries on any
system with D.  Both Phobos and Tango have had shared library loader
modules for years.

In fact, there's no difficulty at all on Posix-based systems.

The only difficulty arises on Windows, because DLLs suck.  They cannot
load symbols out of the host app that loads them, and because of that,
things like typeinfo and classinfo are duplicated.  Then things break.

As Tim already pointed out, DDL has been around for quite some time too.