5 ms·

> In addition, for several years now, Microsoft's WSL developers have been working on mapping Linux API calls to Windows and vice-versa. A lot of the work neede

by geofft 8y ago

> In addition, for several years now, Microsoft's WSL developers have been working on mapping Linux API calls to Windows and vice-versa. A lot of the work needed for Windows apps to run without modification on Linux has already been done. This argument makes little sense: that "vice versa" is wholly unsubstantiated and without it the rest collapses. Making Linux binaries work on NT (which already has a subsystem concept; Interix proved that this could be done) in a way where they interact little with the Windows desktop, and making not just NT binaries but Win32 binaries work smoothly on Linux, are almost entirely unrelated problems. It is true that MS owns the code necessary to make this happen, that WINE is an existence proof that it can be done shockingly well even without that code, and that there is both code and expertise at MS for stuffing Linux concepts and NT concepts in the same kernel. But that's about it.

halbritt 8y ago
The existence of MSSQL-Linux is proof that Microsoft can get this done. The story is pretty interesting: https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-server-on-linux-how-introduction/ https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-se...
- oaiey 8y ago
  Just that a database server is a very specific thing. Own memory handling, own file system handling, own scheduling, ... . The core of these systems give a shit about the operating system.
  - kerng 8y ago
    It's even more so true. The complexity of kernel calls is much higher when custom memory and scheduler involved I'd say. Getting Office running is probably rather simple in comparison.
    - jcelerier 8y ago
      > The complexity of kernel calls is much higher when custom memory and scheduler involved I'd say I really don't think so. MS used to render scrollbars in the kernel (was still the case in early Win10 versions)
      - geofft 8y ago
        I believe TrueType fonts are still rendered in kernel mode. (They have a policy option for blocking untrusted fonts, because of course that parser has bugs.)
        ryuuchin 8y ago
        Although the rendering may still be done in kernel mode the parsing is now done in a usermode sandbox[1] which significantly reduces risks from handling untrusted fonts. [1] https://blogs.technet.microsoft.com/secguide/2017/06/15/dropping-the-untrusted-font-blocking-setting/ https://blogs.technet.microsoft.com/secguide/2017/06/15/drop...
    - mrweasel 8y ago
      MSSQL is basically a small OS, it uses very few system calls, around 50 if I remember the Microsoft presentation correctly. That’s not to say that porting was easy, but rely very little on the underlaying OS. Porting Office is most likely much more work, just to get the GUI working.
  - halbritt 8y ago
    No argument that a desktop environment and a database server are different things. It'd be hard to judge which is a more complex task. Even still, read the story about how they built an OS abstraction layer on top of Windows and Linux and then ported their product to it. That was an impressive feat and an perfect example of Microsoft doing something (maybe only this one thing) right. Unlike Office on Mac which was a piece of shit for very many years and a very different product than Office on Windows.
    - oaiey 8y ago
      Oh I did. I followed WSL and MSSQL development strategies a lot. Cool stuff.
- geofft 8y ago
  Oh yeah, that's a pretty good point. There's no GUI involved, though... but another good example is Internet Explorer for UNIX, which used a third-party WINE-like product from the mid-'90s. https://en.m.wikipedia.org/wiki/Internet_Explorer_for_UNIX https://en.m.wikipedia.org/wiki/Internet_Explorer_for_UNIX But even then, that was with source access to IE. I definitely believe MS has the skills to make a binary-level implementation of Win32 on Linux happen. I just don't think it will be easy.
lukeh 8y ago
Interix was a better POSIX subsystem; it took until WSL to actually be able to run Linux binaries on NT.
unixhero 8y ago
NT has the capabilities to run different API "Personalities". This was pretty major. WIN32 was only one of the APIs NT supported. IBM also did the same with Workplace OS, but it failed. NT could have been a lot of things, if the competitive landscape was different. From Wikipedia: A main design goal of NT was hardware and software portability. Various versions of NT family operating systems have been released for a variety of processor architectures, initially IA-32, MIPS, and DEC Alpha, with PowerPC, Itanium, x86-64 and ARM supported in later releases. The idea was to have a common code base with a custom Hardware Abstraction Layer (HAL) for each platform. However, support for MIPS, Alpha, and PowerPC was later dropped in Windows 2000. Broad software compatibility was achieved with support for several API "personalities", including Windows API, POSIX,[11] and OS/2 APIs[12] – the latter two were phased out starting with Windows XP.[13] Partial MS-DOS compatibility was achieved via an integrated DOS Virtual Machine – although this feature is being phased out in the x86-64 architecture.[14] NT supported per-object (file, function, and role) access control lists allowing a rich set of security permissions to be applied to systems and services.
- geofft 8y ago
  Yup, that's what I meant by "subsystems" (which is NT's own term; not sure why Wikipedia calls them "personalities," and Linux's personality(2) syscall is much more limited). In any case, that support is in the wrong direction. The article proposes dropping NT and moving to Linux, which doesn't have subsystem support at all. Even if it did, the existing WSL code isn't helpful.
  - unixhero 8y ago
    Thea reason why the term Personalities was used is because this is what the industry called this capability, back in the day. It was a huuuge turf war, and the capabilities enabled incredible things. It didn't really pan out however.
