To implement shared libraries on a operating system level generally two steps have to be taken

1) Locate which shared library provides a required symbol
2) Load that library and retrieve the final address of the symbol

Linux does both of those steps at program start up time. As a result all symbols have identity. If a symbols appears in multiple shared libraries only one will be used (first come first serve) and the rest will remain unused.

Windows does step 1) at link time (through so called import libraries). And Step 2) at program start up time. This means that symbols don't have identity. If different shared libraries provide the same symbol it may exist multiple times and multiple instances might be in use.

Why is this important for D?
D uses symbol identity in a few places usually through the 'is' operator. The most notable is type info objects.

bool checkIfSomeClass(Object o)
{
  return typeid(o) is typeid(SomeClass);
}

The everyday D-user relies on this behavior usually when doing dynamic casts.
Object o = ...;
SomeClass c = cast(SomeClass)o;

So if symbols don't have identity all places within druntime and phobos which rely on symbol identity have to be identified and changed to make it work with windows dlls. I'm currently at a point in my Windows Dll implementation where I have to decide how to solve this issue. There are two options now.

Option 1)
Leave as is, symbols won't have identity.

Con:
- It has a performance impact, because for making casts and other features, which rely on type info objects, work we will have to fallback to string comparisons on windows.
- All places within druntime and phobos which use symbol identity have to be found and fixed. This is a lot of work and might produce many bugs.
- Library writers have to consider this problem every time they extend / modify druntime / phobos.
- There are going to be tons of threads on D.learn about "Why does this not work in a Dll"

Pro:
- Its the plain windows shared library mechanism in all its uglyness.

Option 2)
Windows already generates a indirection table we could patch. Rebind the symbols at program start up time overwriting the results of the windows program loader. Essentially reproducing the behavior of linux with code in druntime.

Pro:
- Symbols would have identity.
- Everything would behave the same way as on Linux.
- No run time performance impact.

Con:
- Performance impact at program start up time.
- Might increase the binary size (I'm not entirely sure yet if I can read all required information out of the binary itself or if I have to add more myself)



I personally would prefer option 2 because it would be easier to use and wouldn't cause lots of additional maintenance effort.

Any opinions on this? As both options would be quite some work I don't wan't to start blindly with one and risking it being rejected later in the PR.

Kind Regards
Benjamin Thaut

As I understand, if SomeClass is in some dll, it will be there and be unique. If typeid(SomeClass) loads the symbol address from IAT, it will be the same address as in dll.

On Friday, 8 May 2015 at 08:04:20 UTC, Kagamin wrote:
> As I understand, if SomeClass is in some dll, it will be there and be unique. If typeid(SomeClass) loads the symbol address from IAT, it will be the same address as in dll.

No, you don't understand. TypeInfos are stored in comdats. And they are only created if needed. So if you have SomeClass there is a typeinfo for SomeClass but not all possible typeinfos are created. Say you never use const(SomeClass) and then two other dlls use const(SomeClass) then each of those two dlls will contain a instance of the TypeInfo for const(SomeClass). This issue gets even worse with TypeInfos of templated types.

bool checkIfSomeClass(Object o)
{
  return typeid(o) is typeid(SomeClass);
}

Doesn't typeid(o) extract TypeInfo from the object? If it's stored as a physical value in the object, how can it change transparently for const class?

As I understand, C++ resorts to preinstantiation of needed templates when compiling to dlls.

Am 08.05.2015 um 13:34 schrieb Kagamin:
> bool checkIfSomeClass(Object o)
> {
>    return typeid(o) is typeid(SomeClass);
> }
>
> Doesn't typeid(o) extract TypeInfo from the object? If it's stored as a
> physical value in the object, how can it change transparently for const
> class?
>
> As I understand, C++ resorts to preinstantiation of needed templates
> when compiling to dlls.

This is obviously a very simplified example. You either have to take my word for it about the actualy issue and voice your opinion on the decision to make or dig into dmds sources, understand how type infos work and then question my issue description. But please don't question my description of the issue without actually understanding what the implementation looks like.

Let me put my question in a different way:

From the point of a D user, would you rather have 'is' expressions and 'static' / '__gshared' variables inside classes do strange things sometimes when using dlls or would you wan't it to always work without considering the underlying implementation. Please choose option 1 or option 2.

Does nobody have a opinion on this?

On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
> Pro:
> - Its the plain windows shared library mechanism in all its uglyness.

I wonder if anyone can provide more "Pro" input :)

Am 10.05.2015 um 21:51 schrieb Dicebot:
> On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
>> Pro:
>> - Its the plain windows shared library mechanism in all its uglyness.
>
> I wonder if anyone can provide more "Pro" input :)

I described both implementations of shared libaries. From the description alone you should be able to find any other "pro" arguments for the windows approach. The only one I could find was, that its faster at program startup time, compared to the linux one, but is inferrior in all other points.

Well choice between two presented options seems obvious so I suspect a catch :)

On Sunday, 10 May 2015 at 21:44:59 UTC, Dicebot wrote:
> Well choice between two presented options seems obvious so I suspect a catch :)

Well, exactly like with the shared library visibility the only catch might be Walter's and Andrei's opinion.