4 ms·

All of this is towards the goal of deprecating the NT-Kernel and work on it. Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows

All of this is towards the goal of deprecating the NT-Kernel and work on it. Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++). Rather than windows::nt or gnu::linux, the first "Linux on Desktop" will happen with windows::linux. In 2015 I bet my friends this would happen in 2025. It might not happen exactly that year, but all signs point towards before 2030.

ziml77 4y ago
> Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++). No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. But they ended up running into issues and limitations that made them change their approach. Now, with WSL2, they just have a virtualized instance of Linux running. This isn't even an odd choice as Windows has already been running on top of a hypervisor for anyone who has Hyper-V enabled (new installs of Windows 11 have it enabled by default to support Virtualization Based Security).
- skissane 4y ago
  > Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs WSL1 doesn’t implement the Linux syscall interface on top of the user-mode Win32 or NT APIs. Rather, it runs in-kernel; it calls kernel-mode NT APIs (only some of which directly correspond to NT syscalls), and (I assume) also implements some aspects of the Linux APIs internally to itself. Its approach is rather different from that of Wine or Cygwin, both of which translate one user-space API to another; and also from the legacy Windows OS/2 and POSIX/Interix/SFU/SUA subsystems, which implement those APIs mostly in user space, on top of the NT user-space API. WSL1 is essentially unique; the closest analog is probably the Linux syscall emulation in FreeBSD/NetBSD, Solaris10/Illumos LX branded zones, and the old Linux iBCS2 personality - although those are all far easier because there is much less mapping in emulating the Linux API on another POSIX OS than one fundamentally non-POSIX. > But they ended up running into issues and limitations that made them change their approach. I don’t think those issues were inherently insurmountable, and solving them in the context of WSL1 would have made Windows a better platform, since many of those issues (e.g. poor filesystem performance) also impact native Win32 apps. But, they made a decision on where to invest their resources. WSL2’s implementation strategy requires less engineering work overall to reach a given outcome.
  - ziml77 4y ago
    I specifically said NT APIs to differentiate from the Windows APIs. And my "just like WINE" comment was more to differentiate what they were doing with WSL1 from WSL2. My use of "just like" is too strong there. And I also don't think any of the problems were insurmountable. I'm still disappointed that they gave up on WSL1. (At least partially because I thought the whole Windows Subsystem concept was neat design)
    - skissane 4y ago
      > I specifically said NT APIs to differentiate from the Windows APIs. It depends on what you mean by "NT APIs". If you mean the NT API exposed to user-mode (NT syscalls), no, that is insufficient to implement WSL1 (or anything else like it). If you mean to include kernel-mode-only NT APIs (including undocumented/private APIs which MS doesn't expose to third parties, even new APIs added specifically for WSL1 to consume), then yes that is. > the whole Windows Subsystem concept was neat design Also worth keeping in mind, that WSL1 is not an "environment subsystem" in the sense that Win32 is – or OS/2 and POSIX/etc were. It has a radically different architecture from a classic Windows NT environment subsystem.
      - ziml77 4y ago
        Ah my mistake about the subsystem implementation. My memory was fuzzy given the 5+ years since I read Windows Internals 7th Edition. Thanks for the correction!
- yazaddaruvala 4y ago
  > No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. Uhh, I think you miss read my post. I agree with you WSL1 was a dead end. It tried to put Linux on top of NT. I believe MS will try to put Win32, etc on top of Native Linux APIs (removing NT entirely). WINE and Proton have effectively done 90% and MSFT will have a way simpler time of getting it to 100% given they dont have to worry about their own copyright. MSFT also has the financial motivation to stop developing the NT Kernel, so it’s valuable for them to invest into this “WINE++”.
  - skissane 4y ago
    I think it is unlikely even Microsoft would succeed in replacing the NT kernel with the Linux kernel. NT has features which Linux kernel devs have actively opposed including – such as alternate data stream support in its VFS/IFS layer, and a stable device driver ABI. So even supposing – and I'd be rather surprised if it were to ever actually happen – Microsoft were to release the NT kernel under a GPL-compatible license (thereby eliminating many of the legal issues), they still might find it a great struggle to get the necessary features upstreamed. Important parts of Windows – e.g. synchronisation primitives – cannot be emulated on top of the Linux syscall API as it currently exists (with accuracy and high performance), due to gaps in functionality. See https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5ad1d43@codeweavers.com/ https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a... for some of the gory details. I note that LKML message appears to have received zero replies, which is not an encouraging sign for any progress on that issue. > MSFT also has the financial motivation to stop developing the NT Kernel It would be a huge investment to extend the Linux kernel to be able to support a 100% correct and equal performance emulation of the NT API, and to port that API to run on top of it. Even with such a huge investment, there would be no guarantee of success (what if Linus refuses to upstream the required features?). And, if it legally requires open-sourcing large parts of the existing Windows kernel (due to GPL compatibility), that would greatly improve the viability of Wine/ReactOS/etc, threatening Microsoft's existing Windows revenue stream. The financial case for what you are proposing is far less clear than you think it is.
    - yazaddaruvala 4y ago

ziml77 4y ago

> Today they "emulate" Linux on Windows (WSL2), tomorrow they will "emulate" Windows on Linux (i.e. all the Win32, etc APIs on Linux - think WINE++). No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. But they ended up running into issues and limitations that made them change their approach. Now, with WSL2, they just have a virtualized instance of Linux running. This isn't even an odd choice as Windows has already been running on top of a hypervisor for anyone who has Hyper-V enabled (new installs of Windows 11 have it enabled by default to support Virtualization Based Security).

skissane 4y ago
> Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs WSL1 doesn’t implement the Linux syscall interface on top of the user-mode Win32 or NT APIs. Rather, it runs in-kernel; it calls kernel-mode NT APIs (only some of which directly correspond to NT syscalls), and (I assume) also implements some aspects of the Linux APIs internally to itself. Its approach is rather different from that of Wine or Cygwin, both of which translate one user-space API to another; and also from the legacy Windows OS/2 and POSIX/Interix/SFU/SUA subsystems, which implement those APIs mostly in user space, on top of the NT user-space API. WSL1 is essentially unique; the closest analog is probably the Linux syscall emulation in FreeBSD/NetBSD, Solaris10/Illumos LX branded zones, and the old Linux iBCS2 personality - although those are all far easier because there is much less mapping in emulating the Linux API on another POSIX OS than one fundamentally non-POSIX. > But they ended up running into issues and limitations that made them change their approach. I don’t think those issues were inherently insurmountable, and solving them in the context of WSL1 would have made Windows a better platform, since many of those issues (e.g. poor filesystem performance) also impact native Win32 apps. But, they made a decision on where to invest their resources. WSL2’s implementation strategy requires less engineering work overall to reach a given outcome.
- ziml77 4y ago
  I specifically said NT APIs to differentiate from the Windows APIs. And my "just like WINE" comment was more to differentiate what they were doing with WSL1 from WSL2. My use of "just like" is too strong there. And I also don't think any of the problems were insurmountable. I'm still disappointed that they gave up on WSL1. (At least partially because I thought the whole Windows Subsystem concept was neat design)
  - skissane 4y ago
    > I specifically said NT APIs to differentiate from the Windows APIs. It depends on what you mean by "NT APIs". If you mean the NT API exposed to user-mode (NT syscalls), no, that is insufficient to implement WSL1 (or anything else like it). If you mean to include kernel-mode-only NT APIs (including undocumented/private APIs which MS doesn't expose to third parties, even new APIs added specifically for WSL1 to consume), then yes that is. > the whole Windows Subsystem concept was neat design Also worth keeping in mind, that WSL1 is not an "environment subsystem" in the sense that Win32 is – or OS/2 and POSIX/etc were. It has a radically different architecture from a classic Windows NT environment subsystem.
    - ziml77 4y ago
      Ah my mistake about the subsystem implementation. My memory was fuzzy given the 5+ years since I read Windows Internals 7th Edition. Thanks for the correction!
yazaddaruvala 4y ago
> No. Microsoft tried to bridge the Linux APIs to NT APIs in WSL1 just like WINE does for Windows APIs to Linux APIs. Uhh, I think you miss read my post. I agree with you WSL1 was a dead end. It tried to put Linux on top of NT. I believe MS will try to put Win32, etc on top of Native Linux APIs (removing NT entirely). WINE and Proton have effectively done 90% and MSFT will have a way simpler time of getting it to 100% given they dont have to worry about their own copyright. MSFT also has the financial motivation to stop developing the NT Kernel, so it’s valuable for them to invest into this “WINE++”.
- skissane 4y ago
  I think it is unlikely even Microsoft would succeed in replacing the NT kernel with the Linux kernel. NT has features which Linux kernel devs have actively opposed including – such as alternate data stream support in its VFS/IFS layer, and a stable device driver ABI. So even supposing – and I'd be rather surprised if it were to ever actually happen – Microsoft were to release the NT kernel under a GPL-compatible license (thereby eliminating many of the legal issues), they still might find it a great struggle to get the necessary features upstreamed. Important parts of Windows – e.g. synchronisation primitives – cannot be emulated on top of the Linux syscall API as it currently exists (with accuracy and high performance), due to gaps in functionality. See https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5ad1d43@codeweavers.com/ https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a... for some of the gory details. I note that LKML message appears to have received zero replies, which is not an encouraging sign for any progress on that issue. > MSFT also has the financial motivation to stop developing the NT Kernel It would be a huge investment to extend the Linux kernel to be able to support a 100% correct and equal performance emulation of the NT API, and to port that API to run on top of it. Even with such a huge investment, there would be no guarantee of success (what if Linus refuses to upstream the required features?). And, if it legally requires open-sourcing large parts of the existing Windows kernel (due to GPL compatibility), that would greatly improve the viability of Wine/ReactOS/etc, threatening Microsoft's existing Windows revenue stream. The financial case for what you are proposing is far less clear than you think it is.
  - yazaddaruvala 4y ago