NelsonMinar 8y ago
Yeah the article is just plain wrong about WSL being relevant here. WSL is running Linux binaries on an NT kernel. This article wants to run Win32 binaries on a Linux kernel. Totally different problems. I like WSL, but it's not part of the solution here. (Also WSL's IO performance problems suggest this kind of emulation approach has significant costs.)
- wscott 8y ago
  I totally agree with your conclusion but I wanted to comment about the IO performance remark. If you take an IO-heavy application and compile it natively on both platforms you will find that IO performance on Linux is dramaticly faster than windows(1) (and OSX for that matter). For certain workloads, I could see a Windows application running faster under emulation on Linux than natively. 1) This is maybe not true for big databases since those are optimized to basically bypass all of the Windows filesystem.
  - pjc50 8y ago
    I wonder if an intermediate step would be an ext2 filesystem driver for NT. As an officially supported feature that would be very handy.
  - vbezhenar 8y ago
    Is there any particular reason why Linux IO is dramatically faster? NTFS is polished FS, Fat32 is extremely simple (may be unreliable but that's not the point) and both should be performant enough. Also there's new ReFS. May be there's some stupid bug like Windows Defender checking file for viruses every write() call which could be easily fixed?
    - pzone 8y ago
      It's the general overhead and speed of syscalls for reading and writing files. It's very noticeable in software like git which works by reading and writing hundreds of small chunk files to disk. This is a well known fact and there's no way the team responsible for Windows filesystems is unaware. I would be shocked if it were possible to fix with a small or non-breaking change.
Joeri 8y ago
On the other hand, Microsoft has been trying for years to get developers off win32 and onto .NET. Windows S mode was an experiment where they didn't support win32 at all. Much of .NET is already open source. One could argue they are ready to make a .NET shell around a linux kernel and ship MS Linux. But ... why would they? The only reasoning I can see is if they could stop maintaining the windows kernel, like how the move to chromium means they have one less thing to maintain. But they have to keep maintaining it for all those enterprise windows deployments which are tied hard to win32 apps. So I think there's nothing here but clickbait. And yes, I clicked.
- slededit 8y ago
  winRT (or whatever it’s called now) is not .NET. It’s based upon COM and has full support for native code. .NET is designed with native COM support so it’s use is seamless there.

by geofft 8y ago

halbritt 8y ago

The existence of MSSQL-Linux is proof that Microsoft can get this done. The story is pretty interesting: https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-server-on-linux-how-introduction/ https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-se...

oaiey 8y ago
Just that a database server is a very specific thing. Own memory handling, own file system handling, own scheduling, ... . The core of these systems give a shit about the operating system.
- kerng 8y ago
  It's even more so true. The complexity of kernel calls is much higher when custom memory and scheduler involved I'd say. Getting Office running is probably rather simple in comparison.
  - jcelerier 8y ago
    > The complexity of kernel calls is much higher when custom memory and scheduler involved I'd say I really don't think so. MS used to render scrollbars in the kernel (was still the case in early Win10 versions)
    - geofft 8y ago
      I believe TrueType fonts are still rendered in kernel mode. (They have a policy option for blocking untrusted fonts, because of course that parser has bugs.)
      - ryuuchin 8y ago
        Although the rendering may still be done in kernel mode the parsing is now done in a usermode sandbox[1] which significantly reduces risks from handling untrusted fonts. [1] https://blogs.technet.microsoft.com/secguide/2017/06/15/dropping-the-untrusted-font-blocking-setting/ https://blogs.technet.microsoft.com/secguide/2017/06/15/drop...
  - mrweasel 8y ago
    MSSQL is basically a small OS, it uses very few system calls, around 50 if I remember the Microsoft presentation correctly. That’s not to say that porting was easy, but rely very little on the underlaying OS. Porting Office is most likely much more work, just to get the GUI working.
- halbritt 8y ago
  No argument that a desktop environment and a database server are different things. It'd be hard to judge which is a more complex task. Even still, read the story about how they built an OS abstraction layer on top of Windows and Linux and then ported their product to it. That was an impressive feat and an perfect example of Microsoft doing something (maybe only this one thing) right. Unlike Office on Mac which was a piece of shit for very many years and a very different product than Office on Windows.
  - oaiey 8y ago
    Oh I did. I followed WSL and MSSQL development strategies a lot. Cool stuff.
geofft 8y ago
Oh yeah, that's a pretty good point. There's no GUI involved, though... but another good example is Internet Explorer for UNIX, which used a third-party WINE-like product from the mid-'90s. https://en.m.wikipedia.org/wiki/Internet_Explorer_for_UNIX https://en.m.wikipedia.org/wiki/Internet_Explorer_for_UNIX But even then, that was with source access to IE. I definitely believe MS has the skills to make a binary-level implementation of Win32 on Linux happen. I just don't think it will be easy.

lukeh 8y ago

Interix was a better POSIX subsystem; it took until WSL to actually be able to run Linux binaries on NT.

unixhero 8y ago

NT has the capabilities to run different API "Personalities". This was pretty major. WIN32 was only one of the APIs NT supported. IBM also did the same with Workplace OS, but it failed. NT could have been a lot of things, if the competitive landscape was different. From Wikipedia: A main design goal of NT was hardware and software portability. Various versions of NT family operating systems have been released for a variety of processor architectures, initially IA-32, MIPS, and DEC Alpha, with PowerPC, Itanium, x86-64 and ARM supported in later releases. The idea was to have a common code base with a custom Hardware Abstraction Layer (HAL) for each platform. However, support for MIPS, Alpha, and PowerPC was later dropped in Windows 2000. Broad software compatibility was achieved with support for several API "personalities", including Windows API, POSIX,[11] and OS/2 APIs[12] – the latter two were phased out starting with Windows XP.[13] Partial MS-DOS compatibility was achieved via an integrated DOS Virtual Machine – although this feature is being phased out in the x86-64 architecture.[14] NT supported per-object (file, function, and role) access control lists allowing a rich set of security permissions to be applied to systems and services.

geofft 8y ago
Yup, that's what I meant by "subsystems" (which is NT's own term; not sure why Wikipedia calls them "personalities," and Linux's personality(2) syscall is much more limited). In any case, that support is in the wrong direction. The article proposes dropping NT and moving to Linux, which doesn't have subsystem support at all. Even if it did, the existing WSL code isn't helpful.
- unixhero 8y ago
  Thea reason why the term Personalities was used is because this is what the industry called this capability, back in the day. It was a huuuge turf war, and the capabilities enabled incredible things. It didn't really pan out however.

NelsonMinar 8y ago

Yeah the article is just plain wrong about WSL being relevant here. WSL is running Linux binaries on an NT kernel. This article wants to run Win32 binaries on a Linux kernel. Totally different problems. I like WSL, but it's not part of the solution here. (Also WSL's IO performance problems suggest this kind of emulation approach has significant costs.)

