3 ms·

On the contrary, they’ve been adding new features which bring it closer to POSIX in capabilities - for example, various Windows 10 builds introduced Unix domain

On the contrary, they’ve been adding new features which bring it closer to POSIX in capabilities - for example, various Windows 10 builds introduced Unix domain sockets, a pseudoterminal API, proper UTF-8 support, POSIX file delete semantics, etc. The pain of porting software from Linux/macOS to Windows has been reduced (significantly for some types of apps) and here’s to hoping they reduce it even further.

anonymoushn 4y ago
Maybe they'll ship a usable version of huge pages so that ~all software can go like 10% faster someday. We've waited like 26 years so far.
- jiggawatts 4y ago
  SQL Server has been able to do that on Windows for about a decade now. Just grant the “Lock pages in memory” privilege to the service account and it’ll do it automatically if the server has 16 GB of memory or more. I use it as a free 15% go-faster button in my consulting gigs.
  - anonymoushn 4y ago
    The current implementation is ok for programs that start soon after boot, run as root, and never exit, but even for server workloads there is a lot of other software out there.
yazaddaruvala 4y ago
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)

anonymoushn 4y ago

Maybe they'll ship a usable version of huge pages so that ~all software can go like 10% faster someday. We've waited like 26 years so far.

jiggawatts 4y ago
SQL Server has been able to do that on Windows for about a decade now. Just grant the “Lock pages in memory” privilege to the service account and it’ll do it automatically if the server has 16 GB of memory or more. I use it as a free 15% go-faster button in my consulting gigs.
- anonymoushn 4y ago
  The current implementation is ok for programs that start soon after boot, run as root, and never exit, but even for server workloads there is a lot of other software out there.

yazaddaruvala 4y ago

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)