Windows NT implemented POSIX compatibility because some US government contracts required such. It is said that the POSIX implementation was only pro forma, not intended or suitable for real use (i.e. Microsoft hoped the customer would accept the operating system, and then run NT-specific software, thereby giving them a moat against competing platforms).

In what specific ways was the POSIX implementation unsuited to real use?

  • 6
    Would you mind to cite any sources for either (or best all) assumptions? (Being just pro forma (and what that should mean), being not intended for use and being not suited - bonus for how such contradicting assumption can be all true at the same time)
    – Raffzahn
    Commented Jul 13, 2023 at 9:33
  • 3
    Well, I know what pro forma means, but you may want to explain what it should mean in context of an API. Also, still see here 3 independent assumptions made: 1. Being 'pro forma', 2. not suited for use and 3. not intended for use. " because it's not the kind of thing discussed in formal sources" isn't that a very strong hint for being unfounded opinion? But even so, It would help the question to cite at least that brabling (BTW, there is already an in depth answer on that site debunking that question).
    – Raffzahn
    Commented Jul 13, 2023 at 10:11
  • 2
    In my experience it was just a mass of bugs. We failed to get anything successfully ported to it.
    – Chenmunka
    Commented Jul 13, 2023 at 13:44
  • 4
    If my vague memory serves me right, the NT Posix subsystem wasn't really that bad. But the implementation in MS's development tools (which literally is not required to make an OS Posix-compliant) was less than half-baked. It was really clear they wanted to make it as difficult as possible to implement for the Posix SS.
    – tofro
    Commented Jul 13, 2023 at 14:26
  • 2
    Note that even though the POSIX subsystem was considered minimal/difficult to use/whatever as discussed in the answers it nevertheless required serious work with implications elsewhere. For example: Unlike previous Microsoft file systems NTFS supported case-sensitive filenames in addition to case-insensitive - and this had implications to the Windows subsystem too. Still does.
    – davidbak
    Commented Jul 13, 2023 at 14:43

5 Answers 5


In what specific ways was the POSIX implementation unsuited to real use?

It wasn’t unsuited, but it’s important to understand what was certified. In order to meet requirements for certain US government purchases, laid out in FIPS 151-2, Windows NT’s POSIX subsystem implemented POSIX.1, i.e. the C-level API. It was usable as-is, but actual usability was limited to what POSIX.1 provided; in particular, no end-user tools were included apart from pax, the POSIX archiver. The POSIX subsystem allowed POSIX programs to be compiled and run on NT, and that’s all that was needed.

Nowadays we tend to think of POSIX compliance as involving both APIs and user-level utilities (POSIX.2); to get that on NT, users had to pull in a third-party tool at first — OpenNT (later Interix). In 1999, Microsoft acquired Softway Systems, the developers of Interix, and made Interix available as an optional, free component for NT, Windows Services for UNIX (version 3.0 and later). This was ultimately discontinued.

It’s also worth noting that subsystems on Windows are silos, so the POSIX subsystem doesn’t provide any features accessible to “Windows” programs (using the Win32 subsystem). The POSIX APIs on Windows NT were only available to programs running on the POSIX subsystem, and programs running on the POSIX subsystem couldn’t access Win32-specific features (e.g. Win32 ACLs).

  • 8
    Perhaps a line or two explaining the consequences of being not just 'an API' but 'a subsystem' in the NT model. A (non-native-NT) program runs under one subsystem, it can't pick and choose. Apart from that, this answers the question just fine: the programming environment that was implemented was not particularly rich.
    – dave
    Commented Jul 13, 2023 at 11:28
  • 2
    Windows Services for Unix was actually powerful enough for me to port the (at the time) cygwin-based Firefox build system to it. I did have to pretend I was cross compiling from Interix to Win32 though.
    – Neil
    Commented Jul 13, 2023 at 20:56
  • 3
    Where can I read more about Windows subsystems? Trying to google it just gives a zillion results for Windows Subsystem for Linux and a few hits for Windows Subsystem for Android. Commented Jul 13, 2023 at 21:22
  • 2
    The book Windows Internals is a good source for information about the subsystems (there was also an OS/2 subsystem that was removed in, I believe, 4.0). Wikipedia has a half-decent writeup of the different subsystems that shipped, stuck in the middle of its article on NT architecture: en.wikipedia.org/wiki/Architecture_of_Windows_NT#User_mode Commented Jul 13, 2023 at 22:17
  • 2
    You can read about Windows subsystem concepts in the design documents of the late lamented Mica OS for DEC's PRISM hardware, principal designer D. N. Cutler. :-)
    – dave
    Commented Jul 13, 2023 at 22:46

