Rainer Schuetze wrote:
> 
> Recently, I also started creating threads in a DLL, and that revealed a
> few inconsistencies between dll_helper.d and thread.d. The major problem
> is that DLLMain is called before the thread is added to the list of
> library created threads, causing initialization to be done twice.
> I have a patch for this, but I'm not yet on the latest git-version. I'll
> try to update the bugzilla entry
> http://d.puremagic.com/issues/show_bug.cgi?id=5582 with it and maybe
> even create a pull request.

here's the commit with my patches to the runtime regarding DLL support for Windows Server 2003 and XP/64 and thread creation inside a DLL:

https://github.com/rainers/druntime/commit/864bb10cab2e0a3807df27962a73990b9e44c1e1

On Apr 22, 2011, at 9:48 AM, Rainer Schuetze wrote:

> Rainer Schuetze wrote:
>> Recently, I also started creating threads in a DLL, and that revealed a few inconsistencies between dll_helper.d and thread.d. The major problem is that DLLMain is called before the thread is added to the list of library created threads, causing initialization to be done twice.
>> I have a patch for this, but I'm not yet on the latest git-version. I'll try to update the bugzilla entry http://d.puremagic.com/issues/show_bug.cgi?id=5582 with it and maybe even create a pull request.
> 
> here's the commit with my patches to the runtime regarding DLL support for Windows Server 2003 and XP/64 and thread creation inside a DLL:
> 
> https://github.com/rainers/druntime/commit/864bb10cab2e0a3807df27962a73990b9e44c1e1

Awesome.  I'll apply it today.

On Apr 22, 2011, at 11:09 AM, Sean Kelly wrote:

> On Apr 22, 2011, at 9:48 AM, Rainer Schuetze wrote:
> 
>> Rainer Schuetze wrote:
>>> Recently, I also started creating threads in a DLL, and that revealed a few inconsistencies between dll_helper.d and thread.d. The major problem is that DLLMain is called before the thread is added to the list of library created threads, causing initialization to be done twice.
>>> I have a patch for this, but I'm not yet on the latest git-version. I'll try to update the bugzilla entry http://d.puremagic.com/issues/show_bug.cgi?id=5582 with it and maybe even create a pull request.
>> 
>> here's the commit with my patches to the runtime regarding DLL support for Windows Server 2003 and XP/64 and thread creation inside a DLL:
>> 
>> https://github.com/rainers/druntime/commit/864bb10cab2e0a3807df27962a73990b9e44c1e1
> 
> Awesome.  I'll apply it today.

Oops... could you create a pull request?

Sean Kelly wrote:
> On Apr 22, 2011, at 11:09 AM, Sean Kelly wrote:
> 
>> On Apr 22, 2011, at 9:48 AM, Rainer Schuetze wrote:
>>
>>> Rainer Schuetze wrote:
>>>> Recently, I also started creating threads in a DLL, and that revealed a few inconsistencies between dll_helper.d and thread.d. The major problem is that DLLMain is called before the thread is added to the list of library created threads, causing initialization to be done twice.
>>>> I have a patch for this, but I'm not yet on the latest git-version. I'll try to update the bugzilla entry http://d.puremagic.com/issues/show_bug.cgi?id=5582 with it and maybe even create a pull request.
>>> here's the commit with my patches to the runtime regarding DLL support for Windows Server 2003 and XP/64 and thread creation inside a DLL:
>>>
>>> https://github.com/rainers/druntime/commit/864bb10cab2e0a3807df27962a73990b9e44c1e1
>> Awesome.  I'll apply it today.
> 
> Oops... could you create a pull request?

Tried my best here:

https://github.com/D-Programming-Language/druntime/pull/12

but it contains commits you'd probably do not want. I guess you'll have to "cherry pick" the commit that corresponds to the commit shown above.

Is there any sensible way to create a pull request from single commits? I don't want to create branches for every single change, especially if the building/working with the library need other changes aswell. Keeping changes locally does not work either, because git refuses to pull updates from other sources then.

On Apr 22, 2011, at 12:41 PM, Rainer Schuetze wrote:
> 
> Is there any sensible way to create a pull request from single commits? I don't want to create branches for every single change, especially if the building/working with the library need other changes aswell. Keeping changes locally does not work either, because git refuses to pull updates from other sources then.

You could probably merge specific changes into a separate branch and generate the pull request from that.  I really don't know git well enough to say.

On Apr 20, 2011, at 2:06 PM, Rainer Schuetze wrote:
> 
> Adding standardDllMain() sounds good to me. I agree with windows.dll, too.
> 
> I'm not so sure about windows._thread. OSX has an osx.mach.thread_act, so we might want to have a similar naming for windows, but I have no idea what "act" stands for here.
> 
> Looking through the code, it mostly deals with the thread environment block, so windows.teb might be ok, but not really obvious.
> 
> dllthread: the code has nothing to do with DLLs explicitely, so it would not fit.
> threadsupp: maybe better: threadaux or threadhelp. The latter would at least match the naming of the dbghelp module.
> 
> Though not perfect, threadaux or threadhelp are my favorites.

Okay, _dll.d is being renamed to dll.d and _thread.d to threadaux.d.  dbghelp.d is a bit different in that it's an interface to dbghelp.dll, so its name wasn't an arbitrary choice.

I deleted all the .di files. Still fails the test suite:

..\dmd -c mydll
mydll.d(12): Error: module dll_helper is in file 'core\dll_helper.d' which
cannot be read
import path[0] = \cbx\mars\phobos
import path[1] = \cbx\mars\druntime\import

--- errorlevel 1

I know it's because core\dll_helper.d is gone, but the tests need to be fixed, and I'm not sure what needs to be done with them.

The easiest thing is to replace the "import core.dll_helper" with "import core.sys.windows.dll".  The dll.d module actually has convenience functions that encapsulate what's done manually in the DLL test, but fixing that just makes the code cleaner--it shouldn't alter the result.

On Apr 28, 2011, at 12:14 PM, Walter Bright wrote:

> I deleted all the .di files. Still fails the test suite:
> 
> ..\dmd -c mydll
> mydll.d(12): Error: module dll_helper is in file 'core\dll_helper.d' which cannot be read
> import path[0] = \cbx\mars\phobos
> import path[1] = \cbx\mars\druntime\import
> 
> --- errorlevel 1
> 
> I know it's because core\dll_helper.d is gone, but the tests need to be fixed, and I'm not sure what needs to be done with them.
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Hah! It works again! Thanks!

On 4/28/2011 12:26 PM, Sean Kelly wrote:
> The easiest thing is to replace the "import core.dll_helper" with "import core.sys.windows.dll".  The dll.d module actually has convenience functions that encapsulate what's done manually in the DLL test, but fixing that just makes the code cleaner--it shouldn't alter the result.
>
> On Apr 28, 2011, at 12:14 PM, Walter Bright wrote:
>
>> I deleted all the .di files. Still fails the test suite:
>>
>> ..\dmd -c mydll
>> mydll.d(12): Error: module dll_helper is in file 'core\dll_helper.d' which cannot be read
>> import path[0] = \cbx\mars\phobos
>> import path[1] = \cbx\mars\druntime\import
>>
>> --- errorlevel 1
>>
>> I know it's because core\dll_helper.d is gone, but the tests need to be fixed, and I'm not sure what needs to be done with them.
>>