wscott 8y ago
I totally agree with your conclusion but I wanted to comment about the IO performance remark. If you take an IO-heavy application and compile it natively on both platforms you will find that IO performance on Linux is dramaticly faster than windows(1) (and OSX for that matter). For certain workloads, I could see a Windows application running faster under emulation on Linux than natively. 1) This is maybe not true for big databases since those are optimized to basically bypass all of the Windows filesystem.
- pjc50 8y ago
  I wonder if an intermediate step would be an ext2 filesystem driver for NT. As an officially supported feature that would be very handy.
- vbezhenar 8y ago
  Is there any particular reason why Linux IO is dramatically faster? NTFS is polished FS, Fat32 is extremely simple (may be unreliable but that's not the point) and both should be performant enough. Also there's new ReFS. May be there's some stupid bug like Windows Defender checking file for viruses every write() call which could be easily fixed?
  - pzone 8y ago
    It's the general overhead and speed of syscalls for reading and writing files. It's very noticeable in software like git which works by reading and writing hundreds of small chunk files to disk. This is a well known fact and there's no way the team responsible for Windows filesystems is unaware. I would be shocked if it were possible to fix with a small or non-breaking change.

Joeri 8y ago

On the other hand, Microsoft has been trying for years to get developers off win32 and onto .NET. Windows S mode was an experiment where they didn't support win32 at all. Much of .NET is already open source. One could argue they are ready to make a .NET shell around a linux kernel and ship MS Linux. But ... why would they? The only reasoning I can see is if they could stop maintaining the windows kernel, like how the move to chromium means they have one less thing to maintain. But they have to keep maintaining it for all those enterprise windows deployments which are tied hard to win32 apps. So I think there's nothing here but clickbait. And yes, I clicked.

slededit 8y ago
winRT (or whatever it’s called now) is not .NET. It’s based upon COM and has full support for native code. .NET is designed with native COM support so it’s use is seamless there.