6 ms·

I'm curious to hear your rationale for preferring Windows over POSIX. It's interesting to draw that comparision and conclude that Windows is better (most argume

I'm curious to hear your rationale for preferring Windows over POSIX. It's interesting to draw that comparision and conclude that Windows is better (most arguments favor the UI/UX, the large body of software, or the hardware support - not APIs/standards).

wfunction 10y ago
> most arguments favor the UI/UX, the large body of software, or the hardware support - not APIs/standards Windows kernel API documentation vs. Linux kernel API documentation... there's not even a contest to be had.
- temac 10y ago
  OTOH, the situation is reversed by the userspace API documentation... even more so if we are talking about POSIX vs Win32.......
  - wfunction 10y ago
    I'm not exactly a hardcore fan of Win32 userspace documentation but POSIX's drives me far more insane. Can you name a few examples that aren't from shell32/shlwapi?
    - temac 10y ago
      General principles will be more interesting than examples: Win32 does not list the errors that can happen, rendering the greater error code space it has half-useless. Even without considering errors, the description of what functions do is often unclear or made in not precise terms. It is often needed to test the functions in tiny test programs to actually understand all their details before you can use them properly, and given they often have a high number of parameters this makes this matter even worse. Something as simple as the CreateProcess and family of function is a complete mess (both in the doc and in the detailed way they work...) POSIX actually doubles as a reference documentation. I don't think such a thing really exists for Win32 -- MSDN is way too vague to achieve that purpose. Maybe people from Wine / ReactOS maintain a better doc, I don't know.
      - wfunction 10y ago
        > Win32 does not list the errors that can happen This is so patently wrong. Firstly, the first example I thought of (CreateFile) clearly stated that you could get ERROR_FILE_NOT_FOUND, ERROR_ALREADY_EXISTS, ERROR_FILE_EXISTS, ERROR_PIPE_BUSY, ERROR_SHARING_VIOLATION, ERROR_ACCESS_DENIED. Secondly, drivers can sometimes return error codes that the OS might not expect to be necessary, and the OS can't just coerce the error codes into something else; it'd lose information. [1] For example, if you CreateFile, a driver that mandatorily logs data might decide to return an error saying it's low on disk space even though the file already exists, which you wouldn't expect. If your code isn't specially written to handle it, you should treat it as the general failure condition it is. Heck, you can even think of Windows as returning "TRUE" (for no error) or "FALSE" (for error), and GetLastError as just providing details you can ignore. Simply the fact that you know the possibilities are TRUE and FALSE doesn't satisfy you though, does it? So isn't the problem that Linux is just suppressing information it could actually pass through? If anything, Windows is doing this right and Linux is doing it right by being restrictive on the returned information... but in any cases, at best you can suggest they're both "different" and maybe on a good day people would entertain the possibility. Certainly returning MORE information than you need is not something you can call out as a flaw... [1] e.g. see http://stackoverflow.com/a/19249991 http://stackoverflow.com/a/19249991
        temac 10y ago
        You cherry-picked one function for which some errors were specified (and even in this case; few of them), yet you ignore the general case where MSDN seems to tell "go fuck yourself" to the programmer looking for the possible different error cases. Which are important to known in case you want to react programmatively to some, and in a different way to others. Given how poor the error reporting is under Windows (so poor that useless 32 bits hex error code, component dependant, are pretty much the only (useless) thing that users are seeing), the theory of "more of those" are better is also utterly ridiculous. I've never debugged anything looking at WinNT/Win32 error codes, or even the event log, etc, while I've in plenty of occasion debugged things with Unix errno, strace (which gives errno for failed syscalls) logs in /var/log (often dumping Unix errno + some context) or even just reading stderr. If you want to understand how much of the getlasterror specs are missing in Win32, just take a look at the Wine unit tests in various are. For each of those cases (maybe 99% of which are undocumented in MSDN), that can correspond to programmers needing to replicate their own qualification beforehand usage of affected functions, or worse to implicitly make some (sometimes false) hypothesis. And the overwhelming majority of them are not related whatsoever to any kind of driver and whatnot, it is just that not even the upper layer errors are properly specified/documented. This is the kind of info which should appear somewhere in MS doc, and which does not. It's insanely ridiculous because it's obvious MS have it in a form or another, given it is crucial for backward compatibility (or compatibility in general, if you take the Wine case -- but I guess when you remain within MS the main issue is backward compat)
    - contras1970 10y ago
      As someone who strives to write great reference manuals and thinks pretty high of the prose in the POSIX spec, would you point me at some examples of good win32 documentation? I'm always looking for inspiration.
      - wfunction 10y ago
        I don't really have a list handy so I might have to keep looking to find something that meets the "great" bar (again -- I'm not a hardcore fan, I mere think it's reasonably decent), but for example check out the page on I/O Concepts [1] and the sub-pages (such as "Synchronous and Asynchronous I/O"). Does the POSIX documentation have anything like it? I don't recall so remind me if it does. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365199.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- Hello71 10y ago
  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 10y 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 10y 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 10y 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.)
