D hates to be dynamic linked

[Rainer Schuetze]

I knew that blog, but I expected to find the necessary data somewhere in 
the "undocumented" (but still available) structures.

But I had to dig a little deeper into ntdll myself and came up with a 
patch that is part of the multithread-support for DLLs:

http://d.puremagic.com/issues/show_bug.cgi?id=3885

It emulates the behaviour at process startup time, and modifies the data 
structures so that windows handles the DLL as if it was loaded with the 
process. This has the nice benefit that you don't need to handle the 
creation of new threads.

The downsides are:
- DLL-unload is disabled, but I think unloading a DLL that uses TLS is 
problematic anyway)
- It will leak some pointer-arrays in favor of not causing crashes due 
to other threads using TLS at same time as reallocating these arrays.

As XP is not a fast moving target anymore, I hope that ntdll will not 
change a lot, so it will not need adjustment for every windows-update. 
I've checked SP2 and SP3, which look very much the same with respect to 
TLS implementation.

Rainer

Don wrote:
> 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.
> 
> That's incredibly difficult. Have you read this?
> 
> http://www.nynaeve.net/?p=189
> 
> It'd be great if you can get it to work. But I fear that for Win32, DMD 
> is going to have to switch to explicit TLS.