back
2 comments
Exactly. Windows 10 is a much better operating system than Linux for a broad range of applications, and the desktop. I develop on Windows 10, and am quite happy using a VM (not WSL) for my Centos development.
Are you talking about desktop applications? Windows 10 like every version of Windows going back to NT is built around a Hardware Abstraction Layer and separates userland from the kernel while providing a platform agnostic API. There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't which is my point. Why spend billions on R&D for something you can get for free? Case in point, MacOS/OSX. Apple figured that out a long time ago and it obviously worked for them.
> There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't

There is, for laptop/desktop: almost all of those run a Windows kernel thus most money for laptop/desktop device driver support is going towards supporting the Windows kernel. Technically... it's a difficult discussion but it's irrelevant. Noone is running a bare kernel.

The Linux Kernel is a 60s era monolithic architecture. Windows 10 is a modern microkernel. So, of course, the Linux "kernel" has more stuff in it. But that means that every driver and feature has to be carefully compiled in. It's no wonder there are far more audio, video, and specialized drivers on Windows 10.
Windows 10 is a hybrid kernel. https://stackoverflow.com/q/19365184/308851

Microsoft itself called the NT 3.1 kernel a "macrokernel". https://docs.microsoft.com/en-us/previous-versions//cc750820...

If you look at the Other Wiki, you will find even Mac OS is not a microkernel. http://wiki.c2.com/?MicroKernel

> XNU is not a MicroKernel, it is a kernel obtained by merging the Mach MicroKernel with parts of the BSD kernel and parts specific to Darwin, all running in kernel space.

OKL4 is the most widely deployed pure microkernel in Qualcomm phone modems and Apple's Secure Enclave coprocessor. It is possible OKL4 is the most widespread OS, in fact.

> There isn't anything the Windows kernel can do that the Linux or a BSD kernel can't which is my point.

Oh there is. Like pervasive ACLs on all kernel objects, e.g., processes. User-ids (SIDs) based on a distributed authority model rather than a simple int. Then there's asynchronous IO that's still not usable in Linux. Etc, etc...

What? Why would that be a factor? It's a kernel. Why would it make a difference if the Windows desktop ran on a different kernel? MS has rolled out several different kernels over the history of Windows, why would it be any different? Just like OP mentioned look at MS switching Edge to the Chromium backend. To the user there's isn't a real difference. It's still Edge.
Microsoft sell Windows partly on the promise of backwards compatibility. A Linux kernel would destroy any real backwards compatibility possibilities, with prejudice.

There are 1,000 privately developed and privately run Windows apps for every publicly available application, and those private applications are the backbone of businesses around the world. A Linux kernel would render a VERY large portion of those inoperable, even with WINE.

A Windows with a Linux kernel will never replace traditional Windows. Some Microsoft OS may live alongside traditional Windows, at some point however, and it is unlikely to be Linux at all.

There are lots of kernel architectures out there besides the ones that Linux and Windows use.

The Windows kernel isn't backwards compatible, just the API's which use compatibility libraries and the HAL to interface with the newer kernel. APIs and kernels are 2 different things. Think about the Linux kernel. How to we "talk" to it? Through libraries like glibc which provides an interface for C to make calls to the kernel. Something like WINE wouldn't be necessary. WINE is an open implementation of the Windows API. The WINE project is essentially reverse engineering the Windows API and mapping to the equivalent Linux syscalls. This wouldn't be an issue for MS. All they would have to do is implement a Windows API compatible equivalent of glibc and obviously wouldn't have licensing issues like the WINE project.
> Think about the Linux kernel. How to we "talk" to it? Through libraries like glibc which provides an interface for C to make calls to the kernel.

No. We "talk" to the kernel through an ABI, not an API. Maintaining ABI compatibility is important because you can move a binary from one kernel version to another without recompiling and relinking your app.

Except most of the unique features of Edge are gone. Maybe not all, but plenty of users will notice a difference in Edge when the Chromium version rolls out.

Plus, word on the street is Microsoft's motivation to move to Chromium was totally different to that: it was a performance decision. Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.

>Maybe not all, but plenty of users will notice

>Plus, word on the street is

Come on, don't just start spewing a bunch of weasel words. It's fine if you disagree me and I won't downvote you if you do (I never downvote people for that reason) but at least put some effort into it.

> Too many apps were using Electron, and the only way to improve their performance was to intregrate it into the OS.

Well why wouldn't they just build out the Edge backend to be compatible with node.js to natively support the Electron API? Because it a waste of time and R&D money when Chromium does all that already and more with minimal cost. Why reinvent the wheel when you can get a run-flat radial tire for free?

Did you see a different Edge developer preview than I did? The Chromium-based Edge that I have looks basically like Chromium. Firefox has a more native look than Dev Edge. But Windows is a bit of a hodge-podge, so maybe the user doesn't care.