D hates to be dynamic linked

[Justin Johansson]

Rainer Schuetze wrote:
> Hi,
> 
> as I'm also hitting some problems with DLLs, here are some issues that I 
> am now aware of (sorry, can't tell for linux shared objects, but I guess 
> the situation is similar):
> 
> 1. For D2, there is a major blocker with DLLs loaded after intialization 
> on XP because of no TLS support from the OS. There is a simple 
> workaround for single-threaded application (just setting FS:2c to a 
> pointer to _tlsstart), but I'm considering a full emulation of the TLS 
> initialization.
> 
> 2. No multi-threading support: I've added a function to std.thread that 
> allows adding a thread to the Thread.allThreads array, so it can be 
> called from DLLMain/THREAD_ATTACH. That way the GC can suspend these, 
> and allocations from different threads don't trample onto each other. Is 
> there anything else needed for full multi-threading support?
> 
> My patch is currently D1/Win32 only, but should not be too hard to 
> extend to other platforms. Attaching to already existing threads is a 
> bit harder, though, and it might not always be desired, because these 
> threads might never call into D-code.
> 
> 3. To try things out, I am playing around with the mydll-example, and it 
> shows some quirks that you need to get around: the implementation-file 
> for the DLL needs to use a file name different from the module name, 
> because you need another file specifying the exports. Unfortunately this 
> cannot be the di-file created from the source, because it contains two 
> much information that will cause references to symbols not actually 
> exported.
> 
> Maybe some command line switch is needed to just write the exports into 
> the di file without any implementations. Even better: import the 
> implementation file, but don't create unnecessary references. (I think 
> it's the module-initialization that's been called because of the import 
> - maybe some modifier to the import could remove it).
> 
> 4. The documentation on the website states, that you should use
> 
>     DATA            PRELOAD SINGLE
> 
> in the def-file. That probably is still there as a historical note to 
> win 3.1, it will cause different processes to trample on each others 
> data segments. This has caused a few hours of debugging, so please 
> remove it, so others don't fall into the same trap. The mydll-example 
> does not use the statement.
> 
> 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?
> 





> I'd say, if there is a way to put all public symbols into a def-file, 
> then compile phobos into a DLL and create the import library and use 
> this instead of a static library. The multi-threading-issue for DLLs 
> needs to be solved before, though.

Hi Rainer,

Congrats.  Sounds like you are giving the problem a lot of thought.

Just regarding the public symbols though, I hazard a guess that you
might run into a mangled-name problem here.  Don't won't to put a
damper on your effort though; just a forewarning that this might be
an issue.  Perhaps someone else who knows about exporting DLL
symbols might be gracious enough to chime in.

Cheers
Justin