4 ms·

> In the specific case of Windows the kernel interface is pretty fiddly (the syscall ids vary between Windows releases) Interesting - I wouldn't have expected

> In the specific case of Windows the kernel interface is pretty fiddly (the syscall ids vary between Windows releases) Interesting - I wouldn't have expected that. Anyone know why that's the case?

p_l 4y ago
Windows never used syscalls officially - the Windows API evolved from essentially having the operating system be inside few shared libraries that your program linked with. Even once the idea of syscall started showing up with protected mode and NT, the applications wouldn't directly invoke them, but through interfaces in the libraries. Thus there was never really a proper need to have stable syscall interface, because at least officially no application was supposed to use them - they were private implementation details of various DLLs.
- ryao 4y ago
  These days, you have DRM solutions doing syscalls directly. I think Jurassic World evolution is an example of software using DRM that does that. The wine developers had to implement the ability to emulate windows syscalls because of it. I wonder how Microsoft will react to third parties beginning to do syscalls.
  - userbinator 4y ago
    "beginning to"? This has been around since the early NT days, basically as long as DRM (and thus anti-DRM) has existed. Microsoft's reaction? Nothing but occasionally changing the syscall numbers.
  - yjftsjthsd-h 4y ago
    I'm shocked that that works - I was given to understand that MS outright shuffles syscalls per build to make them completely unreliable from userspace.
    - p_l 4y ago
      A lot of DRM (especially game DRM) solutions don't care about reliability or stability. If they figure a way that makes it harder to reverse or run or whatever, they will do it. Even if they are essentially rootkits bad enough someone really should try to see if CFAA would stick.
- userbinator 4y ago
  In particular, Windows 9x has a completely different syscall interface (if you could even call it that) than the NT line; the majority of kernel32 functions seem to go through a far call to a fixed address: https://news.ycombinator.com/item?id=13264007 https://news.ycombinator.com/item?id=13264007 The above-linked handful of pages may be the only detailed documentation of the 9x syscall interface that is still reachable by search engines today.
TeMPOraL 4y ago
IIRC it's the other way around - it's Linux exposing syscalls for direct access that's unusual.
- yjftsjthsd-h 4y ago
  Yep; Darwin doesn't do raw syscalls, the BSDs don't (OpenBSD going so far as to block anything but libc from making syscalls, as a security feature), illumos doesn't... actually the only OS I can think of off-hand where applications regularly use syscalls is DOS, and even then it looks more like a side-effect of x86 architecture and the constraints that it was developed under. Go hit this particularly hard, having mostly grown up on Linux and then finding out the hard way that using libc isn't really optional on other systems.
  - kevin_thibedeau 4y ago
    DOS syscalls are an outgrowth of the CP/M hardware abstraction. It isn't tied to x86.
  - wongarsu 4y ago
    On well designed systems (and I will count Windows in that group), libc is optional and syscalls are decoupled into another library. After all (unlike what some BSDs think) not everything is C, and forcing everyone to use the libc abstractions isn't very nice.
detaro 4y ago
Applications are not supposed to ever use them, but rather make use of the system libraries to access them. So having stable IDs is somewhere between not a priority and something to be avoided to stop developers ignoring that rule.
monocasa 4y ago
Interestingly they started in more or less in alphabetical order. It certainly looks for the outside like there's a big file that gets updated wherever the dev adding the syscall thinks looks clean, and gets reorganized every now and then. Combined with the obvious 'it's not a stable interface so we like changing it up regularly so people don't feel like they can depend on it'. Here's the table itself for 32 bit x86 versions if anyone's curious: https://j00ru.vexillium.org/syscalls/nt/32/ https://j00ru.vexillium.org/syscalls/nt/32/
wongarsu 4y ago
I'm pretty sure Windows syscall ids are automatically generated in the build process, with no special effort to keep them consistent between releases. Since the code that receives syscalls (kernel) and the code that calls them (shared libraries like user32.dll or ntdll.dll) are shipped together that doesn't cause any problems, and is probably more convinient than manually mapping numbers to function calls.

