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

Sean Kelly sean at invisibleduck.org
Wed Apr 20 10:55:25 PDT 2011


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


More information about the D-runtime mailing list