[D-runtime] druntime fixes again break Windows DLL support

[Don Clugston]

On 20 April 2011 19:55, Sean Kelly <sean at invisibleduck.org> wrote:
> On Apr 20, 2011, at 7:49 AM, Don Clugston wrote:
>
>> On 20 April 2011 16:22, Sean Kelly <sean at invisibleduck.org> wrote:
>>> The helper modules were moved to core.sys.windows. I prepended an underscore because I thought they'd be for internal use. Alternate suggestions welcome.
>>
>> They're ugly and look like internal functions. I think just give them
>> nice names.
>>
>> In fact, how about a wrapper function for the whole mess?
>>
>> extern (Windows)
>> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
>> {
>>     return standardDllMain(hInstance, ulReason);
>> }
>>
>> Any other required work can be done after the standard handler.
>> I make a lot of C-callable DLLs (in fact, it's ~75% of my D
>> programming) and they're all like this.
>> We might need a different wrapper for D-callable DLLs.
>
> I hope that the same wrapper can be used for both.  It would stink if the DLL creator had to build with the intent of being used by D or non-D apps.

It is a decision you have to make right at the beginning.  If you have
a D app, you can (in theory) pass gc-allocated memory through extern
functions. If you have a non-D app, all memory management has to use
memory allocated by Windows, and all extern functions have to be
extern(C) or extern(Windows).
So in the D case, the GC for the DLL and the GC for the app need to be
connected, and it's far more complicated.

> Since Runtime.loadLibrary() knows whether it's loading a D or a non-D DLL, I hope that it will be able to take care of any rejiggering that needs to take place for everything to work properly.

>
> So how about we rename windows._dll to windows.dll, and windows._thread to something else (dllthread? threadsupp?), then add the standardDllMain to windows.dll.

I'd like to hear Rainer's opinion on this --  I'd go along with
anything he says.