All MS is trying to do is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.
All MS is trying to do is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.
Eh? Even as a joke, I don't get it.
1. Download Visual Studio 2022 Community Edition
2. Select and install the workloads you need
3. Fire up any boilerplate from the Welcome menu
4. Press the green play button
Sure, it's no `pacman -S base-devel && g++ main.cpp && ./a.out`, but it's not as bad as everyone puts it.
It is a GUI-first operating system, and if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.
> All MS is trying to do [with WSL] is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.
> if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.
I said "least painful", not impossible. The scenario you describe here would be very painful.
On the contrary, it couldn't be easier. Visual Studio comes with a Windows XP platform toolset[1] that is a one-click install.
Compare, on the other hand, how ridiculously hard it is to develop targeting older glibc on a newer glibc host. There's no way around it except to use a Docker container (which IMO is equivalent to using a sledgehammer on a tiny nail).
[1]: https://learn.microsoft.com/en-us/cpp/build/configuring-prog...
And before that, some people might remember https://en.wikipedia.org/wiki/Virtual_PC#Windows_XP_Mode.
This is like, the primary reason to do this move. Wine has better compatibility for windows software than windows has now in my experience.