You would be interested in this video, in which the vlogger installs the POSIX subsystem for Windows NT 4.0sp6 (after previously having tested the version for NT 3.1). It’s a summary of a livestream of installing POSIX and attempting to run it. He concludes that it did the bare minimum to check off the boxes for the NIST standards, required at the time for federal government contracts. (This is debatable; see below.) he does not install the full Services For Unix (SFU), or the Interix product that Microsoft later bought and made available for download.

The only POSIX utility supplied with Windows was pax, the POSIX archiver, able to unpack .tar and .cpio archives. Several other utilities were supplied with the Windows NT Resource Kit (which was sold as a CD-ROM with a set of reference books, and not widely-publicized as being necessary to use POSIX). To get the subsystem running, the vlogger was able to find old documentation about disabling incompatible NT features, configuring environment variables, and creating a termcap file. At that point, he needed to create aliases like cat for CAT.EXE, which were not provided out of the box, and run sh and vi. (One of the flaws is the complaints about behavior that is, in fact, correct, such as POSIX filenames being case-sensitive.)

To do anything else with it, you would need the Windows NT System Development Kit, as well as Visual C++. Several development utilities are shipped only as source, such as less and make. These did not compile as-is, but needed some minor fixes. With a bit of work, it is possible to build a working cc.exe, which wrapped the Visual C compiler in a UNIX-like command-line program that produces POSIX binaries.

At that point, the vlogger tests various UNIX software, and concludes that the support is too rudimentary to be useful. In fact, he says he doubts anyone actually managed to do anything with it in the ’90s, or that it was even intended to be used. The shell could not run configure scripts. All POSIX-subsystem programs are sandboxed and have no access to the Win32 API, or to graphics, memory-mapped files or networking. Only 110 API functions are supported, enough to compile and run vi, but not anything much more complicated, such as rogue or even adventure. The vlogger was able to compile trek from the BSD games collection, for both 386 and MIPS, but that was it.

Arguably, he was being too harsh, perhaps due to unfamiliarity with how UNIX worked at the time. For example, he was testing the POSIX subsystem with source code that wasn’t POSIX compliant. POSIX is specified to behave like UNIX System V, not BSD UNIX. Back in the day, I wouldn’t have expected BSD source to compile on AIX with the default settings. Even today, on Linux, those programs might not compile without -D_BSD_SOURCE. I recall needing to make minor tweaks to a large number of BSD programs, such as changing <strings.h> to <string.h> or #define strcasecmp((s1), (s2)) strcmpi((s1), (s2)). The compile errors with at least adventure seem to fall squarely in that category. Some of the other error messages that frustrated him seemed clear to me (such as the ones telling him to set an environment variable). It was common for OSes like IRIX and Solaris to add some compatibility for BSD, but what he’s trying to do would not have worked on many versions of UNIX on the market back then.

  • 9
    In theory it's useful to have this kind of report from someone who actually used the POSIX subsystem, but the author of this video is openly anti-Microsoft and seems to have limited knowledge of Windows. E.g. he describes it as "obscene" that he has to install Visual C++, the Windows SDK, and the Resource Kit to compile software for the POSIX subsystem, even though those were normal things for Windows developers to install. I don't know how many of his problems were due to unfamiliarity with the platform plus a lack of motivation to solve them since ultimately he wants to paint MS as bad.
    – benrg
    Commented Jul 13, 2023 at 20:39
  • 4
    @benrg As I mentioned, he also got frustrated about things that were correct for POSIX, such as case-sensitive filenames. The result was perhaps unduly negative. Some of those error messages also look like things that someone more familiar with UNIX could have fixed. The MAKEPATH error message, for example, seems to be clearly saying to set an environment variable, although I’m not sure if he tried it.
    – Davislor
    Commented Jul 13, 2023 at 21:02
  • 6
    As someone who has to work with AIX on a semi-regular basis, I still don't expect anything to work on it. Commented Jul 14, 2023 at 21:06
  • @benrg: Actually I consider that cc shenanigans obscene. There should have been a real cc, as, ar, and ld in the environment that runs independent of a Win32 service. On the other hand, having cc pull files from the SDK wouldn't have been a major issue.
    – Joshua
    Commented Dec 4, 2023 at 22:37

