Hacker News Reader

Comment by jchw | Hacker News Reader

Windows is not POSIX compliant anymore. Claiming that it is and linking to an article about WSL is just confusing, as most Linux distributions are not POSIX compliant either. I assume this is based on Windows NT's historical status with SfU and UNIX compliance. But Windows doesn't need POSIX compliance today. I'm pretty sure that only ever happened because the U.S. government was pushing for POSIX in an era where UNIX operating systems were far more relevant.

View on HN

WSL v1 was just a POSIX wrapper that translated system calls into their NT equivalents. It ended up being scrapped for a Hyper-V based VM approach for WSL2, but it's a pretty good argument as far as practical POSIX compatibility.

From my understanding: WSL1 emulated Linux syscalls and ran Linux-compatible ELF binaries on picoprocesses. This isn't really sufficient to call it a POSIX layer. I am not aware (and can not find evidence) of Microsoft attempting to get it certified as compliant, and in order to do so it would need a compliant root image (e.g. not Ubuntu.)

Services for UNIX was a different story, but that's not what either version of WSL is.

POSIX also specifies the coreutils, so implementing a few syscalls definitely doesn't cut it.

> Microsoft attempting to get it certified as compliant

Who would bother getting POSIX, UNIX, or FIPS 140-2 certified in today's world? We've moved on from when any of those things were important. It costs time/money and what customers would Microsoft attract?

The US Gov't no longer sees those as important requirements.

Certification isn't required to be compliant, and I'd argue that very few people actually care or refer to it in the real world.

It meets the same bar that all of the other "mostly compliant" OSes listed on the POSIX wiki page meet: you can write code against a POSIX stdlib and it'll work without involving a VM as long as you stick to some subset of interfaces and behaviors.

WSL1's compliance was actually larger than most of the OSes on that list. The last time I asked Mentor Graphics which parts of POSIX they supported on Nucleus they said "tell us what APIs your application needs and we'll implement them" (anything beyond PSE51 was largely unimplemented). Zephyr is nice enough to actually document their limitations, but the support is far from comprehensive either:

https://docs.zephyrproject.org/latest/services/portability/p...

WSL1 doesn't even handle userspace. It just ships Ubuntu. And certification or no certification, Ubuntu is very trivially not POSIX-compliant. Perhaps you can make it POSIX compliant, but there is no obvious way to do this; you would have to go point-by-point.

I don't think that is any better than OSes that conform to some specific subset.

Windows NT did have a POSIX subsystem to satisfy US government requirements, in addition to the win32 subsystem (and one more?). It had no relation to Linux whatsoever.

There was also a POSIX file system API available to win32 programs, but I'm not sure how that was related.

It absolutely was related to government requirements. FIPS 151-2 required that certain government purchases be POSIX compliant.

The POSIX namespace in NTFS is important for implementing things like SfU and WSL1. That's how they get proper POSIX semantics for filenames and links. Win32 programs can technically use it too, but it's an NTFS-specific feature rather than just a Win32 one as I understand it. (It can also be used on Linux when using NTFS drivers. AFAIK, it's usually the default option for new files in ntfs3g.)

My personal favorite irony is that by default “write” on windows is more posix compliant than any Linux install using ext4. If you need write atomicity, as posix guarantees, avoid ext4.

POSIX only guarantees write atomicity for pipes and FIFOs, not for regular files.

Reply on news.ycombinator.com