Zpravodaj o Víně – 31. 7. 2013: Když aplikace špatně používá API

1. 8. 2013 | Luboš Doležel | Různé | 5228×

Nové verze Wine: 1.6. Když aplikace špatně používá API. Podpora aplikací závislých na ovladači. Tři tečky nebo trojtečka? Podpora aplikací pro Windows RT od jádra 3.11. Změny v databázi aplikací.

Obsah

• Nové verze Wine: 1.6
• Když aplikace špatně používá API
• Podpora aplikací závislých na ovladači
• Tři tečky nebo trojtečka?
• Podpora aplikací pro Windows RT od jádra 3.11

Nové verze Wine: 1.6

Od posledního vydání Zpravodaje o víně vyšly čtyři -rc verze následované finální verzí Wine 1.6. V -rc verzích šlo jen o malé opravy chyb, podíváme se tedy jen na krátké oznámení verze 1.6 (seznam změn je opravdu velmi dlouhý).

Toto vydání představuje 16 měsíců vývoje a okolo 10 000 jednotlivých změn. Mezi hlavní noviny patří nový ovladač Mac, úplná podpora pro průhlednost oken a nový balíček Mono pro podporu aplikací v .NET.

Když aplikace špatně používá API

Reimplementovace API z jiných operačních systémů je náročný úděl – o tom není pochyb. Dokumentace ne vždy bývá nejlepší, někdy si může dokoce i protiřečit. Úplně nejhorší ale je, když nějaká aplikace závisí na chování původního API, které nebylo ani záměrem autorů tohoto API. Emulace těchto detailů se přitom může ukázat dosti náročnou. Člověk by rád řekl, že aplikace je prostě rozbitá, ale to není řešení. Michael Casadevall:

Pracuji na tom, aby Sid Meier's Civilization V (Civ5) fungovalo pod Wine relativně bez problémů. Největším problémem je to, že instalace největšího expansion packu pod Wine hru kompletně rozbila, pokud jsem nepoužil ošklivé hacky. Hlavním problémem je konkrétně to, že Civ5 načítá datové souboru v pořadí, jak je vrací Find{First,Next}File() a zblázní se, pokud je toto pořadí narušeno. Svá zjištění jsem popsal v bugu #34122.

Začal jsem hledat možné řešení, ale nejsem si jistý, co vlastně dělat. Na stránce na MSDN je jasně napsáno, že pořadí závisí na použitém systému souborů a googlení napovídá, že zatímco NTFS vrací soubory víceméně v abecedním pořadí, FAT32 je vrací podle data vytvoření a u síťových jednotek je to sázka do loterie. Dokonce se mi podařilo v Civ5 vyvolat podobné chyby tím, že jsem jej spustil ze síťového disku (kde jsem si předtím ověřil, že soubory nevrací seřazené). FindFirstFile v podstatě volá NtQueryDirectoryFile, které pak buď použije systémové volání nebo readdir, aby získalo seznam souborů v adresáři.

Michael dále popisuje, kde by provedl případné seřazení, ale celé mu to přijde špatně obzvláště, když jde o chybu v aplikaci, nikoliv ve Wine jako takovém. Na druhou stranu je pravda, že drtivé většině lidí na Windows hra bude fungovat. Na obhajobu takového „hacku“ dále říká: [...] nedivil bych se, kdyby se takový problém objevil i jinde.

Rico Schüller přišel se spoustou dalších otázek. Týkají se hlavně toho, jak by se chovalo NTFS pod Linuxem a jestli se to opravdu rozbije i na FAT32 (které se na Windows přece jen najde spíš než ext3). Kromě doporučení obrátit se na technickou podporu hry dodává:

Řekl bych, že dělání změn ve funkcích Find* je špatné, protože se zcela jistě najde aplikace, která bude záviset na pořadí podle data vytvoření na oddílech s FAT32...

Damjan Jovanovic by na to šel trochu jinak a pomohl si speciálním systémem souborů na bázi FUSE, který by řadil názvy souborů, jako je to na Windows. To se ovšem Michaelovi vůbec nelíbí – hlavně kvůli tomu, jak vinou takové hlouposti utrpí výkon. Přichází ale s jiným nápadem – zatím se k němu sice nikdo nevyjádřil, pravděpodobnost jeho přijetí je ale jistě vyšší, než kdyby se měla dělat úprava Wine s dopadem na všechny aplikace. Michael:

