Hacker News Reader

Comment by creata | Hacker News Reader

I think that's fair to say for Linux, since it aims for syscall compatibility, but I don't think that's true for Windows or macOS, where (unless I'm mistaken) your only options are to use libc (or an equivalent) or to constantly track breaking changes to the syscall interface.

View on HN

I don’t recall any breaking changes on Windows syscall interface, can you give an example?

Windows syscall interface changes all the time. [1] has a table of windows syscall numbers. Just looking at the first syscall, NtAcceptConnectPort, you can see that all windowses up to and including 7 used 0x60; windows 8 changed to 0x61; 8.1 changed it to 1; and then 10 changed it to 2.

1. https://j00ru.vexillium.org/syscalls/nt/64/

I see, that’s interesting. I guess software ecosystem almost always uses Ntdll instead of raw syscalls. I’m still curious why there’s been a reshuffling at all.

The kernel has been refactored several times.

The most famous one being MinWin

https://arstechnica.com/information-technology/2007/10/core-...

During Windows 10 that happened also a couple of times.

You don't do direct syscall on Windows, you make those through system DLLs.

There is nothing preventing you from doing that though, that’s why I was curious.

Hopefully your brain will prevent you from doing that. When OS developers say that the C library is the public interface and syscalls are private, you listen and use the C library.

Golang authors completely ignored FreeBSD's policy and went with syscalls directly because "they don't change in practice" and that is infuriating. Porting to new architectures is much harder, for one.

Reply on news.ycombinator.com