Why did Microsoft go with that approach,
Maybe they didn't know better back then. Historically DLLs
initially didn't support data symbols at all, only functions
where supported. For functions its not a problem if they are
duplicated because usually you don't compare pointers to
functions a lot. Later they added support for data symbols
building on what they had. I assume the system that is in place
now is a result of that.
why did it work for them
Because C/C++ are not as template heavy as D and you basically
try to avoid cross dll templates in c++ at all cost when
developing for windows. Because if you do use templates across
dll boundaries and you are not super careful you get a lot of
issues due to duplicate symbols (e.g. static variables existing
twice etc). MSVC gets around the casting issue by essentially
doing string comparisons for dynamic casts which comes with a
significant performance impact. On the other hand you don't use
dynamic casts in c++ a lot (if you care about performance).
and why does it not map well to D ?
D uses tons of templates everywhere. Even type information for
non templated types is generated on demand and stored in comdats
which can lead to duplicate symbols the same way it does for
templates. In D the dynamic cast is basically the default and you
have to force the compiler to not use a dynamic cast if you care
for performance.
Its not like the linux approach doesn't have issues as well. I
heard of cases where people put large parts of boost into a
shared library and the linux loader would take multiple minutes
to load the shared library into the program. This however is
mostly due to the fact that on linux all symbols are visible from
a shared library by default. In later versions of gcc (4+) they
added a option to make all symbols hidden by default
(-fvisibility=hidden) and you can make only those visible that
you need. This then significantly speeds up loading of shared
libraries because the number of symbols that need to be resolved
is greatly decreased.
On the other hand the linux approach has a additional advantage I
didn't mention yet. You can use the LD_PRELOAD feature to
"inject" shared libraries into processes. E.g. for injecting a
better malloc library to speed up your favorite program. This is
not easily possible with the windows approach to shared libraries.
