On Tue, 01 Feb 2011 13:33:20 -0500, Rainer Schuetze <[email protected]>
wrote:
Robert Jacques wrote:
On Tue, 01 Feb 2011 03:05:13 -0500, Rainer Schuetze
<[email protected]> wrote:
XP TLS support with dynamically loaded DLLs is fixed for some time now
with a workaround implemented in druntime. Also, DLLs can be used in
multi-threading environments.
Yes, I pointed out in another thread that D loading D DLLs can work
around this issue, but the original post was about calling a D DLL from
another language, specifically C#, where the limitation in XP still
exists. (Of course, you might be able to port the work around to C#.
Hmm...)
The workaround is not about D loading a D DLL. Visual D lives happily in
the C++/C# world of Visual Studio, even on XP. It's the magic inside
dll_process_attach() that sets up TLS for existing threads and patches
the loader structures to make XP think the DLL was loaded at startup
(where implicite TLS works). The downside is that the DLL cannot be
unloaded, though.
Thanks, again. Though the pros and cons of this should be listed in the
docs somewhere.
> I've listed some example code from my project below:
[snip]
This DLLMain code is a bit outdated (is it D1?), the current proposed
version is here: http://www.digitalmars.com/d/2.0/dll.html
Thanks. It was D2, but it was forked a while ago. Given that the
recommended way of doing this might change in the future, a string
mixin in core.dll_helper might be appropriate.
I don't like mixins too much, but a standard_DllMain that you can
forward to from DllMain, might be a good idea to include into the
runtime library.
Yes, on second thought, a standard_DllMain is the better solution.
