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