Ve světě Windows jsou tři věci, co se dají udělat v případě rozbité kompatibility s aplikací: změnit kód systému, napsat shim [obalení] nebo opatchovat aplikaci.

V současné době ve Wine můžeme měnit jen naše DLL; patchování aplikací za běhu je právně problematické a křehké. Proto, když je nějaká aplikace podobně rozbitá, nemáme pořádný způsob, jak to napravit. Proto navrhuji rozšířit Wine.

Během včerejších večerních debat se pracovalo na implementaci apphelp.dll, které obsahuje funkčnost databáze shimů. Dotyčný autor neměl v plánu ve Wine implementovat používání shimů, ale mám za to, že časem se bude objevovat více a více případů, kdy shim bude lepším řešením než zásah do knihoven Wine.

Michael na závěr uvedl, že v nejbližších dnech nebude mít čas se tomu do hloubky věnovat, ale chce navrhnout alespoň kus kódu, který by do budoucna mohl posloužit. Dále se pokusí problém řešit s výrobcem hry.

Podpora aplikací závislých na ovladači

Wine se za uplynulá léta dostalo do stavu, kdy šance na fungování aplikace jsou nemalé. S aplikacemi závisejících na vlastnostech velmi specifických pro původní cílový systém to ale nebude nikdy procházka růžovým sadem. Pavel Píša problém s jednou takovou řeší; má ale tu výhodu, že má přístup ke zdrojovým kódům:

Spravujeme open source chromatografický software CHROMuLAN. Bohužel je napsaný v Delphi (ve verzi 6) a nemáme prostředky na portování na Linux, ačkoliv je Linux už 18 let naší hlavní vývojovou platformou pro návrh a vývoj embedded hardwaru. Naším dlouhodobým cílem je aplikaci přeportovat na Lazarus/FPC nebo dokonce přepsat do Qt, ale na tom teď dělat nemůžeme.

CHROMuLAN pod poslední verzí Wine naštěstí běží docela dobře. Máme ale problém s přístupem k hardwaru pro získávání dat.

Zařízení jsou k počítači připojena přes speciální protokol (uLAN) na síti RS-485. Máme dokonce ovladače pro Linux (první platforma), Windows (dokonce ozkoušeno na 64 bitech) a další systémy. Máme všechno pro PCI, konvertory RS-232/485 a přídavné karty PCI RS-485. Celé softwarové vybavení dokonce funguje pod ReactOS v QEMU. Wine je ale příjemnějším řešením, pokud někdo používá Linux jako svůj hlavní desktopový systém.

Pavel dále popisuje úsilí, co doposud vynaložil:

Napsal jsem DLL/SYS jako ovladač podporující veškerá IRP_MJ_xxx a ioctl ve stylu ovladače KMD/WMD a implementoval jsem funkce pomocí volání jejich ekvivalentů nad /dev/ulan.

Ale nefunguje to. Do ul_drv.sys se dostávají jen ioctl a i ta selhávají, protože kontext není správně nastaven. Ukazatel irpStack->FileObject je nastaven na 0x66666666.

Zbytek jeho žádosti o radu se zaměřuje na oblasti Wine, kde se pokusil najít obdobnou situaci, kterou by se mohl inspirovat. Na e-mail zareagoval Vincent Povirk:

Moc o tom nevím, ale zní to, že ovladač je správným řešením. Jde ale asi jen o to, že podpora ovladačů ve Wine není na fungování toho, co potřebuješ, dostatečně dobrá. Méně násilným řešením by tedy asi bylo vylepšit podporu ovladačů ve Wine, nejlépe do stavu, kdy stejný ovladač může fungovat na Windows a pod Wine (ale nevím, zda je to možné).

Dále osvětluje možná úskalí a uzavírá to slovy:

Protože si nemůžeš dovolit trávit spousty času nad vylepšováním podpory ovladačů ve Wine, bude pro podporu tvé aplikace nejlepším řešením si asi speciálně pro sebe upravit Wine.

Juan Lang má ale lepší nápad použitelný právě v situacích, kdy je při ruce zdrojový kód aplikace pro Windows:

Dříve se v podobných situacích navrhovalo napsat linuxovou aplikaci, která přímo komunikuje s ovladačem a poskytuje rozhraní přes soket, a následně používat sokety z programu pro Windows pro komunikaci se zařízením. To je obvykle dostatečně přímočaré a člověk se nemusí tak moc vrtat ve vnitřnostech Wine, aby to rozchodil.

Vincenta napadlo ještě elegantnější řešení pomocí winelib:

