4 ms·
>It starts by not looking into Windows through UNIX developer glasses. People don't need any UNIX biases to just want multiple versions of MSVS to work the way
by jasode 8mo ago
>It starts by not looking into Windows through UNIX developer glasses.
People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version.
But every time, the new version of VS has a bug in the install somewhere that changes something that breaks old projects. It doesn't break for everybody or for all projects but it's always a recurring bug report with new versions. VS2019 broke something in existing VS2017 installs. VS2022 broke something in VS2019. etc.
The "side-by-side-installs-is-supposed-to-work-but-sometimes-doesn't" tradition continues with the latest VS2026 breaking something in VS2022. E.g. https://github.com/dotnet/sdk/issues/51796 https://github.com/dotnet/sdk/issues/51796
I once installed VS2019 side-by-side with VS2017 and when I used VS2017 to re-open a VS2017 WinForms project, it had red squiggly lines in the editor when viewing cs files and the build failed. I now just install different versions of MSVS in totally separate virtual machines to avoid problems.
I predict that a future version VS2030 will have install bugs that breaks VS2026. The underlying issue that causes side-by-side bugs to re-appear is that MSVS installs are integrated very deeply into Windows. Puts files in c:\windows\system32, etc. (And sometimes you also get the random breakage with mismatched MSVCRT???.DLL files) To avoid future bugs, Microsoft would have to re-architect how MSVS works -- or "containerize" it to isolate it more.
In contrast, gcc/clang can have more isolation without each version interfering with each other.
I'm not arguing this thread's msvcup.exe tool is necessary but I understand the motivations to make MSVS less fragile and more predictable.
- torginus 8mo agoNote that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers. That's why docker build environments are a thing - even on Windows. Build scripts are complex, and even though I'm pretty sure VS offers pretty good support for having multiple SDK versions at the same time (that I've used), it only takes a single script that wasn't written with versioning in mind, to break the whole build.
- skissane 8mo ago> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers. But this isn’t true. Many distros package major versions of GCC/LLVM as separate packages, so you install and use more than one version in parallel, no Docker/etc required It can indeed be true for some things-such as the C library-but often not for the compilers
- torginus 8mo agoThe closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.
- skissane 8mo agoTo give a concrete example of what I was talking about, RHEL has “gcc-toolset” for installing multiple GCC versions in parallel: https://developers.redhat.com/articles/2025/04/16/gcc-and-gcc-toolset-versions-rhel-explainer https://developers.redhat.com/articles/2025/04/16/gcc-and-gc...
- torginus 8mo agothis seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/ and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.
- skissane 8mo agoIn RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9. In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions) e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux. Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)