Zpravodaj o Víně – 12. 5. 2014: Konec podpory 16bitových aplikací?

13. 5. 2014 | Luboš Doležel | Různé | 4545×

Nové verze Wine. Rychlost mutexů ve Wine. Konec podpory 16bitových aplikací? Obrat v soudním sporu Oracle vs. Google.

Obsah

• Nové verze Wine
• Rychlost mutexů ve Wine
• Konec podpory 16bitových aplikací?
• Obrat v soudním sporu Oracle vs. Google

Nové verze Wine

Wine 1.7.17 vyšlo 18. dubna s následujícími změnami:

• Rozsáhlejší implementace Správce úloh.
• C runtime je více kompatibilní díky sdílení zdrojových souborů.
• Opravy v podpoře joysticků na OS X.
• Různé opravy chyb.

Wine 1.7.18 vyšlo 2. května s následujícími změnami:

• Lepší podpora pro OLE Accessible Object.
• Vylepšení v nastavování velikosti oken v ovladači Mac.
• Opravy různých paměťových problémů, které našel Valgrind.
• Několik funkcí MSHTML navíc.
• Pročištění v DirectDraw.
• Různé opravy chyb.

Rychlost mutexů ve Wine

I když pod Wine v dnešní době funguje už snad většina aplikací pro Windows, častým problémem zůstává výkon. Ani nemusí jít o obecný problém Wine, jako spíš spoléhání původních vývojářů na to, že určité API Windows je a bude vždy natolik rychlé, aby bylo možné jej využívat natolik intenzivně, jak činí.

Jeden z uživatelů Wine, John Found, vyvíjí aplikaci, která dobře funguje pod Windows, pod Wine se ale potýká s obtížemi:

Nedávno jsem začal pracovat na vícevlákenné aplikaci používající mutexové funkce, konkrétně: WaitForSingleObject a ReleaseMutex. V benchmarcích jsem přišel na to, že tyto funkce jsou 50 až 100krát(!) pomalejší než na Windows. A to se jedná o situaci, kdy mutex používá jen jediné vlákno – na nic se tedy nečeká.

Testovací program zkompilovaný nativně pro Linux (používající knihovnu pthreads) je jen 1,5krát pomalejší (v porovnání se stejným programem, který mutexy nepoužívá vůbec), což je přijatelné.

Co mám tedy udělat, abych tyto funkce urychlil? Je to bug (který má být nahlášen a opraven), nebo nějaký fundamentální problém v architektuře? Měl bych implementaci mutexů řešit jinak?

Vincent Povirk popsal, že se problém skrývá v tom, jak se s mutexy musí pod Wine kvůli jejich možnostem pracovat:

To je kvůli tomu, že každé volání nad jaderným objektem probíhá přes RPC do procesu wineserver.

Sémantika věcí jako DuplicateHandle a všech různých dalších jaderných objektů, na které je možné čekat, musí být věrně přenesena do Wine. Takže i v případě, že jde o jediný objekt používaný jediným vláknem, by sis pro optimalizaci této situace musel být nějakým způsobem jistý, že nikdo nevytvořil v jiném procesu duplikát. Nebo bys musel dát winesevreru dostatek informací k duplikaci, zatímco bys mohl čekat/manipulovat s objektem bez volání RPC.

Takže si nejsem jistý, že jde o fundamentální problém v architektuře, ale je tu hodně věcí, na které je potřeba myslet. A nedoporučil bych řešení takových problémů novým vývojářům Wine.

John se zeptal, zda by mohl výkonu nějak pomoci volbou jiného typu synchronizačních primitiv. Sebastian mu nějaké alternativy doporučil:

[...] Mohl bys buď použít kritické sekce (které interně na Linuxu používají velmi rychlé futexy) nebo odlehčené read/write zámky (viz MSDN), jež používají volání wineserveru jen v případě, kdy blokují. Obě metody by rozhodně měly vést k lepšímu výkonu.

John potvrdil, že mu přechod ke kritickým sekcím zvedl výkon desetinásobně. Na Windows rozdíl tak znatelný nebyl.

Konec podpory 16bitových aplikací?

Tentokrát z mailing listu Wine krátce odbočíme na mailing list linuxového jádra. V dubnu byl do jádra zařazen patch, který znemožňuje vytváření 16bitových segmentů na x86-64. Je to na první pohled nepodstatná věc, ostatně i v rámci Jaderných novin byla okomentována slovy: Jelikož běh 16bitového kódu na těchto systémech tak či tak moc dobře nefunguje a není jasné, jestli to vlastně někdo používá, tak se tato změna považuje za bezpečnou.

Pravdou je, že mezi běžnými aplikacemi pro Linux budeme jen stěží hledat nějakou, která by 16bitové segmenty potřebovala. Wine ale není úplně běžná aplikace... Nejprve se podívejme na informace připojené ke commitu, abychom pochopili, proč mají vývojáři jádra zájem na tom něco podobného zakazovat:

x86-64, modify_ldt: Zákaz 16bitových segmentů na 64bitových jádrech

