4 ms·

This comment is full of inaccuracies and mistakes, and is a terrible travesty of the Windows situation. > except of course you can't even combine some modules

This comment is full of inaccuracies and mistakes, and is a terrible travesty of the Windows situation. > except of course you can't even combine some modules compiled for debug with modules compiled without debug in the same executable. There's a good reason for this, which IMO Unix-like compilers and system libraries should start adopting, too. Debug and Release binaries like the standard C and C++ runtimes and libraries cannot be inter-mixed because they have have different ABIs. They have different ABIs because the former set of binaries have different type layouts, many of which come with debug-specific assertions and tests like bounds-checking, exception try-catch, null-dereference tests, etc. > The Windows problem has always been so so much worse that pretty much all developers simple resorted to shipping the OS system runtime with every package and it's just expected nowadays. This is not true at all. There are several layers to the counterargument. Firstly, UCRT has supplanted MSVCRT since Visual Studio 2015, which is a decade old this year. Additionally, UCRT can be statically linked: use `/MT` instead of `/MD`. And linking back to the previous quote, to statically link a debug CRT, use `/MTd`. Set this up in MSBuild or CMake using release/debug build configurations. UCRT is available for install (and maintained with Windows Update) in older versions of Windows going back to Vista. Next, Windows by default comes with several versions of C++ redistributables going back to Visual Studio 2005. All of these redistributables are also regularly maintained with Windows Update. Finally, Windows SDK versions targeting various versions of Windows are available for all supported Visual Studio developer environments. The oldest currently available in Visual Studio 2022 is Windows XP SP3[1]. These all serve to thoroughly solve both combinations of backward-forward compatibility, where (a) the runtime environment is newer than the developer environment, and (b), the runtime environment is older than the developer environment. It is perfectly possible to compile a single `.exe` on Visual Studio 2022 in Windows 11, and expect it to run on Windows XP SP3, and the vice versa: compile a single `.exe` on Visual Studio 6, and expect it to run on Windows 11. No dynamic libraries, no DLLs, nothing; just a naked `.exe`. Download from website, double-click to run. That's it. No git clone, no GNU Autotools, no configure, no make, no make install (and then f*cking with rpaths), nothing. Prioritising binary-only software distribution means Windows has prioritised the end-user experience. > It's where the phrase "DLL hell" originated, after all. This is also incorrect. 'DLL hell' is a pre-NT problem that originated when packagers decided it was a good idea to overwrite system binaries by installing their own versions into system directories[2]. Sure, the versioning problem was there too, but this is itself a result of the aforementioned DLL stomping. [1]: https://learn.microsoft.com/en-us/cpp/build/configuring-programs-for-windows-xp?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/configuring-prog... [2]: https://en.wikipedia.org/wiki/DLL_Hell#DLL_stomping https://en.wikipedia.org/wiki/DLL_Hell#DLL_stomping I fully daresay writing C and C++ for Windows is an easier matter than targeting any Unix-like. For context, see what video game developers and Valve have done to check off the 'works on Linux' checkbox: glibc updates are so ridiculously painful that Valve resorted to simply patching WINE and releasing it as Proton, and WINE is the ABI target for video games on Linux.

