Není to totéž. Cygwin znovu implementuje posixová systémová volání. Když se proti němu tedy kód zkompiluje, běží nativně ve Windows. Je to jako glibc pro Windows. Je to nativní. Jako když se software původně napsaný pro BSD zkompiluje v Linuxu.
Tahle nová věc spouští binárky určené pro Linux a za jízdy překládá volání na ta microsoftí. Je to jako Wine – program je napsán pro Windows, zkompilován pro Windows a ta mezivrstva mu emuluje systémová volání Windows v Linuxu. Jen tady je to naopak – je to binárka z Linuxu, očekává Linux a jeho glibc a je tam vrstva, která jí dělá dojem, že je v Linuxu.
No, on je tam oproti wine pomerne zasadni rozdil. Wine primarne nahrazuje user-space knihovny a emulovani systemovych volani se prilis nedeje (mam tuseni, ze nejaka podpora pro emulovani systemovych volani tam byla/je, ale to je spise okrajova zalezitost).
Normalni programy pro windows funguji tak, ze misto aby primo volali systemova volani, tak linkuji DLL co jsou vzdy soucasti windows a volaji funkce v nich a az ty pak pripadne volaji do kernelu. Popravde receno mam takovy dojem, ze sada a chovani syscallu je mezi windows NT a "klasickymi VxD windows" pomerne zasadne odlisna. Na windows NT pak funguje to, ze ta userspace DLL pomerne zasadnim zpusobem ovlivnuje jako jaky system se to pro ten program chova, coz pouziva treba predchudce tohle jmenem SUA (a minimalne od Vist vyse je v SUA jako defaultni shell bash, predtim to bylo to zname "ksh co podle Davida Korna neni ksh"). Fakticky i ten win32 subsystem pomerne prekvapive veci "emuluje" v userspace a kernel o nich nic nevi (treba cesty v souborovem systemu).
Historicky se da hledat asi duvod v real-mode a 16bit PM windows, kde vlastne nic jako syscally nebylo a cele to byla spousta DLL slinkovanych do jednoho velkeho adresniho prostoru (odtud pochazi treba hInstance a hPrevInstance argumenty pro WinMain(), ktere ve Win32 nemaji zrovna valny vyznam).
Jo, to máte poměrně přesně. Motivace ale byla trochu jiná. Windows NT byly od začátku psané jako vysoce modulární systém. Cílem bylo běžet na více HW platformách (Intel x86, MIPS, Alpha AXP, PowerPC), a umět běžet aplikace psané primárně pro Win32, ale také pro Win16, DOS, UNIX/POSIX a OS/2. Z toho důvodu NT používají tzv. subsystémy, kde primární subsystém je Win32, a mezi dalšími byly například OS/2, NTVDM (NT Virtual DOS Machine) a POSIX.
Kernel je pak navržený tak aby nebyl "nahoře" vázaný na konkrétní subsystém, a také tak aby nebyl "dole" vázaný na konkrétní HW platformu (od toho je tam Hardware Abstraction Layer). Proto například NTFS coby kernelový modul interně umožnuje case-sensitive názvy souborů, které mohou obsahovat cokoliv vyjma oddělovače adresářů '\', klidně včetně znaku null. Subsystem nad kernelem pak aplikuje vlastní pravidla. Například Win32 považuje názvy souborů za case-insensitive a nesmí obsahovat spoustu znaků, Win32 používá na rozdíl od kernelu koncept jednotek (například C:) atd. POSIX má naopak case-sensitive jména souborů, mountuje volumes do jednoho stromu atd.
Dalším důvodem proč subsystems řeší řadu věcí bez kernelu je výkon. Syscall je poměrně drahý, takže jde o snahu minimalizovat jejich četnost.
Když to shrnu, tak design Windows NT je opravdu elegantní. Dave Cutler si tu National Medal of Technology and Innovation Laureates plně zaslouží.
Pokud jde o rozdíl mezi Wine a Windows Subsystem for Linux, tak je to jak píšete. Wine reimplementuje knihovny poskytující Win32 API. Windows Subsystem for Linux poskytuje syscall interface, a nad tím běží prakticky nemodifikované Ubuntu. MS sice má vlastní implementaci POSIXu, ale Linux se jednak POSIXu drží velmi volně, a pak přidává řadu věcí které v POSIXu vůbec nejsou (namátkou procfs a podporu ACL).
To co pisete je hezka pohadka, ale praxe je uplne jina.
Nekde jsem cetl, ze tym co navrhoval NT (i Cutler) se nejak pohadal s MS a rozvoj NT kernelu resi potom uz nekdo jiny. Dodejme, ze bezkoncepcne.
Ano, NT subsystem neni navrzeny uplne spatne, ostatne je to castecne "prevzate" z Digitalu. A o Win32 subsys (zejmena GUI) vedeli autori uz v dobe formovani, ze tam je spousta nedomyslenosti). OS/2ka nektere tyto chyby napravovala, design delal stejny team lidi.
Jaká je praxe? Taková že jste "někde četl", že <i>tym co navrhoval NT (i Cutler) se nejak pohadal s MS a rozvoj NT kernelu resi potom uz nekdo jiny</i>? Mohu se zeptat na zdroj?
Ad o Win32 subsys (zejmena GUI) vedeli autori uz v dobe formovani, ze tam je spousta nedomyslenosti). OS/2ka nektere tyto chyby napravovala, design delal stejny team lidi - konkrétně? Pokud jsem si všiml, tak OS/2 byla architektonicky silně vázaná na x86, a API mělo dlouho řadu problémů. Například když GUI aplikace nezpracovávala window messages, tak ztuhlo všechno a byl potřeba reboot. Fakt skvělé. Nebo absence konzolového API pro 32-bitové aplikace, také potěší. A to 16-bitové konzolové API bylo dokonce tak zmršené, že většina aplikací klávesnici a myš pollovala.
Je to (nejen) moje praxe.
Jste demagog, nemam zajem zde vypisovat priklady API fci, nebo dohledavat citace.
Pokud jde o OS/2, vezte, ze OS/2ka je z vetsi casti 16bit kod poplatny sve dobe (jak nekde hezky argumentujete, to se pekne posloucha u soudu, ale technici to moc nebasti). Ja bych rekl, ze IBM OS/2ku pos*ala, kdyby nekdo vzal kod a na zelene louce postavil jiny API kompatibilni system, byl by to pekny system. Co je v OS/2 lepsi nez ve Win je popsane v jedne z knizek o GDI, dokonce vydanich v Microsoftu nebo za jeho prispeni. Je to primo citace nektereho z vyvojaru v MS, ne moudro nejakeho bezvyznamneho mhi-ho.
OS/2 znam z velkeho nasazeni v praxi, slo o cca 200 pocitacu a 10 serveru, nekolik let s tim bylo minimum problemu, pak prisel Microsoft a ze bude vyhodne prejit na Windows95, vedeni mu na to "sKoCilo" a nastalo nekonecne kolecko problemu jak se stanicema, tak se serverema, takze na servery se misto Windows NT dal postupne Linux a s tim opet nebyli problemy, jen zbyle 2 Windows Servery slouzici jen jako fileserver se museli restartovat minimalne 1x do mesice, novejsi verze pak radeji o vikendu...
Windows jsou v praxi nejhorsi system vsech dob a jednoduse dalsi priklad ze nejvetsi sr&cka se muze prosadit kdyz jde o natlak, lzi, vyhrozovani, tedy s mafii v pozadi...
V době přechodu na Windows 95 si dobře pamatuji tanečky s dodavateli unixových technologií: předražený HW s výkonem PC, kde dodavatel neměl ani veřejně dostupný ceník, a při jednání o ceně se diskutovala "provize". Zvaní zákazníků na "konference" v zahraničí, rozdávání notebooků (tedy pekelně drahých) managementu... A samozřejmě obrovská spousta problémů. Například file sharing který mršil obsah souborů, za půl roku patch který způsobil že se při zkrácení souboru zapíše chybová hláška do logu (což kupodivu moc nepomohlo), za dalších pár měsíců patch který hlášku odstranil a problém zůstal, patch který odstranil mršení souborů a snížil výkon na desetinu, patch který problém znovu zavedl a změnil hlášku v logu... Windows proti tomu byly požehnání: levné a spolehlivé, veřejně dostupné ceníky, HW i SW okamžitě k dodání, plná dokumentace online nebo za pár dolarů v rámci MSDM Subscription, profi vývojové prostředí, levná školení správy i vývoje aplikací na každém rohu.
Pokud jde o natlak, lzi a vyhrozovani, tohle jsem zažil výhradně u dodavatelů unixových technologií (například nás dost drsně zrazovali od používání file serverů jiných výrobců). Opakuje že výrobci Unixů měli dlouhou řadu korupčních skandálů. Nedohledal jsem, že by se takových praktik účastnil MS. Pokud se toho účastní váš dodavatel, zřejmě to nebude problém MS, ale toho vašeho dodavatele.