It starts by not looking into Windows through UNIX developer glasses.

The only issue currently plaguing Windows development is the mess with WinUI and WinAppSDK since Project Reunion, however they are relatively easy to ignore.

▲

jasode 2 hours ago | parent | next [-]

>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

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 2 hours ago | parent [-]

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.

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 2 hours ago | parent [-]

> 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 2 hours ago \| parent \| next [-]
		The 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.
	▲	pjmlp 2 hours ago \| parent \| prev [-]
		Until the day there is that symlink, or environment variable with the incorrect value.

▲

dgxyz 3 hours ago | parent | prev [-]

Yes. Any user interface toolkit that isn't at least 10 years old should be ignored on windows unless you want to rewrite everything one day.

▲

viraptor 3 hours ago | parent | next [-]

Why? You may end up with something that doesn't get much attention anymore, but none of the official gui approaches have ever been removed as far as I know. Win32, MFC, winforms, wpf, winui, maui are all still available and apps using them are functional. Even winjs still works apparently, even if it was handed over.

I wouldn't start an app in most of them today, but I wouldn't rewrite one either without a good reason.

	▲	dgxyz 3 hours ago \| parent [-]
		Well a number of them have horrific bugs in them which have zero attention. At least win32 has an abstraction level which allows you to work around them. There’s a fun bug on WPF and form backgrounds for example which means on fractional DPI screens the background is tiled unpredictably. Had to patch that one up rather quickly one day and it was a mess due to how damn complicated WPF is.

▲

glimshe 3 hours ago | parent | prev [-]

I wonder if people still use WinForms, MFC and WPF...

▲

marcosdumay 20 minutes ago | parent | next [-]

I'd guess WinForms is still the most popular widget library in Windows.

▲

shigawire 3 hours ago | parent | prev | next [-]

Still migrating an enterprise app off WPF to this day.

	▲	dgxyz 3 hours ago \| parent [-]
		What are you moving to out of interest? I’ve seen people talking of moving ours to Electron which seems to just be more problems waiting.

▲

pjmlp 2 hours ago | parent | prev | next [-]

They certainly do.

▲

dgxyz 3 hours ago | parent | prev [-]

We still use win32!

(granted we made our own MFC around it)