jraph 2y ago
That Windows is generally better at handling compatibility is one thing, but I'm curious about the following part: > There's a good reason for this, which IMO Unix-like compilers and system libraries should start adopting, too. Why? I'm understanding from your comment that you can't mix debug and release objects on Windows because the ABI is different. That's not a feature, that's a limitation. If it works on Linux to mix debug-enabled objects with "release", what use would it have to make it not work anymore? IIUC debug symbols can be totally separated from the object code, such that you can debug the release if you download the debug symbols. A well configured GDB on distros that offer this feature is able to do it automatically for you. It seems very useful and elegant. Why can't Windows do something like this and how is it an advantage? (Genuine question, I have a remote idea on how ELF works (wrote a toy linker), not much how DWARF works, and not the slightest idea on how all this stuff works on Windows)
- delta_p_delta_x 2y ago
  There's a bit of a conflation here; partially my fault. Allow me to clarify... To generate debug symbols for a given binary (whether executable or library) on Windows and MSVC's cl.exe (and Clang on Windows), compile with `/DEBUG`[1] and one of `/Z7`, `/Zi`, or `/ZI`[2]. This is equivalent to `-g` on Linux gcc/clang. In particular, `/Z7` generates separate `.pdb` files, which contain debug symbols for the binary in question. The options that the parent commenter and I were discussing, i.e. `/MD`, `/MDd`, /MT`, and `/MTd`[3] have to do with the C and C++ runtime link configuration. These correspond to multithreaded dynamic, multithreaded dynamic debug, multithreaded static, and multithreaded static debug respectively. Therefore, the small `d` refers to debug versions of the C and C++ runtimes. The differences between the debug and release versions of the C and C++ runtimes are listed in the following links[4][5][6][7][8]. The last link in particular demonstrates the debug CRT's functionality. Conventionally on Windows, debug binaries are linked to the debug versions of the C and C++ runtimes; ergo the requirement that 'Release and Debug binaries on Windows cannot be combined'. This convention is respected by all maintainers who release binary libraries on Windows. There is no equivalent on Unix-likes: it'd be like having 'debug' versions of libc.so.6/libstdc++.so/libc++.so/libpthread.so with different ABIs. If you wanted to change between release/debug here, you would have to at least re-link (if not re-compile) everything. Imagine having `-cstdlib=libc-debug` and `stdlib=libc++-debug` options. Both sets of options (debug symbol options and C runtime link options) are orthogonal, and may be freely combined. Hence, it is perfectly possible to link the debug versions of the C and C++ runtimes to a 'release' executable, although it would be pretty weird. For instance, `/O2 /LTCG /arch:AVX2 /MTd`. Equivalent imaginary GNU-style command: `-O3 -flto=thin -march=x86-64-v3 -cstdlib=libc-debug stdlib=libc++-debug -static`. You can see what I mean, I hope. [1]: https://learn.microsoft.com/en-gb/cpp/build/reference/debug-generate-debug-info?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/debug-... [2]: https://learn.microsoft.com/en-gb/cpp/build/reference/z7-zi-zi-debug-information-format?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/z7-zi-... [3]: https://learn.microsoft.com/en-gb/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/md-mt-... [4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/c-run-time-library-reference?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/c-ru... [5]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-library-features?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-... [6]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/debug-routines?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/debu... [7]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/run-time-error-checking?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/run-... [8]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-debugging-techniques?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-...

jraph 2y ago

That Windows is generally better at handling compatibility is one thing, but I'm curious about the following part: > There's a good reason for this, which IMO Unix-like compilers and system libraries should start adopting, too. Why? I'm understanding from your comment that you can't mix debug and release objects on Windows because the ABI is different. That's not a feature, that's a limitation. If it works on Linux to mix debug-enabled objects with "release", what use would it have to make it not work anymore? IIUC debug symbols can be totally separated from the object code, such that you can debug the release if you download the debug symbols. A well configured GDB on distros that offer this feature is able to do it automatically for you. It seems very useful and elegant. Why can't Windows do something like this and how is it an advantage? (Genuine question, I have a remote idea on how ELF works (wrote a toy linker), not much how DWARF works, and not the slightest idea on how all this stuff works on Windows)

delta_p_delta_x 2y ago
There's a bit of a conflation here; partially my fault. Allow me to clarify... To generate debug symbols for a given binary (whether executable or library) on Windows and MSVC's cl.exe (and Clang on Windows), compile with `/DEBUG`[1] and one of `/Z7`, `/Zi`, or `/ZI`[2]. This is equivalent to `-g` on Linux gcc/clang. In particular, `/Z7` generates separate `.pdb` files, which contain debug symbols for the binary in question. The options that the parent commenter and I were discussing, i.e. `/MD`, `/MDd`, /MT`, and `/MTd`[3] have to do with the C and C++ runtime link configuration. These correspond to multithreaded dynamic, multithreaded dynamic debug, multithreaded static, and multithreaded static debug respectively. Therefore, the small `d` refers to debug versions of the C and C++ runtimes. The differences between the debug and release versions of the C and C++ runtimes are listed in the following links[4][5][6][7][8]. The last link in particular demonstrates the debug CRT's functionality. Conventionally on Windows, debug binaries are linked to the debug versions of the C and C++ runtimes; ergo the requirement that 'Release and Debug binaries on Windows cannot be combined'. This convention is respected by all maintainers who release binary libraries on Windows. There is no equivalent on Unix-likes: it'd be like having 'debug' versions of libc.so.6/libstdc++.so/libc++.so/libpthread.so with different ABIs. If you wanted to change between release/debug here, you would have to at least re-link (if not re-compile) everything. Imagine having `-cstdlib=libc-debug` and `stdlib=libc++-debug` options. Both sets of options (debug symbol options and C runtime link options) are orthogonal, and may be freely combined. Hence, it is perfectly possible to link the debug versions of the C and C++ runtimes to a 'release' executable, although it would be pretty weird. For instance, `/O2 /LTCG /arch:AVX2 /MTd`. Equivalent imaginary GNU-style command: `-O3 -flto=thin -march=x86-64-v3 -cstdlib=libc-debug stdlib=libc++-debug -static`. You can see what I mean, I hope. [1]: https://learn.microsoft.com/en-gb/cpp/build/reference/debug-generate-debug-info?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/debug-... [2]: https://learn.microsoft.com/en-gb/cpp/build/reference/z7-zi-zi-debug-information-format?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/z7-zi-... [3]: https://learn.microsoft.com/en-gb/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/build/reference/md-mt-... [4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/c-run-time-library-reference?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/c-ru... [5]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-library-features?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-... [6]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/debug-routines?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/debu... [7]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/run-time-error-checking?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/run-... [8]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-debugging-techniques?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/crt-...