Winelib DLL poskytující API pro přímý přístup k zařízení (kterou můžete použít přímo z obyčejného programu pro Windows) může být snazší než oddělený proces, pokud je člověk ochoten upravovat aplikaci.

Oba návrhy připadají Pavlovi zajímavé. Ten na závěr doplnil výsledky své analýzy toho, co by bylo nutné udělat pro podporu ovladačů pro Windows a kde je ve zdrojových kódech ReactOS možné hledat inspiraci.

Tři tečky nebo trojtečka?

Na mailing listu Wine se objevil dotaz, zda se mají v překladech používat pro vyjádření výpustky tři oddělené tečky (...) nebo znak Unicode pro „trojtečku“ (…). Ukazuje se totiž, že se ve Wine používají tři tečky všude, až na češtinu a tradiční čínštinu, kde se používá Unicode trojtečka.

Dmitry Timoshkov říká, že by se mělo zůstat u používání obyčejných tří teček, a to kvůli kompatibilitě s bitmapovými fonty, fonty bez znaku výpustky a ANSI API (GetMenuItemInfoA/GetWindowTextA). Nakonec se ale ukazuje, že odpověď na tuto otázku už mají, a to v Microsoftu. Ten poskytuje volně ke stažení příručku pro překladatele do různých jazyků. Konkrétně u češtiny se píše:

Výpustka se běžné používá v anglickém i českém uživatelském rozhraní pro označení prvku (jako je tlačítko nebo položka v menu), který spouští dialogové okno, kde člověk zadává další údaje (jako Browse... = (+) Procházet...). Vzhledem k zachování kompatibility by v těchto případech neměl být používán znak výpustky (ALT+0133). Místo toho použijte tři tečky.

Podpora aplikací pro Windows RT od jádra 3.11

Drobností, která už proběhla i zprávičkami na AbcLinuxu, je úplná podpora aplikací pro Windows RT na Linuxu/Wine (ARM). Díky commitu zařazenému do Linuxu 3.11 se registr TPIDRURW považuje za TLS registr. Jeho hodnota je tedy ukládána/obnovována při přepínání kontextu mezi vlákny v systému.

       

Komentáře

[Václav HFechs Švirga]

Omg, nesmím upgradovat wine, hraju age of conquerors (datadisk k aoe II) včetně multiplayeru (nikoliv steam HD verzi, ale původní s patchy třeba pro vyšší rozlišení) a funguje to skvěle. Ale teď vidím, že se z platinum stalo silver, to bych si zas nezahrál .

[Rovano]

Omg. Tak používej různé verze Wine pro různý software naráz.

[Václav HFechs Švirga]

OMG! Ne, prostě si zablokuju u toho balíčku upgrade . Víc windows sw nepotřebuju .

[Marv-CZ]

Člověk by řekl, proč řeší tu ptákovinu s výpustkem. Problém je v odfláklých písmech od MS, které jsou sice Unicode, ale podporovaných znaků je v nich jak šafránu. V Tahomě, kterou používají jako výchozí pro UI sice výpůstek je, ale např. tam chybí jakákoliv šipka, což mě nedávno dost nakrklo při psaní jedné multiplatformní aplikace.

A když už jsem u těch písem, tak pro pobavení: Jejich Mapa znaků po tolika letech vývoje ani v nejnovějších Windows 8.1 neumí změnit velikost okna a má jakýsi prťavý fixní rozměr.

[Kvakor]

A když už jsem u těch písem, tak pro pobavení: Jejich Mapa znaků po tolika letech vývoje ani v nejnovějších Windows 8.1 neumí změnit velikost okna a má jakýsi prťavý fixní rozměr.

Nejspíš z toho důvodu, že je to stále téměř stejná aplikace, která je nejspíš jen nově přeložená. Takových reliktů je ve Windows mnoho, hlavně v některých méně používaných nastaveních. Na druhou stranu budu raději mít cosi, co vypadá jako z časů Win3.1, pokud to bude fungovat a budu vědět, co kde nastavit, než mít nějaké "moderní" rohranií, co by se s každou verzí kompleně překopalo.

[David Jaša]

Na druhou stranu budu raději mít cosi, co vypadá jako z časů Win3.1, pokud to bude fungovat a budu vědět, co kde nastavit, než mít nějaké "moderní" rohranií, co by se s každou verzí kompleně překopalo.

Tenhle přístup bych žral, kdybych v posledních 5 letech neotevřel gucharmap.