Modern C++ Lamentations
Rubn
where at is.this
Thu Jan 3 21:07:59 UTC 2019
On Thursday, 3 January 2019 at 19:36:52 UTC, Jonathan M Davis
wrote:
> *nix has the same distinction. It's a fundamentally different
> situation from linking your executable against the library.
> You're really dynamically loading rather than dynamically
> linking (though unfortunately, the terminology for the two is
> not particularly distinct, and they're often referred to the
> same way even though they're completely different). Loading
> libraries that way is what you do when you do stuff like
> plugins, because those aren't known when you build your
> program. But it makes a lot less sense as an alternative to
> linking your program against the library if you don't actually
> need to load the library like that. The COFF vs OMF mess on
> Windows makes it make slightly more sense on Windows (at least
> with D, where dmd uses OMF by default, unlike most of the C/C++
> world at this point), because then it doesn't matter whether
> COFF or OMF was used (e.g. IIRC, Derelict is designed to be
> loaded that way for that reason), but in general, it's an
> unnecessarily complicated way to use a library. And if Windows'
> eccentricities make it more desirable than it is on *nix
> systems, then that's just yet another black mark against how
> Windows does dynamic linking IMHO.
>
> - Jonathan M Davis
>
> From the last time I worked with Windows dlls, I remember quite
> distinctly
> that doing anything like adding a symbol to the library meant
> that it was incompatible with executables previously built with
> it (which is not true for shared libraries on *nix - they only
> break if the ABI for the existing symbols changes). So, if
> that's not the case, I don't know what we were doing wrong, but
> I have an extremely sour taste in my mouth from dealing with
> Windows dlls. It was my experience that Linux stuff generally
> just worked, whereas we kept having to deal with junk on
> Windows to make them work (e.g. adding special attributes to
> functions just so that they would be exported), and I
> absolutely hated it. I have nothing good to say about dlls on
> Windows. It's quite possible that some of it isn't as bad if
> you know more about it than the team I was working on did, but
> it was one part of why making our libraries cross-platform was
> not at all fun.
>
> - Jonathan M Davis
Yah you should just stop and never talk about how Windows DLLs
work again until you've actually learned how they actually work.
"I used some piece of software that I have no idea how it works,
I condemn it cause it works this way even though I'm sure if it
even works that way". I already know the D team has no idea what
they are doing on Windows, but just stop.
More information about the Digitalmars-d
mailing list