Instrukce IRET, v případě, že se vrací do 16bitového segmentu, obnovuje pouze spodních 16 bitů ukazatele do uživatelského prostoru. Na 32bitových jádrech pro toto máme softwarovou obezličku („espfix“), ta ale závisí na nenulové bázi segmentu zásobníku, která není v 32bitovém módu dostupná.

Jelikož je 16bitová podora na 64bitových jádrech stejně tak nějak rozbitá (chybí režim V86) a většina (pokud je skoro všechny) 64bitových procesorů podporuje virtualizaci, jednoduše zamítejme pokusy o vytvoření 16bitového segmentu na 64bitovém jádře.

Krátce na to se ozval Brian Gerst s obavami o funkčnost 16bitových aplikací pod Wine:

Nachází se tento bug i na moderních CPU? Tato změna rozbíjí spouštění 16bitových aplikací pod Wine. Mám tu několik opravdu starých her, které bych si chtěl občas zahrát, a nemám tu kopii Win 3.11, abych si je dal do VM.

Diskuze pokračovala dál. Jaderní vývojáři by rádi tento únik informací odstranili, ačkoliv se někteří domnívají, že únik vyšších bitů není až tak závažný. Linuse pak zajímá to, jestli 16bitové aplikace opravdu někdo používá a opravdu to celé nějak funguje:

Pokud vím, tak 64bitová Windows 16bitové binárky nepodporují, takže jsem předpokládal, že ani Wine to na x86-64 neumí. Ne, že bych to očekával z nějakých technických důvodů.

NICMÉNĚ. Rád bych slyšel něco konkrétnějšího než „v poslední době jsem to nezkoušel“. Pravidlo „nerozbíjíme uživatelský prostor“ se vztahuje na skutečné *uživatele*, nikoliv na testovací programy.

Najdou se lidé, kteří opravdu používají staré 16bitové programy pro Windows pod Wine? Na tom právě záleží.

Na tuto otázku Linusovi odpověděl sám Alexandre Julliard:

Ano, stále máme mnoho uživatelů a stále dostáváme hlášení chyb u konkrétních 16bitových aplikací. Bylo by moc hezké, kdybychom je mohli na x86-64 nadále podporovat, hlavně kvůli tomu, že Microsoft to nedělá

Později se dokonce ukázalo, že tato změna v jádře rozbíjí i některé 32bitové aplikace pro Windows (problémový patch byl mezitím backportován do starších jader):

Vypadá to, že jsou rozbité i některé 32bitové programy, jelikož po přechodu na Linux 3.14.3 nemohu spustit svůj starý šachový program:

----
| % file CB70.exe 
| CB70.exe: PE32 executable (GUI) Intel 80386, for MS Windows
| % LANG=C wine CB70.exe
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
| modify_ldt: Invalid argument
`----

Později se objevily také stížnosti na nefunkční Microsoft Office 2000. Jelikož se uživatelům a vývojářům snad podařilo jaderné vývojáře přesvědčit o důležitosti podpory 16bitových segmentů na x86-64, H. Peter Anvin začal pracovat na espfix pro x86-64, aby nebylo nutné podporu zrušit. Doufejme tedy, že nám i staré aplikace budou pod Wine nadále fungovat.

Obrat v soudním sporu Oracle vs. Google

V USA už několik let probíhá soudní spor mezi firmami Oracle a Google kvůli „okopírování“ podoby javovských API na Androidu. Tento krok byl ze strany Googlu nezbytný pro to, aby původní javovský kód mohl beze změny fungovat i na Androidu. Oraclu se ale nelíbí to, že Google takto obešel nutnost licencovat si od Oraclu „technologie“ a využil tak stávajícího ekosystému kolem Javy bezplatně.

První rozhodnutí v tomto sporu bylo pro Google příznivé: deklarace API nepodléhají autorským právům. Oracle však nebyl s tímto závěrem spokojen, a proto se odvolal. Nyní odvolací soud rozhodl, že deklarace autorským právům podléhají, což nejeden softwarový projekt vyděsilo. Jinak tomu nebylo ani na mailing listu Wine:

[odkaz na EFF]

Toto jsou opravdu znepokojivé zprávy. Jaké jsou dopady na Wine, pokud by to nakonec takto dopadlo?

Shachar Shemesh trochu vyjasnil situaci:

Hlavně to ještě nijak nedopadlo. Soud řekl, že otázka interoperability je předmětem „fair-use“, nikoliv platnosti autorských práv. V tomto ohledu jde z různých důvodů o porážku pro celé odvětví, ale nemusí to mít okamžitý dopad na Wine.

Dalším aspektem, pokud to takto dopadne, je pak to, že důsledky pro kohokoliv, kdo se snaží přistupovat k softwaru pod GPL, budou neméně závažné. Nejsem si jist, že by z toho měl MS prospěch. Jestli to nějak změní jejich postoj k Wine, je pak další otázka.

Stefan Dösinger následně odkázal na zajímavý článek vztahující se k rozhodnutí odvolacího soudu:

Doporučil bych všem přečíst si komentář od Bradleyho Kuhna. Myslím si, že za pozornost stojí i jeho doporučení přečíst si celé soudní rozhodnutí, a jelikož jsem tak sám neučinil, nebudu se k této věci dále vyjadřovat.

V odkazovaném blogovém zápisu mj. stojí, že odvolací soud zásadně překroutil tvrzení Google ohledně „okopírování“ deklarací. Zatímco Google říká, že se jeho deklarace v mnohém podobají, ale také se v mnohém liší, soud tvrdí, že se Google přiznal, že to zkrátka „obšlehnul“. Podstatné je však to, že soud netvrdí, že Google porušil nějaká práva: pouze říká, že nelze celou otázku shodit ze stolu slovy, že zde autorská práva nemají žádný dopad.

Změny v databázi aplikací

Omlouváme se za nepřítomnost přehledu změn v tomto vydání. Od příštího vydání bude přehled opět přítomen.

       

Komentáře

[Salamek]

C runtime je véce kompatibilní díky sdílení zdrojových souborů.

[véca]

Je více než půl třetí odpoledne a véce je pořád tam. Kde jsou ty časy, kdy se chyby po upozornění v diskusi opravovaly...

[Lol Phirae]

Kde jsou ty časy, kdy nebyly diskuse u články zasrány off-topic kydy o překlepech.

[Maďar]

Kde jsou ty časy, kdy články byly bez překlepů a pravopisných chyb.

[ja]

Kde jsou ty casy, kdy se pod clankem nikdo neptal na to, kde jsou ty casy?

[Honz]

Mám kdesi nějakou Zebru, ta by mohla být 16bitová, vyzkouším ji...

[xkucf03]

Můžu zkusit Pampucha, taky od Zoneru

[Mintaka]

A co na to Bulánci?

[bulanek]

Už zase nejdou.

[Hans1024]

H. Peter Anvin je teda manik. Napred rikal, ze to (win16 segmenty) nikdo nepouziva, prestoze mu bylo opakovane receno, ze se to pouziva. A kdyby to nezachranil Linus se svym "we do not break userspace", zadny espfix by nepsal. (tim nechci nijak shazovat praci kterou na Linuxu odvedl) Asi nema rad "16bitove smejdarny"

Vyvojarum WINE jsem to psal na mailing list, ale jakozto outsiderovi mi to musel nekdo schvalit, coz nejaky ten den trvalo a Alexandre Julliard prisel az kdyz uz to tak nejak bylo rozhodnuto.

[Hans1024]

(win16 segmenty)

jsem chtel asi napsat 16-bit segmenty a win16 aplikace, nak se mi to spojilo

[D.A.Tiger]

Je hezke, ze hledaji zpusoby jak zvysit vykon aplikaci pod wine. Ale stejne, nejaky ubytek tam bude vzdycky a zalezi na mnoha faktorech jak moc bude poznatelny, protoze wine je proste dalsi vicemene systemova vrstva vlozena mezi jadro a aplikaci.

[Luboš Doležel (Doli)]

Na podobné věci by byl ideální nějaký volitelný jaderný modul + nechat původní řešení jako fallback.

[D.A.Tiger]

Jj, taky si to myslim. Minimalne nikourovnova implementace Win Api by mohla byt primo nad jadrem - podle me by to dost veci resilo, vcetne neprijemnych ubytku na vykonu aplikaci.

Ale zas na druhou stranu, kdyz dojde k chybe v aplikaci, kterou neodchyti, muze se sirit pres systemova volani az co do nejnizsich vrstev. Takhle proste spadne jen Wine. Jenze kdyz se to dostane pres prislusny modul az do jadra, destabilizuje to cely system (nemluve o tom, zda by to nedokazalo nadelat i nejake vedlejsi skody). Je otazkou zda tohle bychom umeli vyresit, nebo bychom takove situace byli ochotni riskovat...

[luky]

To mi prijde zbytecne komplikovane, IMO by stacilo vytvorit jen futexfd() syscall a potom by wine mohlo implementovat windowsacke cekani pres poll. Zbytek nebude tak citlivy na vykon.

[D.A.Tiger]

Je to komplikovane, ano to priznamvam. Ale jde mi o to, ze nikourovnova systemova volani jsou zakladem vicemene vseho. Proto si myslim, ze implementace jednoho syscallu sice pomuze, ale nezchrani vse...

[David Heidelberg]

měl si na mysli tohle? http://www.longene.org/en/index.php

[D.A.Tiger]

Neco takoveho. Priznam se, ze o tom projektu jsem doted vubec nevedel.... Zkousel jsi jej?

[David Heidelberg]

nezkoušel, ale myšlenka mi to přijde výborná (rozhodně to zrychlení bude citelné, dle nějaké historické diskuze z roku 2000 psali o 20% oproti Win2000, a 900% oproti Wineserver ). Dle wiki vypadá vývoj živě.

Jako drobnou nevýhodu považuji převažující čínštinu na fóru a minimální adopci ze stran distribucí.

Ale mám pocit, že vzít Longene + nativní podporu D3D9 pro Wine , tak už se blíží doba, kdy hry pro Windows poběží rychleji na hybridním Linuxu :)