La risposta rapida è sì, una volta per soddisfare lo standard FIPS-151 e rispondere a un'offerta dell'Air Force, Microsoft ha assicurato che Windows era effettivamente conforme a POSIX. Anche se non credo che Microsoft abbia mantenuto la certificazione nelle edizioni successive, dopo averla deprecata. In Windows 10 hanno riportato gran parte di esso con un sapore Linux, anche se non credo che si siano preoccupati di ricertificare.
La risposta lunga è questa.... Alla fine degli anni '90 il governo degli Stati Uniti, con lo standard FIPS-151, ha richiesto che tutti i sistemi venduti al governo degli Stati Uniti fossero conformi a POSIX [i dettagli di gran parte di questo sono spiegati nel libro di John Quarterman'UNIX, POSIX e sistemi aperti]. Ad un certo punto, dopo la pubblicazione di FIPS-151, la US Air Force presentò un'offerta che DEC e Microsoft volevano inseguire con NT/Alpha. Microsoft/DEC (avendo solo completato l'interfaccia *.1 con il loro sottosistema posix), vinse la gara. Unisys fece causa dicendo che il solo sottosistema *.1 non era lo spirito del requisito. La difesa di Microsoft era che avevano costruito l'API e che stavano permettendo a terzi di fare il lavoro dello spazio utente, dato che il loro spazio utente era Windows e la sua Win32API. Alla fine, Microsoft/DEC furono autorizzati a procedere a condizione che una terza parte apparisse per riempire quel buco entro una certa data (ho dimenticato i dettagli). In effetti, fu loro richiesto di produrre un sistema NT basato su POSIX pienamente funzionante entro tale data.
Per soddisfare il requisito, Microsoft fece un accordo con una piccola azienda (Softway Systems) per sviluppare lo stesso che fu rilasciato come prodotto "Interix" di Softway. Che in effetti non faceva schifo. Per i veri tipi UNIX come me, ha reso Windows sopportabile e francamente ha meno stranezze dei successivi sforzi UNIX per Windows (che è un discorso diverso) perché la soluzione Softway vive effettivamente fianco a fianco con Windows, e chiama direttamente l'uKernel NT. non usa l'API di Window sotto le coperture (Cygin, UWIN, et al - siedono sopra Win32S quindi sono in definitiva limitati alle caratteristiche e alle convenzioni che Windows fornisce sotto le coperture).
I ragazzi di Softway avevano effettivamente fonti per NT da Microsoft e hanno aggiunto alcune API mancanti (per esempio il file system di NT ha sempre supportato hard e softlinks, ma Win32S non ha chiamate per crearli). Le correzioni sono state poi riprese e rilasciate negli aggiornamenti di Windows secondo necessità. I comandi sono stati presi principalmente da FreeBSD e gnu come necessario, e tutti i requisiti "open source" sono stati soddisfatti - nel senso che tutto ciò che Softway aveva preso con una GPL è stato reso disponibile (che era solo il codice dello spazio utente, come gcc e le sue librerie).
Come utente, significava che si poteva compilare eseguire codice POSIX come previsto senza alcuna mappatura reale. Il problema principale quando si "portava" codice da un "vero UNIX" come Solaris, Tru64 o una distro Linux; tendeva ad essere che il file system NT supporta un modello di sicurezza diverso da quello richiesto da POSIX e le API POSIX non hanno modo di supportare alcune di queste caratteristiche.
Eventualmente, Microsoft comprò Softway e portò il prodotto Interix in-house e lo rilasciò come SFU - Services for Unix, e successivamente lo rinominò SUA - Subsystem for UNIX-based Applications. Tuttavia, in Windows 8, SUA è stato deprezzato e poi successivamente rimosso da Windows 8.1.
A partire da Windows 10, Microsoft ha rilasciato WSL - Windows Subsystem for Linux, che ha resuscitato il sottosistema, ma lavorando con Canonical, rendere l'API una API Linux e i comandi basati su versioni Linux. L'emulazione del kernel era "clean room" e basata sul codice precedente, quindi niente di tutto ciò è contaminato dalla GPL. Ma qualsiasi cosa nello spazio utente che usa la GPL è di nuovo disponibile per il download secondo le licenze GPL. È possibile ricompilare localmente, anche se credo che le intenzioni fossero che i binari dello spazio utente da un'immagine di Ubuntu 14.04 dovrebbero essere in grado di funzionare così com'è sotto il sottosistema. I cambiamenti nel codice dello spazio utente sono davvero per far interagire il comando in un modo che sia più facile utilizzare l'NTFS di base e vivere ragionevolmente sullo stesso uKernel fianco a fianco con un sottosistema Win10.