D hates to be dynamic linked

[Bane]

Just to get it righ: this means GC will be in dl tool so people that complain about exe size and gc bloat will be happy about it?

Roald Ribe Wrote:

> 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