4 ms·

I wish Microsoft would modernize Windows to be a fully (or mostly) POSIX-compliant architecture like (almost?) every other OS in existence. It's a unicorn in th

by kevwil 8y ago

I wish Microsoft would modernize Windows to be a fully (or mostly) POSIX-compliant architecture like (almost?) every other OS in existence. It's a unicorn in that regard, and unicorns should stay extinct. ;-)

nolok 8y ago
The people who truly care about it not being POSIX compliant are also the people who would still denigrate it even if it became fully compliant so ... From their point of view, why bother ? You are your own worst enemy on that one. On the flip side, with WSL windows 10 can now pretty much run any POSIX compliant code anyway.
zapzupnz 8y ago
POSIX was made to unite the UNIXes. The reason why POSIX compatibility would be important is for efficient porting of software from one platform to another, especially when the platforms aren't UNIX-compliant. Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard. Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that. Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software. Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet. You're making fun of unicorns, but treating 'POSIX' like a magic word.
- int_19h 8y ago
  As someone who generally prefers Windows, it would still be nice to have a greater degree of POSIX in it, just for the sake of more portability. There are some choices, like the path syntax, that are never going to make Win32 fully POSIX compliant. But why can't we e.g. have POSIX threads and synchronization primitives, or most of the filesystem API?
  - slededit 8y ago
    The old Unix personality had that - and now the new Linux Personality (they no longer call it that) implements this for you. This complaint no longer makes sense since WSL was released.
    - int_19h 8y ago
      WSL serves different scenarios - it is for running Linux software on Windows. It's all or nothing - if you want Linux, you get Linux. If you want Windows, you get Windows. You can't mix and match. So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.
      - slededit 8y ago
        The IPC communication between WSL and native windows applications is getting better all the time. Along with the filesystem they both share you can use sockets, and named pipes. Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.

by kevwil 8y ago

nolok 8y ago

The people who truly care about it not being POSIX compliant are also the people who would still denigrate it even if it became fully compliant so ... From their point of view, why bother ? You are your own worst enemy on that one. On the flip side, with WSL windows 10 can now pretty much run any POSIX compliant code anyway.

zapzupnz 8y ago

POSIX was made to unite the UNIXes. The reason why POSIX compatibility would be important is for efficient porting of software from one platform to another, especially when the platforms aren't UNIX-compliant. Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard. Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that. Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software. Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet. You're making fun of unicorns, but treating 'POSIX' like a magic word.

int_19h 8y ago
As someone who generally prefers Windows, it would still be nice to have a greater degree of POSIX in it, just for the sake of more portability. There are some choices, like the path syntax, that are never going to make Win32 fully POSIX compliant. But why can't we e.g. have POSIX threads and synchronization primitives, or most of the filesystem API?
- slededit 8y ago
  The old Unix personality had that - and now the new Linux Personality (they no longer call it that) implements this for you. This complaint no longer makes sense since WSL was released.
  - int_19h 8y ago
    WSL serves different scenarios - it is for running Linux software on Windows. It's all or nothing - if you want Linux, you get Linux. If you want Windows, you get Windows. You can't mix and match. So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.
    - slededit 8y ago
      The IPC communication between WSL and native windows applications is getting better all the time. Along with the filesystem they both share you can use sockets, and named pipes. Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.