Having tried to use it, I found it had a major fault that rendered it unusable.

Delete file while in use did not function; and quite a few applications from the era expected this to work; with them not working, the multi-userness was reduced to single user if the applications worked at all.

As far as I can tell, the network was not accessible either.

As an aside note, the MS implementation made it impossible to implement POSIX.2 (shell scripting) because /usr/bin wasn't a valid path, so #!/bin/sh didn't work and #!/usr/bin/env sh didn't either. People would have been hopping mad if they had to type #!/usr/bin/env sh but at least it would have been portable to any POSIX.2 system (there were a few systems that tried to move the shell long ago; mostly it didn't work too good). The path to getopt didn't work for the same reason.

  • 1
    If an underlying file system doesn't support such an ability, I don't think a POSIX layer can add one. What would even "real" Unix do if a program attempted to use such functionality on network drive on a server which couldn't delete a file that was open for access by anyone?
    – supercat
    Commented Jul 13, 2023 at 19:40
  • 4
    @supercat: That's the point. It's effectively mandatory functionality and it wasn't provided on any filesystem. The NTFS filesystem it technically capable of it, the NT driver isn't. But in fact your question has an answer. Sun's NFS filesystem didn't implement it on the server side but rather in kernel on the client side. Other workstations saw ghost .nfsXXXXXX files, which caused issues. (Trying to implement it in user mode does not function.)
    – Joshua
    Commented Jul 13, 2023 at 20:06
  • 3
    The whole mess around 'file deletion' on NTFS seemed to be a hack for FAT compatibility, where the directory entry is the thing that allows you to get to the file, so FAT never had the capability to remove the directory entry and keep the file around until closed. I really wish they hadn't bothered to be 'compatible'.
    – dave
    Commented Jul 14, 2023 at 1:34
  • 3
    "quite a few applications from the era expected this" - sure, but what did POSIX say? That's the thing with standards. Either they say something has to behave in a standard way, or the implementation has the freedom to choose.
    – MSalters
    Commented Jul 14, 2023 at 6:57
  • 5
    @MSalters: The answer to that question would only tell us whether they "cheated" in getting POSIX certification, or whether many Unix programs depended on functionality that POSIX failed to actually specify. Either way, it was part of the functionality that normal programs expected. Commented Jul 14, 2023 at 16:14

TL;DR: Those claims do not add up.

The whole issue is, to use nice words, an urban myth. It ticks all the boxes about MS being an evil conspiracy but does not deliver any validation, neither references nor concrete claims making it open to speculation by interpretation.

An API can not be implemented and not implemented at the same time.

Being an API is the key part here. POSIX stands for Portable Operating System Interface and is an API. POSIX isn't some OS or a certain OS or kernel design and especially it's not UNIX. While it's based on Unix and tries to unify the user side API of various Unices, it can be implemented with any OS (*1).

