5 ms·

Hmm. The MSVCRT.DLL/MSVCRTD.DLL not being binary compatible between releases of Visual Studio is the same thing, except of course you can't even combine some mo

by bregma 2y ago

Hmm. The MSVCRT.DLL/MSVCRTD.DLL not being binary compatible between releases of Visual Studio is the same thing, except of course you can't even combine some modules compiled for debug with modules compiled without debug in the same executable. 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. It's where the phrase "DLL hell" originated, after all. Not to say the ABI problem isn't real if you want to combine binary packages from different Linux-based OSes. Plenty of solutions for that have cropped up as well: containers, flatpacks, snaps, the list goes on.

forrestthewoods 2y ago
> The Windows problem has always been so so much worse Hard, hard disagree. The problems are somewhat comparable. But if any platform is more painful it's Linux. Although they're similar if you exclude glibc pain. At least in my personal experience of writing lots of code that needs to run on win/mac/linux/android. > pretty much all developers simple resorted to shipping the OS system runtime with every package Meanwhile Linux developers have resorted to shipping an entire OS via docker to run every program. Because managing Linux environment dependencies is so painful you have to package the whole system. Needing to docker to simply launch a program is so embarrassing. > except of course you can't even combine some modules compiled for debug with modules compiled without debug in the same executable That's not any different on Linux. That has more to do with C++.
- graemep 2y ago
  > Meanwhile Linux developers have resorted to shipping an entire OS via docker to run every program. > Needing to docker to simply launch a program is so embarrassing. I have never needed docker "just to launch a program". Docker makes it easy to provide multiple containerised copies of an identical environment. Containers are a light alternative to VM images. I assume you find the existence of Windows containers just as embarrassing? https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/ https://learn.microsoft.com/en-us/virtualization/windowscont...
  - forrestthewoods 2y ago
    > Docker makes it easy to provide multiple containerised copies of an identical environment. Correct. The Linux architecture around a global of dependencies is, imho, bad and wrong. The thesis is it's good because you can deploy a security fix to libfoo.so just once for the whole system. However we now live in a world where you actually need to deploy the updated libfoo.so to all your various hierarchical Docker images. sad trombone > Containers are a light alternative to VM images. A light alternative to Docker is simply deploy your dependencies and not rely on a fragile, complicated global environment. > I assume you find the existence of Windows containers just as embarrassing? Yes. I know my opinion is deeply unpopular. But I stand by it! Running a program should be as simple as downloading a zip, extracting, and running the executable. It's not hard!
    - LtWorf 2y ago
      I guess your software is not libre, right? In that case, I think you should stick to snap and flatpak.
    - rixed 2y ago
      I wish you all had experienced the golden age when running a program was as simple as apt-get install program and run it. I find it hard to discuss the merits of Linux va windows with regard to deploying software without addressing the elephant in the room which is the replacement of a collectively maintained system that ensure software cohabitation by the modern compartmentalised collection of independent programs.
      - anthk 2y ago
        Flatpak it's fine. For serious reprocibility and unmatched software instalations, guix.
    - graemep 2y ago
      > Correct. The Linux architecture around a global of dependencies is, imho, bad and wrong. The thesis is it's good because you can deploy a security fix to libfoo.so just once for the whole system. However we now live in a world where you actually need to deploy the updated libfoo.so to all your various hierarchical Docker images. sad trombone Only if you choose to use docker. As other people have pointed out most things on Linux can be deployed using a package manager. > A light alternative to Docker is simply deploy your dependencies and not rely on a fragile, complicated global environment. So like flatpak? > I know my opinion is deeply unpopular. But I stand by it! Running a program should be as simple as downloading a zip, extracting, and running the executable. It's not hard! How is that better than apt install? That (or equivalent on other distros) is how I install everything other than custom code on servers (that I git pull or similar).
- fullspectrumdev 2y ago
  Instead of Docker, static linking is a much more elegant solution if library/dep management is painful. Switching to static linking using a sane libc (not glibc) can be a pain initially but you end up with way less overhead IMO.
  - munchler 2y ago
    Static linking is a good way to avoid the problem, but I’d hardly call it “elegant” to replicate the same runtime library in every executable. It’s very wasteful - we’re just fortunate to have enough storage these days to get away with it.
    - forrestthewoods 2y ago
      > I’d hardly call it “elegant” to replicate the same runtime library in every executable. It’s very wasteful - we’re just fortunate to have enough storage these days to get away with it. I think you need to quantify "very wasteful". Quite frankly it's actually just fine. Totally fine. Especially when the alternative has turned out to be massive Docker images! So the alternative isn't actually any better. Womp womp. An actually elegant solution would be a copy-on-write filesystem that can deduplicate. It'd be the best of both worlds.
  - jcelerier 2y ago
    > Switching to static linking using a sane libc (not glibc) can be a pain initially but you end up with way less overhead IMO. how does that work when you app needs access to the gpu drivers ?
