4 ms·

yes, the Linux userspace<->kernel API is far better documented. Windows has literally hundreds if not thousands of completely undocumented (publicly) system cal

yes, the Linux userspace<->kernel API is far better documented. Windows has literally hundreds if not thousands of completely undocumented (publicly) system calls, whereas each Linux system call has a man page available on basically every Linux system, no web browser required. even the "internal" system calls like mmap2 have man pages. find me "documentation" for NtSuspendProcess. and even the kernel API documentation, which, while it has its issues, I would argue is still far better than MSDN, which IME is mostly pages and pages of function prototypes with a one-line restatement of the name of the function.

Hello71 9y ago
oh, and CLOEXEC seems very clear and explicit to me. OTOH, we have Windows where instead of open(path, O_CLOEXEC), we must use SetHandleInformation(handle, HANDLE_FLAG_INHERIT, 0). now let us compare the documentation for these two options: MSDN: "If this flag is set, a child process created with the bInheritHandles parameter of CreateProcess set to TRUE will inherit the object handle." Linux: "Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Note that the use of this flag is essential in some multithreaded programs, because using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor and attempts to set its close-on-exec flag using fcntl(2) at the same time as another thread does a fork(2) plus execve(2). Depending on the order of execution, the race may lead to the file descriptor returned by open() being unintentionally leaked to the program executed by the child process created by fork(2). (This kind of race is in principle possible for any system call that creates a file descriptor whose close-on-exec flag should be set, and various other Linux system calls provide an equivalent of the O_CLOEXEC flag to deal with this problem.)" seems better to me.
nxc18 9y ago
If you're making syscalls on Windows, you're doing it wrong (with the sole exception of drivers, for which the API surface is adequately documented).
dahauns 9y ago
find me "documentation" for NtSuspendProcess What for? Use of NtSuspendProcess/NtResumeProcess is usually a smell of trying to do *nix style multiprocessing in Windows. For which the answer usually is: Don't. Yeah I know, that's a perfect point to start yet another flamewar, and as such I want to add the disclaimer that I'm not making a judgment with this statement. :) It's just that this is by design: You're not supposed to use the kernel API directly in Windows, you are supposed to code against Win32/WinRT/UWP. (Hmm...I'd hazard a guess there is documentation for these calls, but it's simply not public.)

Hello71 9y ago

oh, and CLOEXEC seems very clear and explicit to me. OTOH, we have Windows where instead of open(path, O_CLOEXEC), we must use SetHandleInformation(handle, HANDLE_FLAG_INHERIT, 0). now let us compare the documentation for these two options: MSDN: "If this flag is set, a child process created with the bInheritHandles parameter of CreateProcess set to TRUE will inherit the object handle." Linux: "Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Note that the use of this flag is essential in some multithreaded programs, because using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor and attempts to set its close-on-exec flag using fcntl(2) at the same time as another thread does a fork(2) plus execve(2). Depending on the order of execution, the race may lead to the file descriptor returned by open() being unintentionally leaked to the program executed by the child process created by fork(2). (This kind of race is in principle possible for any system call that creates a file descriptor whose close-on-exec flag should be set, and various other Linux system calls provide an equivalent of the O_CLOEXEC flag to deal with this problem.)" seems better to me.

nxc18 9y ago

If you're making syscalls on Windows, you're doing it wrong (with the sole exception of drivers, for which the API surface is adequately documented).

dahauns 9y ago

find me "documentation" for NtSuspendProcess What for? Use of NtSuspendProcess/NtResumeProcess is usually a smell of trying to do *nix style multiprocessing in Windows. For which the answer usually is: Don't. Yeah I know, that's a perfect point to start yet another flamewar, and as such I want to add the disclaimer that I'm not making a judgment with this statement. :) It's just that this is by design: You're not supposed to use the kernel API directly in Windows, you are supposed to code against Win32/WinRT/UWP. (Hmm...I'd hazard a guess there is documentation for these calls, but it's simply not public.)