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