- gpderetta 2y ago
  Containers are a relatively recent phenomenon. Outside of distro packages, distributing statically linked binaries, dynamic binaries wrapped in LD_LIBRARY_PATH scripts or binaries using $ORIGIN based rpath are all options I have seen.
delta_p_delta_x 2y ago
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.

by bregma 2y ago

forrestthewoods 2y ago

> The Windows problem has always been so so much worse Hard, hard disagree. The problems are somewhat comparable. But if any platform is more painful it's Linux. Although they're similar if you exclude glibc pain. At least in my personal experience of writing lots of code that needs to run on win/mac/linux/android. > pretty much all developers simple resorted to shipping the OS system runtime with every package Meanwhile Linux developers have resorted to shipping an entire OS via docker to run every program. Because managing Linux environment dependencies is so painful you have to package the whole system. Needing to docker to simply launch a program is so embarrassing. > except of course you can't even combine some modules compiled for debug with modules compiled without debug in the same executable That's not any different on Linux. That has more to do with C++.

graemep 2y ago
> Meanwhile Linux developers have resorted to shipping an entire OS via docker to run every program. > Needing to docker to simply launch a program is so embarrassing. I have never needed docker "just to launch a program". Docker makes it easy to provide multiple containerised copies of an identical environment. Containers are a light alternative to VM images. I assume you find the existence of Windows containers just as embarrassing? https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/ https://learn.microsoft.com/en-us/virtualization/windowscont...
- forrestthewoods 2y ago
  > Docker makes it easy to provide multiple containerised copies of an identical environment. Correct. The Linux architecture around a global of dependencies is, imho, bad and wrong. The thesis is it's good because you can deploy a security fix to libfoo.so just once for the whole system. However we now live in a world where you actually need to deploy the updated libfoo.so to all your various hierarchical Docker images. sad trombone > Containers are a light alternative to VM images. A light alternative to Docker is simply deploy your dependencies and not rely on a fragile, complicated global environment. > I assume you find the existence of Windows containers just as embarrassing? Yes. I know my opinion is deeply unpopular. But I stand by it! Running a program should be as simple as downloading a zip, extracting, and running the executable. It's not hard!
  - LtWorf 2y ago
    I guess your software is not libre, right? In that case, I think you should stick to snap and flatpak.
  - rixed 2y ago
    I wish you all had experienced the golden age when running a program was as simple as apt-get install program and run it. I find it hard to discuss the merits of Linux va windows with regard to deploying software without addressing the elephant in the room which is the replacement of a collectively maintained system that ensure software cohabitation by the modern compartmentalised collection of independent programs.
    - anthk 2y ago
      Flatpak it's fine. For serious reprocibility and unmatched software instalations, guix.
  - graemep 2y ago
    > Correct. The Linux architecture around a global of dependencies is, imho, bad and wrong. The thesis is it's good because you can deploy a security fix to libfoo.so just once for the whole system. However we now live in a world where you actually need to deploy the updated libfoo.so to all your various hierarchical Docker images. sad trombone Only if you choose to use docker. As other people have pointed out most things on Linux can be deployed using a package manager. > A light alternative to Docker is simply deploy your dependencies and not rely on a fragile, complicated global environment. So like flatpak? > I know my opinion is deeply unpopular. But I stand by it! Running a program should be as simple as downloading a zip, extracting, and running the executable. It's not hard! How is that better than apt install? That (or equivalent on other distros) is how I install everything other than custom code on servers (that I git pull or similar).
fullspectrumdev 2y ago
Instead of Docker, static linking is a much more elegant solution if library/dep management is painful. Switching to static linking using a sane libc (not glibc) can be a pain initially but you end up with way less overhead IMO.
- munchler 2y ago
  Static linking is a good way to avoid the problem, but I’d hardly call it “elegant” to replicate the same runtime library in every executable. It’s very wasteful - we’re just fortunate to have enough storage these days to get away with it.
  - forrestthewoods 2y ago
    > I’d hardly call it “elegant” to replicate the same runtime library in every executable. It’s very wasteful - we’re just fortunate to have enough storage these days to get away with it. I think you need to quantify "very wasteful". Quite frankly it's actually just fine. Totally fine. Especially when the alternative has turned out to be massive Docker images! So the alternative isn't actually any better. Womp womp. An actually elegant solution would be a copy-on-write filesystem that can deduplicate. It'd be the best of both worlds.
- jcelerier 2y ago
  > Switching to static linking using a sane libc (not glibc) can be a pain initially but you end up with way less overhead IMO. how does that work when you app needs access to the gpu drivers ?
gpderetta 2y ago
Containers are a relatively recent phenomenon. Outside of distro packages, distributing statically linked binaries, dynamic binaries wrapped in LD_LIBRARY_PATH scripts or binaries using $ORIGIN based rpath are all options I have seen.

delta_p_delta_x 2y ago

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.