Programy a hry ve Windows používají NT synchronization API. Wine toto implementuje přes RPC. Pokud však program nebo hra přistupuje k tomuto rozhraní často, RPC se stává brzdou.
Proto byl do linuxového jádra navržen ovladač Windows NT Sync, který by vytvořil zařízení /dev/ntsync. Výkon her se tímto zlepší o 20 (Metro 2033) až téměř 700 % (Dirt 3). Tento přístup není nový, již dříve existovaly ESYNC a FSYNC. Nový NTSYNC by měl být blíže k původnímu API ve Windows NT.
(zdroj: phoronix)
Jo, příště by někdo mohl chtít dát po naběhnutí jádra přehrát tu melodii při startu z Win95! :-D
No nevím, myslel jsem si, že kvalita kódu se posuzuje podle kódu a ne podle toho, kdo jeho změnu navrhl. Je to docela podobná argumentace jako že všichni imigranti jsou špatní, protože jen my zde v ČR víme, jak se správně žije a vůbec tu nemáme žádné zloděje a vrahy...
Kvalitně udělaná interoperabilita s Win aplikacemi je pro Linux podstatná funkcionalita. Jinak teda předpokládám, že ovladač bude formou modulu, který lze v /etc/modprobe.d/blacklist blacklistovat.
Zcela zbytecnej FUD. Ten patch neprichazi od Microsoftu, ale od tvurcu Wine.
Spuštění kódu z Cashsoftu v linuxu je dost zásadní... protože ty dva světy bez sebe nemůžou být a co potřebuješ na linuxu, tak potřebuješ i na Win. Postupně ovšem je dost možné, že celá Win éra přejde pomalu do linuxu....
A první co udělá uživatel z Win na linuxu, tak se naží spustit něco z Win... A Wine za poslední 2 roky udělal obrovský evoluční krok a šlape dál a dál. Program Wine neklapává už i jiným emulačním programům (né ve všem, ale jde pomalu na to).
Je vtipné, že kolikrát pod emulací Wine program z Win funguje lépe a stabilněji než na nejnovějších Win....
To není hoax, takhle funguje WSL 1 (Windows Subsystem for Linux). Aplikace volají knihovny OS, a ty v případě Linuxu komunikují s kernelem skrze signály. Microsoft udělal vrstvu, která tyto signály převádí na volání jádra NT. Můžeš si to představit jako WINE, akorát ten je o úroveň výš - převádí volání knihoven OS (NT jádro je tak navržené, že se nevolá jádro přímo).
EDIT: POSIX vrstvu má Windows někdy od NT 4 nebo 2000.
26. 1. 2024, 18:20 editováno autorem komentáře
>Bola tam na to, aby Microsoft a partneri mohli v obstaravaniach deklarovat podporu POSIX.
Přesně tak. Protože to tehdy vyžadovala americká vláda, která byla pro Microsoft potenciálním velkým zákazníkem.
Bohužel, ta podpora POSIXu ve Windows ani zdaleka nebyla kompletní. Specifikaci (FIPS 151-2) sice splňovala, ale nic víc. Ačkoli následně vznikl software od třetí strany určený pro portování UNIXových aplikací na Windows NT, bylo to těžkopádné a problémové řešení. Následně v době Windows XP/2003 Microsoft toto řešení třetí strany koupil a rebrandoval na "Windows Services for UNIX", otázkou však je, jak velké popularitě se toto řešení těšilo (sám jsem jej zkoušel používat a příliš mne nenadchlo). S vydáním Windows 8.x byla podpora Services for UNIX ukončena, ovšem pozůstatky původního POSIX subsystému zůstávají v NT kernelu dodnes a podle všeho právě na něm je založen "moderní" WSL 1.
Ono se rika ze je snadnější portovat cely interpret stélku než samotný shell script. Tady se ukázalo ze je jednodušší emulovat cely HW než několik syscallu .
S timhle problémem se pojí několik bugu a cele je to dost brutální mmap msync, truncate souboru a k tomu ještě zarovnavani/zaokrouhlovani stránek v paměti. Jde to to co uvidí v paměti druhy proces když první proces provede tyhle operace a zatím to vypadá ze NT memory Management tohle nedokáže emulovat.
Na straně libdbm to taky nikdo nechce řešit protože se to už moc neudrzuje a v tom je kódu už je teď milion hacku pro různé jiné Unixy. Posix nejde do takové hloubky aby to bylo skutečně přenositelne.
Hlavní problém bude to nt v názvu. Když Apple pro hardwarově akcelerovaný emulátor Rosetta 2 potřeboval v ARM ISA režim zaokrouhlení z x86, tak instrukci pojmenoval jako JavaScript rounding, protože JS chování tehdy převzal podle majoritní (prakticky jediné) architektury.
27. 1. 2024, 14:21 editováno autorem komentáře
Toto ale není pravda.
fjcvtzs a cvttsd2si mají úplně jinou sémantiku. fjcvtzs dělá wrap-around, cvttsd2si dělá truncate, ale není wrap around.
V X86_64 se pro konverzi double -> int32 v JS použije [v]cvttsd2si s 64-bit GP registrem a použije se jen těch 32 spodních bitů, tím se docílí ten wrap-around, ale je to spíš chytrý hack než feature.
Takže, fjcvtzs nemá nic společného s X86.
Myslím, že velmi dobrou tradicí linuxového jádra je nepřidávat do něj jednoúčelové věci či věci sloužící jen jedné konkrétní aplikaci - a na místo toho vymyslet nějaký obecnější mechanismus, kterým se požadovaná věc dá implementovat, ale možná ještě spousta dalších.
Krásným příkladem budiž snaha dostat do jádra kontejnery, ze kterých se nakonec vyklubaly namespaces, které jsou užitečné i na mnoho jiných věcí (aplikační sandboxy, emulace síťových topologií a mnoho dalšího).
Jiný příklad byl třeba ashmem z Androidu (potřebný pro běh emulačních vrstev typu Waydroid - tedy podobný případ jako tady u wine). Nakonec byla místo slepého přijetí této jednoúčelové věci přidána potřebná funkcionalita to memfd, což je daleko obecnější mechanismus, a Android userspace se to naučil používat.
Doufám, že i v tomto případě to dopadne podobně.
Takže podpora Android aplikací není jednoúčelová a Windows aplikací je? Myslíte, že ten memfd bude třeba za 5 let používat aspoň jedna další aplikace? V jádře je mraky různých typů synchronizací, není žádná "ta jediná správná pro Linux". V monolitickém jádru to jinak udělat nejde. Aspoň že je to jako driver modul, tj. kód se vám nemusí zavádět, dokud si neřeknete.
Zrovna ta synchronizace ve Windows, pokud by byla implementována rozumně uceleně, je obecná dost. WaitForMultipleObjects a její příbuzné jsou skvělé obecné funkce, protože (ve Windows) do nich můžete strčit cokoliv, co disponuje signálním stavem (event, mutex, process, thread, file/pipe/socket, semaphore, ...).
U linuxového jádra mě vždy z povzdálí bavilo sledovat právě tyhle experimenty s implementacemi nových primitiv. U Windows byla adopce vzhledem k politice zpětné kompatibility vždy o dost pomalejší, pokud vůbec proběhla :-).
Co se týče futexu, je fakt, že nějaký +- ekvivalent asi přišel s Vista (2006) a jejich condition variables a SRWLs (pointer-sized RW zámky, co se také snaží vše řešit v usermodu, dokud to jen jde -- v jádře se v podstatě to samé jmenuje pushlock a je to tam již od XP). Z hlediska snahy volat jádro pouze v případě nutnosti tam již dříve byly tzv. kritické sekce (v jádře tzv. executive resources), ale to jsou dost těžkotonážní obludy.
