I've got little test here https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.

I have one application and two dlls. Application loads both dlls, calls their factory functions and then passes each IModule instance that it got from factories to those modules.

Modules then try to cast those IModule refs back to their real interfaces (ISharedModule1) but i am getting null there.

A have found a workaround for this by returning a void* pointer to real interface and it back when needed.

Another, and more major issue is, that when exception is thrown application fail immediately.

Is it broken on windows, or it is me doing it wrong?

On 24.11.2014 19:20, MrSmith wrote:
> I've got little test here
> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>
>
> I have one application and two dlls. Application loads both dlls, calls
> their factory functions and then passes each IModule instance that it
> got from factories to those modules.
>
> Modules then try to cast those IModule refs back to their real
> interfaces (ISharedModule1) but i am getting null there.

The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL.

>
> A have found a workaround for this by returning a void* pointer to real
> interface and it back when needed.
>

Another workaround for a limited number of classes would be to add member functions 'ISharedModule1 toSharedModule1() { return null; }' in IModule and override these 'ISharedModule1 toSharedModule1() { return this; }' in the appropriate class.

> Another, and more major issue is, that when exception is thrown
> application fail immediately.
>
> Is it broken on windows, or it is me doing it wrong?

I haven't tried in a while but I think it should work on Win32, but probably does not on Win64.

On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze wrote:
>
> On 24.11.2014 19:20, MrSmith wrote:
>> I've got little test here
>> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>>
>>
>> I have one application and two dlls. Application loads both dlls, calls
>> their factory functions and then passes each IModule instance that it
>> got from factories to those modules.
>>
>> Modules then try to cast those IModule refs back to their real
>> interfaces (ISharedModule1) but i am getting null there.
>
> The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL.
>
>>
>> A have found a workaround for this by returning a void* pointer to real
>> interface and it back when needed.
>>
>
> Another workaround for a limited number of classes would be to add member functions 'ISharedModule1 toSharedModule1() { return null; }' in IModule and override these 'ISharedModule1 toSharedModule1() { return this; }' in the appropriate class.
>
>> Another, and more major issue is, that when exception is thrown
>> application fail immediately.
>>
>> Is it broken on windows, or it is me doing it wrong?
>
> I haven't tried in a while but I think it should work on Win32, but probably does not on Win64.

I thought it will work at least for interfaces.
Any way, this is workaroundable, but exceptions must be there at least.

On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze wrote:
> The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL.

Maybe we can have a function, which will search the typeinfo based on type name, like C++ does it?

On Tuesday, 25 November 2014 at 10:02:00 UTC, Kagamin wrote:
> On Monday, 24 November 2014 at 20:56:29 UTC, Rainer Schuetze wrote:
>> The different DLLs have different copies of the RTTI for the classes (you could not link them separately otherwise). Looking for base classes or derived classes only compares RTTI pointers, so it doesn't find the target class of a cast in the hierarchy inside another DLL.
>
> Maybe we can have a function, which will search the typeinfo based on type name, like C++ does it?

I was sure that when dll is loaded, runtimes will merge (hook) and all type info is shared between dll and application.

Am 24.11.2014 19:20, schrieb MrSmith:
> I've got little test here
> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>
>
> I have one application and two dlls. Application loads both dlls, calls
> their factory functions and then passes each IModule instance that it
> got from factories to those modules.
>
> Modules then try to cast those IModule refs back to their real
> interfaces (ISharedModule1) but i am getting null there.
>
> A have found a workaround for this by returning a void* pointer to real
> interface and it back when needed.
>
> Another, and more major issue is, that when exception is thrown
> application fail immediately.
>
> Is it broken on windows, or it is me doing it wrong?

Dlls are generally broken on windows. If you hack around in druntime (e.g. the casting routines) you can get it to work to some degree, but you are going to be happier if you just stay away from it.

On Tuesday, 25 November 2014 at 18:39:56 UTC, Benjamin Thaut wrote:
> Am 24.11.2014 19:20, schrieb MrSmith:
>> I've got little test here
>> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>>
>>
>> I have one application and two dlls. Application loads both dlls, calls
>> their factory functions and then passes each IModule instance that it
>> got from factories to those modules.
>>
>> Modules then try to cast those IModule refs back to their real
>> interfaces (ISharedModule1) but i am getting null there.
>>
>> A have found a workaround for this by returning a void* pointer to real
>> interface and it back when needed.
>>
>> Another, and more major issue is, that when exception is thrown
>> application fail immediately.
>>
>> Is it broken on windows, or it is me doing it wrong?
>
> Dlls are generally broken on windows. If you hack around in druntime (e.g. the casting routines) you can get it to work to some degree, but you are going to be happier if you just stay away from it.

Is there a bugzilla issue for this? And what is the status of windows dlls?

Am 25.11.2014 21:46, schrieb MrSmith:
> On Tuesday, 25 November 2014 at 18:39:56 UTC, Benjamin Thaut wrote:
>> Am 24.11.2014 19:20, schrieb MrSmith:
>>> I've got little test here
>>> https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
>>>
>>>
>>>
>>> I have one application and two dlls. Application loads both dlls, calls
>>> their factory functions and then passes each IModule instance that it
>>> got from factories to those modules.
>>>
>>> Modules then try to cast those IModule refs back to their real
>>> interfaces (ISharedModule1) but i am getting null there.
>>>
>>> A have found a workaround for this by returning a void* pointer to real
>>> interface and it back when needed.
>>>
>>> Another, and more major issue is, that when exception is thrown
>>> application fail immediately.
>>>
>>> Is it broken on windows, or it is me doing it wrong?
>>
>> Dlls are generally broken on windows. If you hack around in druntime
>> (e.g. the casting routines) you can get it to work to some degree, but
>> you are going to be happier if you just stay away from it.
>
> Is there a bugzilla issue for this? And what is the status of windows dlls?

Yes there is: https://issues.dlang.org/show_bug.cgi?id=9816
Also: http://wiki.dlang.org/DIP45

I'm currently working on it, but I can not promise anything. Also its unclear how long its going to take to get it merged once its actually working.

Kind Regards
Benjamin Thaut

Am 25.11.2014 21:46, schrieb MrSmith:
> Is there a bugzilla issue for this? And what is the status of windows dlls?

If you want a bit more dll support right now, I suggest that you take a look at these changes and merge them into your own version of druntime:

https://github.com/Ingrater/druntime/commit/7e54eac91dd34810913cfe740e709b18cbbc00d6

Kind Regards
Benjamin Thaut

On Wednesday, 26 November 2014 at 07:46:12 UTC, Benjamin Thaut wrote:
> Am 25.11.2014 21:46, schrieb MrSmith:
>> Is there a bugzilla issue for this? And what is the status of windows dlls?
>
> If you want a bit more dll support right now, I suggest that you take a look at these changes and merge them into your own version of druntime:
>
> https://github.com/Ingrater/druntime/commit/7e54eac91dd34810913cfe740e709b18cbbc00d6
>
> Kind Regards
> Benjamin Thaut

Thank you very much!