3 ms·

Funny that the author calls out Windows as being separate somehow. Hasn't the last 20 years of Windows been synonymous with adding more Posix-compatibility?

eyelidlessness 4y ago
Windows has ostensibly been, or at least has been claimed to be, “POSIX compliant” for much longer than that. I think however technically true that might be, a good heuristic for why Windows is “other” in this categorization is how frequently things are reported as broken in Windows environments when they don’t have any other platform-specific issues across many *nixes. Sure that divergence might not be specific to POSIX, but a more general “every other system from every other vendor agrees broadly on ___ but if you use Windows your environment needs special accommodations.” Anecdotally, the surface area of this divergence is basically equivalent to any project which constructs file paths, and/or executes subcommands, unless special care was taken prior to address Windows specifically. And Windows is certainly entitled to its own particularities and idiosyncrasies! But it’s not entitled to have those and be regarded as not having them at the same time. That would be absurd.
ghelmer 4y ago
I have been unpleasantly surprised when I expect Posix semantics from Windows. Think about parent PIDs. You can't assume a process's parent PID is actually still the parent. Think about file open semantics. Try to open to a file when any other process has the file open with no sharing allowed. Think about file delete. (Really, try to delete a file reliably in Windows.) Think about string encoding and code pages. (Well, this is out of bounds for Posix, but closely related to expected filename semantics.)
jeroenhd 4y ago
Has it? From COM to C++/WinRT, I think Windows is moving further and further away from simple POSIX calls. Of course these platforms have mainly been designed to be used by other languages (VBScript to PowerShell) but if you want to use newer APIs in your C++ application, you're going to need to go through the new API. Bolting Linux in a thin VM onto the OS has been done to facilitate web/POSIX devs that otherwise would buy a Mac or install Linux. It's a more modern take on bolting Windows Services for UNIX onto NT4 back in '99. The API of the Windows platform itself has only moved further and further away from POSIX as time went on.

eyelidlessness 4y ago

Windows has ostensibly been, or at least has been claimed to be, “POSIX compliant” for much longer than that. I think however technically true that might be, a good heuristic for why Windows is “other” in this categorization is how frequently things are reported as broken in Windows environments when they don’t have any other platform-specific issues across many *nixes. Sure that divergence might not be specific to POSIX, but a more general “every other system from every other vendor agrees broadly on ___ but if you use Windows your environment needs special accommodations.” Anecdotally, the surface area of this divergence is basically equivalent to any project which constructs file paths, and/or executes subcommands, unless special care was taken prior to address Windows specifically. And Windows is certainly entitled to its own particularities and idiosyncrasies! But it’s not entitled to have those and be regarded as not having them at the same time. That would be absurd.

ghelmer 4y ago

I have been unpleasantly surprised when I expect Posix semantics from Windows. Think about parent PIDs. You can't assume a process's parent PID is actually still the parent. Think about file open semantics. Try to open to a file when any other process has the file open with no sharing allowed. Think about file delete. (Really, try to delete a file reliably in Windows.) Think about string encoding and code pages. (Well, this is out of bounds for Posix, but closely related to expected filename semantics.)

jeroenhd 4y ago

Has it? From COM to C++/WinRT, I think Windows is moving further and further away from simple POSIX calls. Of course these platforms have mainly been designed to be used by other languages (VBScript to PowerShell) but if you want to use newer APIs in your C++ application, you're going to need to go through the new API. Bolting Linux in a thin VM onto the OS has been done to facilitate web/POSIX devs that otherwise would buy a Mac or install Linux. It's a more modern take on bolting Windows Services for UNIX onto NT4 back in '99. The API of the Windows platform itself has only moved further and further away from POSIX as time went on.