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

[Sean Kelly]

On Apr 20, 2011, at 12:45 PM, Don Clugston wrote:

> 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.

In the non-D case, any threads calling the DLL code can be registered via thread_attachThis().  That should cause them to be scanned by the DLLs GC for roots.  Though I imagine the app's main thread is registered regardless, inside rt_init().  That is only the stack though, not malloc-obtained DMA, so I guess it is something the DLL writer has to think about.