D hates to be dynamic linked

[Roald Ribe]

Justin Johansson wrote:
> Rainer Schuetze wrote:
> 
>> 5. To share gc-collected objects between different DLLs, a common 
>> phobos-DLL seems necessary. Extracting the GC into a separate DLL and 
>> using the proxy-mechanism to attach any other client-DLL to it seems 
>> feasable, but are there other things that need to be shared between 
>> different phobos-instances? What about exception-handling?
>>
> 
> Sounds like you have the right idea; that sounds similar to the
> way Microsoft does it with MFC DLL's.  If I recall correctly,
> when MFC applications are DLL based, you link with a common C runtime
> DLL as well.  This way all memory allocations and frees are handled
> by the common C runtime DLL (i.e. single point of responsibility).
> Presumably a similar regime for D and the GC would be necessary.

Not only MFC. Plain C and C++ programs as well. This is why most MS-
Windows based compiled languages comes with two versions of the
runtime lib, one for static link and one for dynamic link (DLL).

If not, there will always be problems with DLL's in that language
sharing file handles, memory, sockets, threads and so on.

The flip side of the coin is "DLL hell" (use Google). It is less of
a problem in newer versions of MS-Windows than it used to be, but
necessary to consider when supporting older platforms.

The Linux/BSD/unix side I know less about, but since they have a
common location for shared libs and support multiple versions of
the same lib (AFAIK) the problems are less there.

Roald