[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