5 ms·

Looks like PE is superior in this case, since initialization of dynamic modules is handled in dynamic modules themselves? Or do I miss anything? https://docs.m

• userbinator 7y ago
  Dynamic linking on Unixes (POSIX-ish, BSDs, Linux, you know what I mean...) has always been a pretty horrible mess (speaking as someone who has mostly worked in the Windows side of things, starting with DOS and Win16), but DllMain() is not really the way in which it's better on Windows. On Windows, symbols (really just addresses) that you want accessible from other modules need to be explicitly declared "dllexport" in one, and imported (using the "dllimport" attribute) in others. The loader is part of the OS and resolves the imports at load time (although you can do it yourself if you really need/want to, as evidenced by things like packers and plugin modules.) On the nixes, it seems dynamic linking was more of an afterthought (the dynamic loader being its own executable whose path is hardcoded in the binary is one artifact of this) and they tried to reuse what they already had for static linking but at runtime. I suppose it's more "elegant" in some ways, but on the other hand having all the complexity of static linking reproduced at runtime just seems overly convoluted to me.
  • saagarjha 7y ago
    > DllMain() is not really the way in which it's better on Windows. To expand on this, ELF shared libraries have this too: any function pointers in the .init_array section will get executed when the library is loaded. You can get one of these in your library by marking a C function with __attribute__((constructor)) and compiling with compiler that understands this attribute.
    • cryptonector 7y ago
      The .init and .fini sections are run at object load and unload times, respectively, yes, but DllMain() also ets called for each thread at thread startup and teardown time. On Unix you can catch thread teardown with pthread keys, but you can't catch thread startup. Just an FYI.
  • pjmlp 7y ago
    Aix is the exception here, because its original design from shared objects is similar to dlls on Windows, OS/2, Symbian,...
  • temac 7y ago
    Dynamic linking on Unixes works fine and achieves what it tries to do: build a single program with pretty much no difference with what it would have been with static linking, with no non-portable extra annotation needed at source level. The dynamic linking model under Windows is completely different: the various PE are way more separated, to the point of causing all kind of craziness at C++ interfaces boundaries even if everything has been compiled with exactly the same compiler (and it better be the case to begin with, if you really have C++ interfaces under Windows -- which for the same reason is often not really recommended). It also has advantages though, for example it is better for some plugin models (but again: not all - it depends on the interface design), and obviously it is way better to run even the most basic regular Win32 programs given how Windows is designed internally with sometimes 2 libC used at the same time and a fat and mandatory dynamic-only user space layer. If you use your own .dll Windows let you build programs that are not covered by the C or C++ standard models (e.g. multiple different C++ implementations used at the same time by a single program). The Windows design also has been influenced by the Win16 era, which had even more exotic requirements. The models are so different that people used to one usually focus on all the issues the other has, and internalize all the details to the point it can often affect their own design without thinking about it -- it also makes some programs (or even just libraries) harder to port from one system to the other.
• deleted 7y ago
  [deleted]