Hacker News Reader

Comment by geofft | Hacker News Reader

> 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.

View on HN

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.

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.

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-se...

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.

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.

> 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)

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.)

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/drop...

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.

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.

Oh I did. I followed WSL and MSSQL development strategies a lot. Cool stuff.

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 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.

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.)

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.

I wonder if an intermediate step would be an ext2 filesystem driver for NT. As an officially supported feature that would be very handy.

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?

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.

Isn't it a programming model thing? There's no Linux version of IOCP, and my impression is Windows apps that do use IOCP get good performance—but apps using cross-platform APIs or ported from UNIX tend not to have an IOCP-shaped IO layer and just use blocking calls, which are less optimized on Windows.

Maybe I'm confusing this with subprocess creation speed (which also hurt git back when lots of tools were shell or Perl scripts) or network performance (many years ago, my boss and I found that Apache on Linux on VMware Workstation on Windows with bridged networking performed better than Apache directly on Windows, presumably because it's using select() or something)?

I read previously on HN that it has something to do with NTFS's MFT structures... particularly when large number of small files are involved. I don't think FAT32 suffers from the same problem but then again, it isn't widely used on desktops or servers any more.

It's certainly also ACL overkill. They lookup ACL inheritance by default on every single file call, unless you turn it off in your directory. That's uncached and recursive up to the root, extremely slow.

Thanks for that info! It seems particularly noticeable in WSL when compiling large packages; all the dependency calculations are super slow compared to native Linux. I'd naively thought it had something to do with Windows Defender overhead but your explanation makes more sense.

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.

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.

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.

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

Reply on news.ycombinator.com