- Sir_Cmpwn 10y ago
  Linux and POSIX are not the same thing.
  - wfunction 10y ago
    Parent said "hardware support"; "POSIX hardware support" would not make all that much sense since it's just an interface specification. The point was to find a reason for preferring Windows which I gave.
    - Sir_Cmpwn 10y ago
      Parent did not say "hardware support". Edit: oh, are you referring to me? I see what you mean but it's still beside the point.
to3m 10y ago
1. Signals are bad. All the bad bits of IRQs, and you're not even working in assembly language, so they're twice as hard. Just say no. 2. The forking model is seductive, but wrong-headed. It's hard to make the file descriptor inheritance behave correctly, and it means the memory requirements are unpredictable (due to the copy-on-write pages) 3. Readiness I/O is not really the right way to do things, because there are obvious race conditions, and the OS can't guarantee one thread woken per pending operation (because it has no idea which threads will do what). Also, the process owns the buffer, which really limits what the OS can do... it needs to be able to own the buffer for the duration of the entire operation for best results, so it can fill it on any ready thread, map the buffer into the driver's address space, etc. 4. Poor multithreading primitives. This really annoyed me... like, you've got a bunch of pthreads stuff, but it doesn't interact with select & co. The Linux people aren't dumb, so they give you eventfd - but there's no promise of single wakeup! NT wakes up one thread per increment, and the wakeup atomically decrements the semaphore; Linux wakes up every thread waiting on the semaphore, and they all fight over it, because there's no other option. (I'm just ignoring POSIX semaphores entirely, because they don't let you wait on them with select/poll/etc. in the first place.) (Perhaps this and #3 ought to be the same item, because they are related. And the end result is that you need to use non-blocking IO for everything... but the non-blocking IO is crippled, because it still has to copy out into the caller's buffer. It's just a more inconvenient programming model, for no real benefit.) I guess it just boils down to what you want: a beautifully polished turd, or a carefully engineered system assembled from turds.
- Sir_Cmpwn 10y ago
  Thanks for humoring me. For what it's worth, I agree with you on all of these points, but I still fall strongly in favor of POSIX over Windows.
- caf 10y ago
  Using signals in the ye olde UNIX fashion is bad. However, that was entirely fixed with the advent of POSIX threads: block all signals in all threads with sigprocmask(), and have a dedicated signal-handling thread that loops around on sigwaitinfo(). That thread then handles signals entirely synchronously, notifying other parts of the program using usual inter-thread communication.
dom0 10y ago
Most Windows APIs actually were designed, unlike POSIX.

wfunction 10y ago

> most arguments favor the UI/UX, the large body of software, or the hardware support - not APIs/standards Windows kernel API documentation vs. Linux kernel API documentation... there's not even a contest to be had.

temac 10y ago
OTOH, the situation is reversed by the userspace API documentation... even more so if we are talking about POSIX vs Win32.......
- wfunction 10y ago
  I'm not exactly a hardcore fan of Win32 userspace documentation but POSIX's drives me far more insane. Can you name a few examples that aren't from shell32/shlwapi?
  - temac 10y ago
    General principles will be more interesting than examples: Win32 does not list the errors that can happen, rendering the greater error code space it has half-useless. Even without considering errors, the description of what functions do is often unclear or made in not precise terms. It is often needed to test the functions in tiny test programs to actually understand all their details before you can use them properly, and given they often have a high number of parameters this makes this matter even worse. Something as simple as the CreateProcess and family of function is a complete mess (both in the doc and in the detailed way they work...) POSIX actually doubles as a reference documentation. I don't think such a thing really exists for Win32 -- MSDN is way too vague to achieve that purpose. Maybe people from Wine / ReactOS maintain a better doc, I don't know.
    - wfunction 10y ago
      > Win32 does not list the errors that can happen This is so patently wrong. Firstly, the first example I thought of (CreateFile) clearly stated that you could get ERROR_FILE_NOT_FOUND, ERROR_ALREADY_EXISTS, ERROR_FILE_EXISTS, ERROR_PIPE_BUSY, ERROR_SHARING_VIOLATION, ERROR_ACCESS_DENIED. Secondly, drivers can sometimes return error codes that the OS might not expect to be necessary, and the OS can't just coerce the error codes into something else; it'd lose information. [1] For example, if you CreateFile, a driver that mandatorily logs data might decide to return an error saying it's low on disk space even though the file already exists, which you wouldn't expect. If your code isn't specially written to handle it, you should treat it as the general failure condition it is. Heck, you can even think of Windows as returning "TRUE" (for no error) or "FALSE" (for error), and GetLastError as just providing details you can ignore. Simply the fact that you know the possibilities are TRUE and FALSE doesn't satisfy you though, does it? So isn't the problem that Linux is just suppressing information it could actually pass through? If anything, Windows is doing this right and Linux is doing it right by being restrictive on the returned information... but in any cases, at best you can suggest they're both "different" and maybe on a good day people would entertain the possibility. Certainly returning MORE information than you need is not something you can call out as a flaw... [1] e.g. see http://stackoverflow.com/a/19249991 http://stackoverflow.com/a/19249991
      - temac 10y ago
        You cherry-picked one function for which some errors were specified (and even in this case; few of them), yet you ignore the general case where MSDN seems to tell "go fuck yourself" to the programmer looking for the possible different error cases. Which are important to known in case you want to react programmatively to some, and in a different way to others. Given how poor the error reporting is under Windows (so poor that useless 32 bits hex error code, component dependant, are pretty much the only (useless) thing that users are seeing), the theory of "more of those" are better is also utterly ridiculous. I've never debugged anything looking at WinNT/Win32 error codes, or even the event log, etc, while I've in plenty of occasion debugged things with Unix errno, strace (which gives errno for failed syscalls) logs in /var/log (often dumping Unix errno + some context) or even just reading stderr. If you want to understand how much of the getlasterror specs are missing in Win32, just take a look at the Wine unit tests in various are. For each of those cases (maybe 99% of which are undocumented in MSDN), that can correspond to programmers needing to replicate their own qualification beforehand usage of affected functions, or worse to implicitly make some (sometimes false) hypothesis. And the overwhelming majority of them are not related whatsoever to any kind of driver and whatnot, it is just that not even the upper layer errors are properly specified/documented. This is the kind of info which should appear somewhere in MS doc, and which does not. It's insanely ridiculous because it's obvious MS have it in a form or another, given it is crucial for backward compatibility (or compatibility in general, if you take the Wine case -- but I guess when you remain within MS the main issue is backward compat)
  - contras1970 10y ago
    As someone who strives to write great reference manuals and thinks pretty high of the prose in the POSIX spec, would you point me at some examples of good win32 documentation? I'm always looking for inspiration.
    - wfunction 10y ago
      I don't really have a list handy so I might have to keep looking to find something that meets the "great" bar (again -- I'm not a hardcore fan, I mere think it's reasonably decent), but for example check out the page on I/O Concepts [1] and the sub-pages (such as "Synchronous and Asynchronous I/O"). Does the POSIX documentation have anything like it? I don't recall so remind me if it does. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365199.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Hello71 10y ago
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 10y 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 10y 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 10y 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.)
Sir_Cmpwn 10y ago
Linux and POSIX are not the same thing.
- wfunction 10y ago
  Parent said "hardware support"; "POSIX hardware support" would not make all that much sense since it's just an interface specification. The point was to find a reason for preferring Windows which I gave.
  - Sir_Cmpwn 10y ago
    Parent did not say "hardware support". Edit: oh, are you referring to me? I see what you mean but it's still beside the point.

