Interesting. I've been pretty happy with all the Unix-related updates they've put out lately. WSL has been a godsend and the new terminal and powershell have worked a treat. Glad they seem to be continuing with it.
My theory is that Microsoft is working on eventually moving Windows over to the Linux kernel, and all these things they are doing are setting the stage and preparing for an easier transition.
This comment reminds me of the GIF of Michael Scott screaming 'NO GOD PLEASE NO'[1].
It also tells me that anyone who makes this comment has limited exposure to comparative kernel development. I've always said it, I'll say it now, and I'll say it in the future: the NT kernel is by far the best part of Windows, and it is in many ways superior to the Linux kernel. Furthermore, Windows ships with an absolute metric ton of very nice userspace technologies that either a) don't exist on Linux, or b) are rubbish to use on Linux.
I don't understand why people want everything to converge on the Linux kernel and its userspace. I like open-source as much as everyone else, but 'let's make ALL the things GNU/Linux!' just leads to lack of competition and therefore stagnation and no innovation.
I have a better wish: Microsoft should open-source core Windows technologies, and eventually, the NT kernel itself. Then, it could maintain its official Microsoft® Windows™ distribution with support contracts, while allowing developers to compile and modify WindowsOpen. Something like what it currently does with VS Code.
Those folks fail to understand that if that ever happens, it will be a macOS UNIX like experience, or Android/Linux, or ChromeOS/Linux, not a Stalmman's GNU/Linux one.
As I said on the other post, I strongly doubt that. It offers few benefits and many roadblocks. It would be a monstrous amount of work, would throw into question many existing security-related certifications, break Microsoft's love of backwards-compatibility, etc.
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.
> the least painful way to develop for Windows on Windows is to just use Linux
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.
> 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).
I have been continually disappointed that Microsoft has not released a seamless Windows virtualization system. WindowsX would run the new, redesigned APIs, but all of the legacy could run inside a sandboxed system to give the world the required decades to finally transition.
This! I won't buy a Windows OS to run stuff because rebooting is annoying and I end up rarely ever actually dual booting. But I'd pay good money for a Windows Classic library on Linux.
It’s basically what Apple did when moving from OS 9 to OS X. Old applications would load up in Classic, allowing users to start using the new system, while developers had time to update their apps.
It's also far easier to port an old Windows application to run on modern Windows, or write a program on modern Windows targeting old Windows, than it is to do any of this on Linux.
