Dynamic D Library

[Benji Smith]

Daniel Keep wrote:
> If we have, for example, a C app that is using D code as plugins, each
> plugin will ask the system for "dmdrt.dll" using its minimal embedded
> DDL stub.  But since they're system calls, we should only get one copy.
>  I'm not sure exactly how the system will share that library, though;
> whether it's per-process or system-wide.
> 
> In any case, the DDL stub should be able to pull in the full DDL from
> dmdrt.dll and then use that to link everything together.
> 
> The nice bonus of this is that DDL just becomes an implementation detail
> AND we can say "yes, we can do DLLs in D!" even if we're only using them
> to contain a DDL payload.
> 
> The one downside I can think of is that if you DID want to distribute a
> D plugin for a C/C++ program, you'd also need to ship dmdrt.dll
> alongside it.  Although, in that case, it probably wouldn't hurt
> anything (aside from memory usage) to simply statically link the runtime
> and standard library in; if the host app is C/C++, then the plugins
> probably won't be able to stomp all over each other.

My primary use of D right now is to build DLLs for C++ applications, so 
I'd be very annoyed if the standard Windows DLL functionality became 
more convoluted.

For custom loading into D applications, why even bother using a DLL as a 
container? Why not design a file format (maybe even DDL as it currently 
exists) and use that as the primary dynamic loading & linking machanism, 
  on all platforms?

--benji