to3m 10y ago

1. Signals are bad. All the bad bits of IRQs, and you're not even working in assembly language, so they're twice as hard. Just say no. 2. The forking model is seductive, but wrong-headed. It's hard to make the file descriptor inheritance behave correctly, and it means the memory requirements are unpredictable (due to the copy-on-write pages) 3. Readiness I/O is not really the right way to do things, because there are obvious race conditions, and the OS can't guarantee one thread woken per pending operation (because it has no idea which threads will do what). Also, the process owns the buffer, which really limits what the OS can do... it needs to be able to own the buffer for the duration of the entire operation for best results, so it can fill it on any ready thread, map the buffer into the driver's address space, etc. 4. Poor multithreading primitives. This really annoyed me... like, you've got a bunch of pthreads stuff, but it doesn't interact with select & co. The Linux people aren't dumb, so they give you eventfd - but there's no promise of single wakeup! NT wakes up one thread per increment, and the wakeup atomically decrements the semaphore; Linux wakes up every thread waiting on the semaphore, and they all fight over it, because there's no other option. (I'm just ignoring POSIX semaphores entirely, because they don't let you wait on them with select/poll/etc. in the first place.) (Perhaps this and #3 ought to be the same item, because they are related. And the end result is that you need to use non-blocking IO for everything... but the non-blocking IO is crippled, because it still has to copy out into the caller's buffer. It's just a more inconvenient programming model, for no real benefit.) I guess it just boils down to what you want: a beautifully polished turd, or a carefully engineered system assembled from turds.

Sir_Cmpwn 10y ago
Thanks for humoring me. For what it's worth, I agree with you on all of these points, but I still fall strongly in favor of POSIX over Windows.
caf 10y ago
Using signals in the ye olde UNIX fashion is bad. However, that was entirely fixed with the advent of POSIX threads: block all signals in all threads with sigprocmask(), and have a dedicated signal-handling thread that loops around on sigwaitinfo(). That thread then handles signals entirely synchronously, notifying other parts of the program using usual inter-thread communication.

dom0 10y ago

Most Windows APIs actually were designed, unlike POSIX.