IMO Microsoft has the money to hire very competent people, they could architect an OS from the ground up designed for the present day hardware using all the knowledge that appeared after UNIX and C was created. I would resurrect the C# based OS if you really want to start fresh with a new kernel.
Wine is great, but it is far off from being a substitute for Windows itself. There’s bound to be not just the obvious bugs and incompatibilities but also think of all of the edge cases that Microsoft have implemented fixes and workarounds for over the years. There is, IMO, simply no way that Wine could ever completely replace Windows on a global scale.
I think we've/they've been heading in this direction for a while. At least from a kernel perspective. All we need is a DirectX port now which is easy by kind of "reverse-reverse" engineering Wine and a compatibility layer.
I think behind the scenes this is WSL's true purpose.
This is never, ever, ever going to happen, and the reason is enterprise compliance. Every year, technical auditors will approve security policies that require Windows in all kinds of scenarios and definitively rule out use of Linux for any purpose.
Also, one of the promises of Windows is that they won't break backwards compatibility under any circumstance regardless of how buggy the behaviour (except number of bits, RIP 16-bit). Unmodified Windows 95 binaries will still run today as long as the appropriate DLLs are there.
I think 16-bit support is actually a limitation of x86 CPUs. They can only go into 16-but mode if they booted as 32-bit. A 64-bit CPU running in 64-bit mode is incapable of running 16-bit x86 code. It is not a software limitation. This can be demonstrated by installing 32-bit Windows and enabling 16-bit support.
Yeah, but if they REALLY wanted to, they could have emulated an 80268, it would have been plenty fast even in interpreted emulation. The whole NTVDM machine would fit in L1 cache.
You can support 16bit in long mode via compatibility mode (the bits are still in the Global descriptor table definition https://wiki.osdev.org/GDT as long as the long mode bit isn't set the, Sz bit can be used to indicate 16bit code), just not real mode without using virtualization extensions. The issue was more the way HANDLEs were managed and getting rid of 16bit limitations. (also getting programmers to stop assuming they could safely do things with the upper parts of handles)
No, it is possible to run 16 bit protected mode applications (i.e. Windows 3.x apps) under 64-bit "long mode". Microsoft explicitely chose to not support that -- with a few exceptions. In true Microsoft fashion, NTVDM on x86-64 is actually hardcoded to be able to run a couple of known InstallShield and Acme installer executables that are 16-bit but used to install 32-bit software.
WINE on Linux x86-64 will run 16-bit Windows programs, by the way.
However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. This would probably have broken a lot of 16-bit Windows software that still relied on real mode components, so it does make sense for this and other reasons that they dropped support for 16-bit software.
> However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs.
You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux.
But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.
I saw that module, looked at the code, and wondered if at that point it wouldn't be easier to just run a thin wrapper around the virtual 8086 code while just using standard virtualization extensions. That way it's just another KVM and not yet more kernel code to maintain. Because honestly QEMU already supports that target. This is of course ignoring the many issues caused by faster CPUs or things the target program is expecting but no longer exist or act differently on modern CPUs.
Well, there is a rather straightforward explanation: virtualization extensions did not exist, and in fact would not exist for another 5 years at least.
Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere).
Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).
This is solved by making Windows a subsystem of a Linux-based operating system. Much like Wine, but actually maintained by Microsoft, providing a completely isolated and bug-compatible environment for legacy apps, and a leaner implementation for future win32 APIs that map more closely to Linux primitives.
Pretty much the same way that early versions of Mac OS X could run “Classic” apps.
(It’s kind of remarkable how Apple was able to push their entire user base into a transition, and backward compatibility with that era is neither practical nor really desired. Not the case with Windows!)
Anyway, yeah, there are really no technical reasons why this couldn’t be done or even difficult, the reasons why this would never happen are all strategic and enterprisey.
Hilarious. Then they'd have to deal with the fact that they deliberately made their API calls to screw with Wine, and things like Crossover, during the late 90's and early 2000's.
Not really. They had a ton of programs that needed bug-for-bug compatibility.
Caring about getting SimCity2000 to run is a much more reasonable explanation than trying to protect themselves from Wine, which in the early 2000s was barely on anyone's radar.
For a LOT of us, at least in certain circles of power users, this is the only thing tying us to Windows. I have a fuckton of software that I know almost for sure that will run under the newest Windows... in Linux, yeah, maybe Wine likes it, or maye I'm out of luck.
For some of this software there are reasonable alternatives (emulators, for example. I care about the ROMs, and they are not tied to any operating system). Others, not so much (like my Winamp with 20+ input plugins, some of which can play audio files that I haven't found how to play in Linux, at least using a single player for all the formats). Admittedly, Windows' bullshit is making it harder and harder to justify compliance. I assume that at some time in the future I will finally switch and eschew all the bullshit of aggressively anti-user behaviour (ads, forced updates, changes in UI or in the default applications because of said forced updates, and so on) that Windows seems to love since 8 or so.
I know I'm not alone. If Windows gets rid of all this compatibility, there is no fucking way that users are going to accept it. Let Windows be Windows and Linux be Linux.
There is absolutely no way, if Windows was to switch to the Linux kernel, they'd base it on any existing distribution. That is hilariously panglossian. The result would be a weird fork like Android or ChromeOS.
This is more like fanfiction about Microsoft adopting the authors favorite stuff, just because.
I was trying to think of a way to sum up this blog post, and you nailed it. Fanfiction. That's all this is. "I like these Linux things, so Microsoft should throw away Windows and make it with these things."
That's not really a transition though. Windows applications aren't running on the WSL2 kernel. It's just making the use of the underlying hyperv more seamless.
It's closer to an IBM model, where they could care less what's running in an LPAR, and explicitly support Linux there, but the legacy stuff is what keeps the bills paid.
I couldn't care less about running Windows apps in WSL2. But I want full linux experience in the stifling corporate environment and Windows 11 is a notch closer to delivering it.
So far, I have to launch VcXsrv for Linux GUI apps. It works OK, but Windows network reconfiguration breaks connectivity once in a while.
This is nearly as absurd as that UserVoice thread where people clamor for full Visual Studio to be ported to linux. Never going to happen, don't waste a moment thinking about it.
If even half of those engineers are overseas, which I'd say it's highly likely (but I would like to know), it's even possible the average per year is lower than that.
Working on an operating system (or generally working on anything low-levelish) is not as enticing as many people seem to think it is.
I think if anything it's more likely that WSL/WSLg development continues to the point where you can do the inverse of all the VFIO stuff going on. Run Windows/Hyper-V as a base layer but boot directly into the linux DE of your choice. It's my understanding this is already similar to how WSL works.
Microsoft maintains dominance, at least partially, by backwards comparability. It would be hugely risky to break that. Also, why? What would the benefit be to Microsoft the corporation? By doing this they would only open the door to competition while simultaneously giving up control of their own kernel.
Because eventually the costs might offset the benefits. I'm not holding my breath -- they're going to milk Windows until the bitter end, that's for sure.
But never is a long time, even more so in a world where Windows on the server is such a joke not even MS believes in it and consumer products are tablets and smartphones, not desktops and laptops.
I'd ask "why" in the other direction. The benefit MS derives from Windows at this point is $0 per year. What still has a ton of value in 2021 is Windows compatibility, and they don't need the distraction of maintaining a full OS for that. Maybe it's easier to maintain compatibility by maintaining their own OS. There's clearly a benefit to giving it up though.
Will they? I believe they will - kind of. I think they'll make a Windows for cloud that is based on Linux. I think they'll still have the current Windows on the desktop stick around (at least for the now).
Right. I don't see why this is so far fetched. It gets MS/Windows branding/features on the machines, not some "other" Linux distro. Once people are using Windows only features, they can discontinue or raise prices or etc on the "other" linux distros.
It seems like you're talking about a Microsoft Cloud Linux distro, like Amazon Linux, rather than something related to Windows. Microsoft Linux makes sense, for similar reasons to Amazon Linux making sense. It doesn't relate to Windows, though.
Filesystem IO on windows is noticeably slower than on Linux (of course fixing Windows would also solve that, but they've had quite a while for that...)
As a Linux user for now 20 years, I think the author is under some kind of delusion that windows doesn't provide enough value to exist on its own.
I thus assume the autor must be very young, and has little experience with the reality of the corporate world, which loves:
- compatibility
- inertia
- deployment automation
- technical support
- strong legal support (compliance, contracts, DOD approval...)
- social proof (reputation, certification, etc)
- have a big player that can be held responsible
- predictability
Apple is not interested in it, Red Hat is not big enough, Google has desmontrated its incapability to do it, and so on. But MS provides all that, and better than any Unix shop in town.
It would be economically ridiculous to turn Windows into Linux and lose all that stuff.
Merging the two could happen if they manage to keep all their pieces of the pie, and I assume WSL is a first step in that direction.
I used to have this long running thing I would tell people - that eventually MS will rewrite Windows to run on-top of Linux.
I actually have completely changed my mind about it though. I don't think it will ever happen. Younger people see perfection as everything being similar. Older people appreciate the differences. I'm getting older.
One of the things that the Windows kernel does just better than Linux is providing a stable kABI. The argument against that is “just upstream/open source your driver”. Well that’s not always possible. I think this is honestly holding back hardware support in Linux. The ideologically driven FOSS folks can choose to only run open-source drivers, while those just wanting to get stuff done (like me) will happily run proprietary drivers. I understand this does undermine the purpose of the GPL so it will never happen.
Microsoft is starting to realize they need to re-invest in windows. The kernel is still considered more advanced than the Linux kernel, but it is all the other stuff that has issues. Windows is a complex beast that needs to be simplified. It would be better if Microsoft open-source the kernel, and kept everything else closed source. Like MacOS
I think the casual Linux user doesn't appreciate the sheer amount of engineering and forethought that went into the Windows NT parts of Windows. Say what you want about Win32 and its legacy, but NT was well thought-out by people who had significant experience (Dave Cutler and his team). Microsoft wouldn't ever walk away from that investment.
it'll happen, but as always with MS, the execution will be poor and it'll flop
MS needs to change its culture first, and replace all their managers including the product managers
then they can start to think of a future with a linux kernel (it's already the case for their azure stuff)
but by then, i doubt they'll still be around
the future will be free of computers, people will wear their PC, it already started with the smartphone, the next step will be the death sentence for MS
> This ridiculous complexity and scale highlight why Microsoft has historically struggled to deliver reliable feature updates for Windows 10, forcing them to drop “Windows as a Service”, moving to a more manageable yearly update schedule.
The author seems to have a distinct lack of understanding of windows codebase. They didn’t move away from windows as a service because of code complexity, they did it because businesses didn’t and don’t want a rapid release cycle for desktop, they want stability. And NOBODY wanted massive UI changes without a very clear version difference so they could move to the new UI when they were ready.
Windows as a service was a bad idea they properly course corrected on.
Furthermore, most of the code he’s referring to is up the stack and would presumably need to be ported to Linux unless they’re going to abandon all of their enterprise users and apps (they won’t). MinWin was only 25MB after all (yes I realize that isn’t a complete OS but it gives you an idea of how much space all the “other stuff” is taking up).
70 comments
[ 2.9 ms ] story [ 148 ms ] threadThe article also doesn't suggest how Windows would retain its legendary backward compatibility if it were to switch to a Linux base.
I think behind the scenes this is WSL's true purpose.
Also, one of the promises of Windows is that they won't break backwards compatibility under any circumstance regardless of how buggy the behaviour (except number of bits, RIP 16-bit). Unmodified Windows 95 binaries will still run today as long as the appropriate DLLs are there.
http://www.columbia.edu/~em36/ntvdmx64.html
https://github.com/leecher1337/ntvdmx64
http://www.columbia.edu/~em36/otvdm.html
https://en.wikipedia.org/wiki/SoftPC
WINE on Linux x86-64 will run 16-bit Windows programs, by the way.
However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. This would probably have broken a lot of 16-bit Windows software that still relied on real mode components, so it does make sense for this and other reasons that they dropped support for 16-bit software.
You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux.
But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.
Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere).
Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).
(It’s kind of remarkable how Apple was able to push their entire user base into a transition, and backward compatibility with that era is neither practical nor really desired. Not the case with Windows!)
Anyway, yeah, there are really no technical reasons why this couldn’t be done or even difficult, the reasons why this would never happen are all strategic and enterprisey.
Caring about getting SimCity2000 to run is a much more reasonable explanation than trying to protect themselves from Wine, which in the early 2000s was barely on anyone's radar.
The really important emphasis here is on "almost." The value is in "100%."
> and certainly much cleaner than whatever code DLLs written in the Windows ME era contain
"Cleaner" is not a benefit.
For some of this software there are reasonable alternatives (emulators, for example. I care about the ROMs, and they are not tied to any operating system). Others, not so much (like my Winamp with 20+ input plugins, some of which can play audio files that I haven't found how to play in Linux, at least using a single player for all the formats). Admittedly, Windows' bullshit is making it harder and harder to justify compliance. I assume that at some time in the future I will finally switch and eschew all the bullshit of aggressively anti-user behaviour (ads, forced updates, changes in UI or in the default applications because of said forced updates, and so on) that Windows seems to love since 8 or so.
I know I'm not alone. If Windows gets rid of all this compatibility, there is no fucking way that users are going to accept it. Let Windows be Windows and Linux be Linux.
This is more like fanfiction about Microsoft adopting the authors favorite stuff, just because.
They probably do have a very refined concept of clickbait though.
Full linux exprience on Windows Server Core is just one release away.
See https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-a...
It's closer to an IBM model, where they could care less what's running in an LPAR, and explicitly support Linux there, but the legacy stuff is what keeps the bills paid.
So far, I have to launch VcXsrv for Linux GUI apps. It works OK, but Windows network reconfiguration breaks connectivity once in a while.
https://developercommunity.visualstudio.com/t/visual-studio-...
lol?
Working on an operating system (or generally working on anything low-levelish) is not as enticing as many people seem to think it is.
But never is a long time, even more so in a world where Windows on the server is such a joke not even MS believes in it and consumer products are tablets and smartphones, not desktops and laptops.
Will they? I believe they will - kind of. I think they'll make a Windows for cloud that is based on Linux. I think they'll still have the current Windows on the desktop stick around (at least for the now).
even as someone who computes primarily on a linux desktop the idea feels silly to me
[1] https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines?...
I thus assume the autor must be very young, and has little experience with the reality of the corporate world, which loves:
- compatibility
- inertia
- deployment automation
- technical support
- strong legal support (compliance, contracts, DOD approval...)
- social proof (reputation, certification, etc)
- have a big player that can be held responsible
- predictability
Apple is not interested in it, Red Hat is not big enough, Google has desmontrated its incapability to do it, and so on. But MS provides all that, and better than any Unix shop in town.
It would be economically ridiculous to turn Windows into Linux and lose all that stuff.
Merging the two could happen if they manage to keep all their pieces of the pie, and I assume WSL is a first step in that direction.
Or maybe it's the embrace stage, I don't know.
I actually have completely changed my mind about it though. I don't think it will ever happen. Younger people see perfection as everything being similar. Older people appreciate the differences. I'm getting older.
MS needs to change its culture first, and replace all their managers including the product managers
then they can start to think of a future with a linux kernel (it's already the case for their azure stuff)
but by then, i doubt they'll still be around
the future will be free of computers, people will wear their PC, it already started with the smartphone, the next step will be the death sentence for MS
The author seems to have a distinct lack of understanding of windows codebase. They didn’t move away from windows as a service because of code complexity, they did it because businesses didn’t and don’t want a rapid release cycle for desktop, they want stability. And NOBODY wanted massive UI changes without a very clear version difference so they could move to the new UI when they were ready.
Windows as a service was a bad idea they properly course corrected on.
Furthermore, most of the code he’s referring to is up the stack and would presumably need to be ported to Linux unless they’re going to abandon all of their enterprise users and apps (they won’t). MinWin was only 25MB after all (yes I realize that isn’t a complete OS but it gives you an idea of how much space all the “other stuff” is taking up).