POSIX implementation is also not a name game, but certified against a fixed catalogue. It's a point of existing or not. For that it doesn't count if the POSIX API is the only one available or even the one used most - or in what way it is implemented. No matter if implemented in basic system calls, a system library or a user side library. All that counts is that programs using POSIX functions in a way POSIX defined them can be compiled and executed in that environment.

Not defining the way of implementation is exactly what makes POSIX a portable interface definition.

Windows offers the POSIX API out of the box. The fact that other API also exist is meaningless - likewise what API an application uses. Windows is eventually among the OS least divergent from Unix, considering that true classic mainframe systems with zero commonality to Unix, like OS/390, z/OS or BS2000, are fully POSIX certified since the 1990s.

Windows NT implemented POSIX compatibility because some US government contracts required such.

MS adding it just for "some US government contracts" sound far fetched and more like trash talking than any serious angle. POSIX was a major buzz in professional computing the 1990s. A must for anyone who wanted to stay in Business.

It is said that the POSIX implementation was only pro forma,

Not sure what 'pro forma' could mean in context of an API. Either it is implemented according to POSIX specification or not. There is no inbetween (*2).

not intended

Intention is a very debatable point, rather opinion based, without any valid statement of MS themself or reliable proof thereof.

or suitable for real use

Which as well does need at least some reasoning why a provided, certified API should be suitable for 'real' use

(i.e. Microsoft hoped the customer would accept the operating system, and then run NT-specific software, thereby giving them a moat against competing platforms).

What hodgepodge should that be? Requirements are made ant meet, otherwise no procurement. So the question is not what MS hopes, but what the requirements are. Was there a requirement that some application, provided by MS uses that API, or was it that the API should be present? In the later case, it doesn't matter what API the application software uses. Hard to see anything relevant here.

In what specific ways was the POSIX implementation unsuited to real use?

That's an extreme assumption without any source and specification.

*1 - Provided that OS does offer the basic capabilities the API requires.

*2 - No, implementing only parts (like .1 or .1a, etc) is still implementing and valid for certification.

  • 5
    You seem to be overlooking that it was not just 'an API', it was 'an NT subsystem'. If you're running in the Posix subsystem, you don't have access to Win32 APIs as well.
    – dave
    Commented Jul 13, 2023 at 11:30
  • 4
    I can think in a couple of ways to completely implement something like the POSIX API while discouraging any real-world use, making it a pro-forma implementation: You could, for instance, make it slow, limit its access to system ressources like memory or disk space, or make it hard to configure or annoying to use. Commented Jul 13, 2023 at 12:03
  • 5
    I think being qualified to reveive government orders is quite a bit more more than a knicknack.
    – tofro
    Commented Jul 13, 2023 at 14:55
  • 5
    To be clear, I think it unlikely that Microsoft invested additional money to make NT POSIX work badly, but I have no difficulty believing that they didn't bother investing additional money to make it work well. We all know that once you have something that kinda sorta works, it takes additional effort to make it work well, and there are always other things that could be done with those resources.
    – rwallace
    Commented Jul 13, 2023 at 19:44
  • 3
    @Raffzahn — What rwallace said: When you need POSIX compliance only to tick off some box for a major cutomer, you can go for the most naive, minimum effort implementation that passes the necessary test. No need to optimize anything, no need to make it work /well/, or be user friendly. Besides, we are talking about a company that, at around the same time, made Windows 3.1 throw fake error messages when running on top of DR DOS. Commented Jul 13, 2023 at 21:03

I was working on porting unix software to windows NT at the time.

Strict POSIX was never a useful standard as it did not include network access or graphical outout. Unix systems that supported POSIX did not prevent the use of functionality that was not defined by POSIX.

Both Windows NT and VMS make it practically impossible to use functionality that was not in the POSIX standard from a program running in the POSIX subsystem. But there was no point in running software on Windows NT if it could not display graphics or use the network.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .