Live data from Hacker News

Guide to Linux System Calls (2016)

blog.packagecloud.io

11–20 of 37 posts

Re: Guide to Linux System Calls (2016)

#11
post #6

Earlier quoted context omitted.

That is true for Linux but might not be true for other operating systems though.

It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yours…

Only UNIX based OSes use libc as part of the stable interface, which on UNIXes case actually means ISO C + POSIX.

On non-POSIX OSes like NT and plenty of others, libc is part of whatever compiler one decides to use and as such not part of any OS interface as such.

On NT the stable OS APIs are provided via the OS personalities, meaning OS/2 (dead now), the old POSIX one (also dead and replaced by WSL), and Win32 (actually User, Kernel, GDI as the main ones), which as of Windows 8 and MinWin refactoring is split into redirection dlls know as API sets, https://docs.microsoft.com/en-us/windows/win32/apiindex/wind....

Which is why on code that never intends to be portable, you will see calls like ZeroMemory instead of memset.

Re: Guide to Linux System Calls (2016)

#13

Earlier quoted context omitted.

It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yours…

macOS, in some sense a BSD (at least nominally), would like you to not make system calls yourself as well. Actually, not linking against libc has a number of hilarious consequences, one of which is that you bypass the platform sandbox because apparently the engineers thought it couldn't be possible to write a program without it :P

Is there an example somewhere on how to link without libc and make my own syscalls? I tried this a while ago (can't remember which version of macOS it was), fiddling with Csu, nasm etc. but couldn't quite figure it out.

Re: Guide to Linux System Calls (2016)

#14
post #11

Earlier quoted context omitted.

It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yours…

Only UNIX based OSes use libc as part of the stable interface, which on UNIXes case actually means ISO C + POSIX. On non-POSIX OSes like NT and plenty of others, libc is part of whatever compiler one decides to use and as such not part of any OS interface as such. On NT the stable OS APIs are provided via the OS personalities, meaning OS/2 (dead now), the old POSIX one (also dead and replaced by WSL), and Win32 (actu…

Oh, interesting; I'd assumed that NT was just using libc as its stable ABI, but on further reading it looks more like ntdll.dll (probably just for that personality?). Similar concept, slightly different place. Still, my point was that under the "Windows" personalities, you talk to a library, never directly to the kernel.

EDIT: Found https://web.archive.org/web/20121224002314/http://netcode.cz... which if I'm reading right indicates that ntdll is indeed the bottom-layer library that's allowed to actually talk to the kernel.

Re: Guide to Linux System Calls (2016)

#15
post #11

Earlier quoted context omitted.

Only UNIX based OSes use libc as part of the stable interface, which on UNIXes case actually means ISO C + POSIX. On non-POSIX OSes like NT and plenty of others, libc is part of whatever compiler one decides to use and as such not part of any OS interface as such. On NT the stable OS APIs are provided via the OS personalities, meaning OS/2 (dead now), the old POSIX one (also dead and replaced by WSL), and Win32 (actu…

Oh, interesting; I'd assumed that NT was just using libc as its stable ABI, but on further reading it looks more like ntdll.dll (probably just for that personality?). Similar concept, slightly different place. Still, my point was that under the "Windows" personalities, you talk to a library, never directly to the kernel. EDIT: Found https://web.archive.org/web/20121224002314/http://netcode.cz... which if I'm reading…

Yes, ntdll is the lowest level, but you aren't supposed to use it directly, and if you do, well no one is going to help when a patch Tuesday or something like that breaks the application.

The personality DLLs are the applications entry point with the kernel.

Re: Guide to Linux System Calls (2016)

#16
post #15

Earlier quoted context omitted.

Oh, interesting; I'd assumed that NT was just using libc as its stable ABI, but on further reading it looks more like ntdll.dll (probably just for that personality?). Similar concept, slightly different place. Still, my point was that under the "Windows" personalities, you talk to a library, never directly to the kernel. EDIT: Found https://web.archive.org/web/20121224002314/http://netcode.cz... which if I'm reading…

Yes, ntdll is the lowest level, but you aren't supposed to use it directly, and if you do, well no one is going to help when a patch Tuesday or something like that breaks the application. The personality DLLs are the applications entry point with the kernel.

Most of ntdll.dll is officially sanctioned at this point. It's officially documented, and obviously plays into the backwards compat choices they make.

Re: Guide to Linux System Calls (2016)

#17

Earlier quoted context omitted.

macOS, in some sense a BSD (at least nominally), would like you to not make system calls yourself as well. Actually, not linking against libc has a number of hilarious consequences, one of which is that you bypass the platform sandbox because apparently the engineers thought it couldn't be possible to write a program without it :P

Is there an example somewhere on how to link without libc and make my own syscalls? I tried this a while ago (can't remember which version of macOS it was), fiddling with Csu, nasm etc. but couldn't quite figure it out.

-static -nostdlib, and make sure you have an entry point set.

Re: Guide to Linux System Calls (2016)

#18

Earlier quoted context omitted.

macOS, in some sense a BSD (at least nominally), would like you to not make system calls yourself as well. Actually, not linking against libc has a number of hilarious consequences, one of which is that you bypass the platform sandbox because apparently the engineers thought it couldn't be possible to write a program without it :P

Is there an example somewhere on how to link without libc and make my own syscalls? I tried this a while ago (can't remember which version of macOS it was), fiddling with Csu, nasm etc. but couldn't quite figure it out.

[deleted]

Re: Guide to Linux System Calls (2016)

#20
post #15

Earlier quoted context omitted.

Yes, ntdll is the lowest level, but you aren't supposed to use it directly, and if you do, well no one is going to help when a patch Tuesday or something like that breaks the application. The personality DLLs are the applications entry point with the kernel.

Most of ntdll.dll is officially sanctioned at this point. It's officially documented, and obviously plays into the backwards compat choices they make.

Sort of. Many NT functions are officially documented. But they're also officially documented as unstable. They probably won't break many of the oldest functions but they reserve the right to do so at some point.
Post reply on HN