> In the specific case of Windows the kernel interface is pretty fiddly (the syscall ids vary between Windows releases) Interesting - I wouldn't have expected that. Anyone know why that's the case?

p_l 4y ago

Windows never used syscalls officially - the Windows API evolved from essentially having the operating system be inside few shared libraries that your program linked with. Even once the idea of syscall started showing up with protected mode and NT, the applications wouldn't directly invoke them, but through interfaces in the libraries. Thus there was never really a proper need to have stable syscall interface, because at least officially no application was supposed to use them - they were private implementation details of various DLLs.

ryao 4y ago
These days, you have DRM solutions doing syscalls directly. I think Jurassic World evolution is an example of software using DRM that does that. The wine developers had to implement the ability to emulate windows syscalls because of it. I wonder how Microsoft will react to third parties beginning to do syscalls.
- userbinator 4y ago
  "beginning to"? This has been around since the early NT days, basically as long as DRM (and thus anti-DRM) has existed. Microsoft's reaction? Nothing but occasionally changing the syscall numbers.
- yjftsjthsd-h 4y ago
  I'm shocked that that works - I was given to understand that MS outright shuffles syscalls per build to make them completely unreliable from userspace.
  - p_l 4y ago
    A lot of DRM (especially game DRM) solutions don't care about reliability or stability. If they figure a way that makes it harder to reverse or run or whatever, they will do it. Even if they are essentially rootkits bad enough someone really should try to see if CFAA would stick.
userbinator 4y ago
In particular, Windows 9x has a completely different syscall interface (if you could even call it that) than the NT line; the majority of kernel32 functions seem to go through a far call to a fixed address: https://news.ycombinator.com/item?id=13264007 https://news.ycombinator.com/item?id=13264007 The above-linked handful of pages may be the only detailed documentation of the 9x syscall interface that is still reachable by search engines today.

TeMPOraL 4y ago

IIRC it's the other way around - it's Linux exposing syscalls for direct access that's unusual.

yjftsjthsd-h 4y ago
Yep; Darwin doesn't do raw syscalls, the BSDs don't (OpenBSD going so far as to block anything but libc from making syscalls, as a security feature), illumos doesn't... actually the only OS I can think of off-hand where applications regularly use syscalls is DOS, and even then it looks more like a side-effect of x86 architecture and the constraints that it was developed under. Go hit this particularly hard, having mostly grown up on Linux and then finding out the hard way that using libc isn't really optional on other systems.
- kevin_thibedeau 4y ago
  DOS syscalls are an outgrowth of the CP/M hardware abstraction. It isn't tied to x86.
- wongarsu 4y ago
  On well designed systems (and I will count Windows in that group), libc is optional and syscalls are decoupled into another library. After all (unlike what some BSDs think) not everything is C, and forcing everyone to use the libc abstractions isn't very nice.

detaro 4y ago

Applications are not supposed to ever use them, but rather make use of the system libraries to access them. So having stable IDs is somewhere between not a priority and something to be avoided to stop developers ignoring that rule.

monocasa 4y ago

Interestingly they started in more or less in alphabetical order. It certainly looks for the outside like there's a big file that gets updated wherever the dev adding the syscall thinks looks clean, and gets reorganized every now and then. Combined with the obvious 'it's not a stable interface so we like changing it up regularly so people don't feel like they can depend on it'. Here's the table itself for 32 bit x86 versions if anyone's curious: https://j00ru.vexillium.org/syscalls/nt/32/ https://j00ru.vexillium.org/syscalls/nt/32/

wongarsu 4y ago

I'm pretty sure Windows syscall ids are automatically generated in the build process, with no special effort to keep them consistent between releases. Since the code that receives syscalls (kernel) and the code that calls them (shared libraries like user32.dll or ntdll.dll) are shipped together that doesn't cause any problems, and is probably more convinient than manually mapping numbers to function calls.