Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wine does all of that though for Windows, even when the syscall structure and caveats or compatibility fixes for the Win32 APIs are unknown.

With Linux, all the syscalls and their bugs are documented, at least in the commit history, if not the man pages.



Wine is an amazing piece of software,but it’s still easy to find issues in many apps. Microsoft wanted something it could sell as a general Linux replacement, so it needed close to 100% compatibility.


My point still stands — Linux syscalls are documented, the Win32 APIs and syscalls aren’t.


> Linux syscalls are documented

It doesn't mean they are implementable atop NT/Windows kernel facilities, semantics, and behaviours, in which case it's an alternative implementation to maintain that foregoes integration.

While Wine's effort and compatibility levels achieved are impressive, they actually prove my point: compatibility is a constant fight, there are a ton of tunables (some automated), and it's still not perfect (which is what a VM gives you for essentially free).

There's more than "basic" syscall interface to it though, there's the whole implementation of features (that are GPLv2 licensed) e.g btrfs? iptables? ebpf? ptrace? hold my beer; run kernel-backed wireguard in WSL2? no problem; alsa? you betcha; real time facilities? sure! custom kernel with a missing feature like usb passthrough? be my guest; contribute to the linux kernel code? entirely possible. It's all there, today, and not at the mercy of MS's will or ability to implement this or that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: