4 ms·

While ELF has its problems, I wouldn't call Windows's approach 'right', by a long shot. * Writing libraries is a big hassle in Windows because you have to expl

While ELF has its problems, I wouldn't call Windows's approach 'right', by a long shot. * Writing libraries is a big hassle in Windows because you have to explicitly define all exportable symbols. * DLLs have all kinds of strange boundary rules. C++ exceptions cannot pass DLL boundaries. Heap memory allocated by one DLL cannot always be freed by another. Etc etc.

shin_lao 14y ago
The first problem is actually not a problem but one of the reasons DLLs are better: private by default reduce linking problems. The second problem has got nothing to do with DLLs and everything to do with the fact that there is no C++ ABI. As for memory allocation, it's not really a good idea to allocate memory in a library and free it in another, is it?
- npsimons 14y ago
  As for memory allocation, it's not really a good idea to allocate memory in a library and free it in another, is it? Ah, I guess I'll have to stop using strdup() then.
  - shin_lao 14y ago
    strdup(), part of the libc, allocates memory with a function from the libc (malloc), therefore you are allocating and freeing memory with functions within the same library. However, yes, for security reasons strdup should be avoided.
pjmlp 14y ago
> Writing libraries is a big hassle in Windows because you have to explicitly define all exportable symbols. Just like in Aix, unless it is now changed (my experience goes back to 2001). > C++ exceptions cannot pass DLL boundaries. C++ restrictions have to do with lack of C++ ABI. You have in same issue in ELF systems, when mixing compilers. > Heap memory allocated by one DLL cannot always be freed by another. This is a good thing. Object handles belong to the module that created them, and it is a good way to ensure a clean way to use accessor functions to deal with data.
- klodolph 14y ago
  > This is a good thing. Object handles belong to the module that created them, and it is a good way to ensure a clean way to use accessor functions to deal with data. No, it doesn't prevent anything. There is nothing stopping you from calling free() on a buffer returned from a function in a DLL, it just might crash. There is nothing inherently superior about adding an additional source of crashes which are not diagnosed by the compiler.
npsimons 14y ago
C++ exceptions cannot pass DLL boundaries. Are you sure this isn't just a C++ problem? It's a well known fact that due to name mangling, C++ compiled by different compilers (even different versions of the same compiler!) can't always be called.
- saurik 14y ago
  This is due to the different libraries possibly being compiled against different versions of the C++ standard library or C runtime, and is thereby somewhat relevant to and "caused by" this specific feature (where different libraries can do this in the first place). The same thing could happen if two people, for example, linked against different major versions of an XML parser: they would be unable to share state, as data returned from one library would have been generated with one XML library and then would be modified by another, even though the types matches for the purposes of the C compiler. In practice, different major versions should simply be considered different libraries, and many argue it is an encapsulation mistake to allow your public interface to be bound up with details of the libraries you use; however, this kind of use case is much more likely to either work correctly or fail horribly on Linux, as opposed to ending up in some kind of weird uncanny valley of stability. People then reference C++ with regards to this, because C++ happens to have a library that acts on tons of core data types, and yet by default (you can build setups where this doesn't happen, but it requires coordination over the DLLs you are mingling) compiles trivial parts of the algorithms inlined into your logic (so there isn't even a function boundary at all, much less code that could be shared easily). The result is that if C++ touches your public interface, you are almost certainly, at bare minimum, wanting to share something "simple" like a string or a vector, or alternatively wanted to use exceptions somewhere. You now, however, run into the XML library issue. Some people believe this is simply bad API design (as C++ should be treated as a library to encapsulate), while others believe it is a language deficiency. I argue that to the extent it is the latter you probably do control the DLLs that are acting as a set, and external APIs should operate under the former regime (as yes: you also have to worry about name mangling there, although compilers have gotten very good at that: we now tend to see them as part of the system ABI).

shin_lao 14y ago

The first problem is actually not a problem but one of the reasons DLLs are better: private by default reduce linking problems. The second problem has got nothing to do with DLLs and everything to do with the fact that there is no C++ ABI. As for memory allocation, it's not really a good idea to allocate memory in a library and free it in another, is it?

npsimons 14y ago
As for memory allocation, it's not really a good idea to allocate memory in a library and free it in another, is it? Ah, I guess I'll have to stop using strdup() then.
- shin_lao 14y ago
  strdup(), part of the libc, allocates memory with a function from the libc (malloc), therefore you are allocating and freeing memory with functions within the same library. However, yes, for security reasons strdup should be avoided.

pjmlp 14y ago

> Writing libraries is a big hassle in Windows because you have to explicitly define all exportable symbols. Just like in Aix, unless it is now changed (my experience goes back to 2001). > C++ exceptions cannot pass DLL boundaries. C++ restrictions have to do with lack of C++ ABI. You have in same issue in ELF systems, when mixing compilers. > Heap memory allocated by one DLL cannot always be freed by another. This is a good thing. Object handles belong to the module that created them, and it is a good way to ensure a clean way to use accessor functions to deal with data.

klodolph 14y ago
> This is a good thing. Object handles belong to the module that created them, and it is a good way to ensure a clean way to use accessor functions to deal with data. No, it doesn't prevent anything. There is nothing stopping you from calling free() on a buffer returned from a function in a DLL, it just might crash. There is nothing inherently superior about adding an additional source of crashes which are not diagnosed by the compiler.

npsimons 14y ago

C++ exceptions cannot pass DLL boundaries. Are you sure this isn't just a C++ problem? It's a well known fact that due to name mangling, C++ compiled by different compilers (even different versions of the same compiler!) can't always be called.

saurik 14y ago
This is due to the different libraries possibly being compiled against different versions of the C++ standard library or C runtime, and is thereby somewhat relevant to and "caused by" this specific feature (where different libraries can do this in the first place). The same thing could happen if two people, for example, linked against different major versions of an XML parser: they would be unable to share state, as data returned from one library would have been generated with one XML library and then would be modified by another, even though the types matches for the purposes of the C compiler. In practice, different major versions should simply be considered different libraries, and many argue it is an encapsulation mistake to allow your public interface to be bound up with details of the libraries you use; however, this kind of use case is much more likely to either work correctly or fail horribly on Linux, as opposed to ending up in some kind of weird uncanny valley of stability. People then reference C++ with regards to this, because C++ happens to have a library that acts on tons of core data types, and yet by default (you can build setups where this doesn't happen, but it requires coordination over the DLLs you are mingling) compiles trivial parts of the algorithms inlined into your logic (so there isn't even a function boundary at all, much less code that could be shared easily). The result is that if C++ touches your public interface, you are almost certainly, at bare minimum, wanting to share something "simple" like a string or a vector, or alternatively wanted to use exceptions somewhere. You now, however, run into the XML library issue. Some people believe this is simply bad API design (as C++ should be treated as a library to encapsulate), while others believe it is a language deficiency. I argue that to the extent it is the latter you probably do control the DLLs that are acting as a set, and external APIs should operate under the former regime (as yes: you also have to worry about name mangling there, although compilers have gotten very good at that: we now tend to see them as part of the system ABI).