C# Interop

[Robert Jacques]

On Tue, 01 Feb 2011 13:33:20 -0500, Rainer Schuetze <r.sagitario at gmx.de>  
wrote:

>
> Robert Jacques wrote:
>> On Tue, 01 Feb 2011 03:05:13 -0500, Rainer Schuetze  
>> <r.sagitario at gmx.de> 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.