Zpravodaj o Víně – 10. 2. 2012

22. 2. 2012 | Luboš Doležel | Různé | 3150×

Je dobré hrát si s nastavením Direct3D? Americké exportní embargo. Přeložit, nebo nepřeložit "Program Files"? (Velké) zrychlení díky wineserveru v rámci procesu.

Obsah

• Je dobré hrát si s nastavením Direct3D?
• Americké exportní embargo
• Přeložit, nebo nepřeložit "Program Files"?
• (Velké) zrychlení díky wineserveru v rámci procesu

Je dobré hrát si s nastavením Direct3D?

U velkého množství her v AppDB naleznete poznámky uživatelů, že je pro funkčnost té či oné aplikace nebo hry nutné změnit vybrané hodnoty v registrech. Stephen Chao přišel s patchem, který do winecfg přidává nový tab, odkud je možné většinu měněných hodnot snadno naklikat.

Čekám na reakce na patch pro winecfg, který jsem včera poslal. Měl bych to posílat do mailing listu pro patche?

Stvořil jsem tento patch, abych se zbavil frustrace z toho, že musím na novo přidávat všechny klíče kolem Direct3D do registrů pokaždé, co si vymažu adresář .wine. A také proto, abych si byl jistý, že to, co dělám, má nějaký efekt, tedy že tam nejsou překlepy nebo že nepoužívám zastaralé informace z různých stránek na AppDB. Jako bonus je to automaticky propojené se záložkou Aplikace.

Dmitry Timoshkov poslal ID commitu, ve kterém byl odstraňován groupbox s volbami pro nastavení režimu shaderů. Stephen odpověděl, že tento patch viděl...

Znamená to, že ani žádné jiné volby pro Direct3D by neměly být z winecfg přístupné? Z mé vlastní zkušenosti z procházení stránek na AppDB si všichni s nastavením d3d hrají.

Austin English zareagoval slovy, že ani když to dělají všichni, neznamená to, že to je zrovna moudré. „Spousta stránek na AppDB také doporučuje nastavit tunu různých DLL na native, což se rozhodně nedoporučuje.“ Pak se ozval ještě Vitaliy Margolen:

To [že to všichni dělají] je přesně ten důvod, proč tyto volby byly odstraněny. Aby se zabránilo lidem v tom, aby si rozbíjeli nastavení Wine a pak hlásili neplatné bugy. „Oficiální“ postoj Wine k tomto typu voleb je:

1. Wine by mělo detekovat všechny volby automaticky. A poladit je podle potřeb (v závislosti na aplikaci nebo požadovaných funkcích).
2. Pokud bod 1 nefunguje – nahlašte bug, aby bylo Wine opraveno.

P.S.: Pokud opravdu potřebujete opětovně nastavovat své vlastní volby – uložte je jako soubor .reg. Pak je můžete importovat pomocí regedit.

Americké exportní embargo

Jak jste asi už slyšeli nebo tušíte, Spojené státy (a řada dalších zemí) uvalily embargo na Írán. Toto embargo se vztahuje na vše možné a i když to může na první pohled působit trochu absurdně, týká se to i (open source) softwaru. Aidin Gharibnavaz napsal vývojářům, že SourceForge neumožňuje stažení Wine v některých zemích:

Drazí vývojáři Wine, SourceForge ve výchozím nastavení blokuje stahování z některých zemí, například z Íránu. Více informací na sourceforge.net.

Takže pokud by z vaší strany nebylo protiprávní, abyste umožnili Íráncům stahovat váš software, prosím přenastavte ExportControl v ProjectAdminu na SourceForge, abychom váš skvělý software mohli užívat. Děkuji.

Juan Lang uvedl, že to s legalitou může být trochu složitější:

Ať už to je či není protiprávní, a že nejsem právník, věřím, že není legální umožnit stahování z USA, aniž by se nejprve podala žádost o přezkoumání.

Wine obsahuje obecné šifrovací algoritmy, nejen autentizační, a nemá omezení na délku klíče. Ačkoliv řada věcí kolem kryptografie byla získána z volně dostupných zdrojových kódů, nevím, zda věci jako ověřování certifikátů spadají do požadavků na přezkoumání.

Proto si nemyslím, že můžeme povolit stahování z Íránu na SourceForge. Přesto je ale možné získat zdrojový kód Wine jiným způsobem.

Omlouváme se za problémy.

Marcus Meissner napsal prakticky to samé. Kromě toho ale poradil vyzkoušet další odkazy na stránkách Wine, protože některá místa možná Írán neblokují.

Přeložit, nebo nepřeložit „Program Files“?

Přeložené názvy systémem vytvářených adresářů ve Windows jsou jedním z rozporuplných rozhodnutí, která vývojáři Windows učinili. A protože se Wine snaží Windows co nejvíce připomínat, týká se tento neduh chtě nechtě i Wine. Francois Gouget se této otázce začal opět věnovat a podle všeho v tom mají tak trochu bordel i v Redmondu.

V shell32.rc máme spoustu shellovských cest k přeložení. Na základě mých francouzských VM a počítačů jsem nicméně toho názoru, že by se řada z nich neměla překládat. [...]

Při pohledu na Windows 2000 a novější zjišťuji, že se Microsoft rozhodl překládat jen adresáře, které jsou uživateli nejvíce viditelné. To by vysvětlilo, proč „Application Data“, „Local Settings“ a podobné nejsou přeloženy.

Nicméně poslední móda (např. Windows 7) vypadá tak, že samotné názvy složek na disku nejsou nikdy přeloženy a místo toho se používá soubor 'desktop.ini' pro zobrazení lokalizovaného názvu v GUI. Takže na Windwows 7 je například adresář „Program Files“ pojmenován právě takto na disku, ale ve Windows Explorer se kvůli souboru „desktop.ini“ ukazuje jako „Programmes“. (Stojí za všimnutí, že „Program Files (x86)“ nemá žádné „desktop.ini“, a tak to není v Exploreru přeloženo. To je ale bordel!)

Tak co s tím budeme dělat?

K e-mailu byl přiložen patch, který označuje některé řetězce tak, aby překladatelé věděli, že tento text se překládat nemá. Další debata se točila kolem vytváření symbolických odkazů mezi přeloženým a nepřeloženým názvem. Podle Francoise to ale není zrovna dobrý nápad. Podobný způsob překládání tradičních adresářů jako na Windows 7 se totiž ujal i na Linuxu.

Myslím si, že máme na výběr mezi následujícími možnostmi:

1. Přeložit názvy složek, které je nutné přeložit, pomocí resource souborů.
2. Nebo nepřekládat názvy složek vůbec a použít desktop.ini, aby se v GUI zobrazily lokalizovaně (což si může vyžádat nějaký ten vývoj navíc).

Možnost 2) je to, jak se to teď dělá, snad i v GNOME to tak je. Takže vymýšlení vlastních způsobů podle mě není dobrý nápad (navíc by tu pak byl problém s duplicitními názvy při změně locale).

Myslím si, že by bylo dobré jít cestou 2), i kdyby se podpora pro soubory desktop.ini hned neřešila. A teď mě opravdu zajímá jen to, co dělat s resource stringy.

Alexandre Julliard odpověděl, že způsob 2) by měl být v pořádku. Pak už by se „problémové“ názvy ani nemusely dávat do resource souboru a mohly by být jako konstanty ve zdrojovém kódu.

(Velké) zrychlení díky wineserveru v rámci procesu

Daniel Santos zaznamenal, že wineserver běžící v odděleném procesu způsobuje značný propad v některých ne zrovna hezky napsaných aplikacích. Teď se vrátil s lehce přepracovanou verzí hacku, který spouští wineserver v rámci procesu wine:

Přikládám svůj hack po nějakém tom pročišťování, polaďování a dalším experimentování (především v podobě zjišťování, co nefunguje). Je to stále dost čerstvý kus kódu.

Před 3 lety jsem dostal takový nápad, když jsem zrovna hrál Star Wars Battlefront (1 a 2) a načítalo se mi to tak dlouho, že jsem tomu nemohl pomoci řešením bottlenecků (aplikace při načítání chrlí GetForegroundWindow a PeekMessageA, obojí volá 22000 krát za sekundu) a pak jsem se konečně odhodlal dát tomuto hacku šanci. Abych to shrnul, načítání nové mapy trvá pod Wine 75 sekund, přičemž na Windows to trvá mezi 10 a 15 sekundami (mno, na mém laptopu, který je pomalejší než můj desktop). S tímto hackem se to zkracuje na 8 sekund pod Wine, což je asi tak 10× rychlejší.

Tento hack sestavuje libwineserver.so, které hlavní aplikace (tedy ta první, co spustíte) nastartuje v novém vlákně v rámci současného procesu, pokud je nastavena hodnota prostředí DIRTYNASTYSPEEDHACK. Pak jsou volání wineserveru dělána napřímo. Následně spuštěné programy ve stejném WINEPREFIXu komunikují s vaším procesem pomocí tradičních rour.

Sestavování mi ještě nefunguje tak, jak by mělo, aktuálně se sestaví jen libwineserver.so při sestavování serveru (tedy se nesestavuje pokud to máte nakonfigurované s --with-wine-tools). Autotools nepatří mezi mé silné stránky, takže kdyby někdo měl zájem a přidal to tak, tak bych to ocenil

Toto zrychlení si vybírá svou daň v tom, že stabilita vašeho wineserveru (a tedy všech aplikací běžících pod touto instancí) závisí na stabilitě vašeho programu. Takže pokud to máte zapnuté, váš program může zhroutit instanci wine. Další věcí je to, že i když to řeší dlouhé načítání ve Star Wars Battlefront II, tak se to chová dost divně – jde o správné přehrávání zvukových bufferů a HID vstup (pokud pohybuji myší pomalu dolů, tak se bude pohybovat pomalu nahoru). Tyto problémy zmizí jakmile zapnu ladění (což je asi kvůli tomu, že to program zase trochu zpomalí).

Vyzkouším to na pár dalších aplikacích, co běží pod Wine pomalu (jako Finale 2010).

Největší přakážkou je ale vždy to, „jak to udělat správně“. A to je právě to, co brání tomu, aby se taková věc dostala do Wine - Alexandre řekl, že to půjde jen přes jeho mrtvolu. Juan Lang pak přispěchal s odůvodněním:

Asi nevíš o tom, že něco takového před lety udělalo Transgaming a za zařazení dost lobovalo. Už tehdy to AJ zamítl. Důvody, proč to nezařadit, zůstávají stejné: kvůli tomu, že zabugovaná aplikace může sejmout wineserver, se nemůžeme nikdy ani pokusit o podporování takové zběsilosti. Jakýkoliv nahlášený bug by v takové situaci hned byl podezřelý. Ještě horší by pak bylo, kdyby lidé v hlášeních chyb zapomínali zmínit, že to zapnuli.

Takže ne, nikdy takovou věc do oficiálního vydání nezařadíme. Už tak máme dost problémů s lidmi, co hlásí chyby na nepodporovaných konfiguracích.

Můžeš si udržovat svůj vlastní fork nebo patch, pokud chceš, aby to lidé mohli zkoušet na svých vlastních sestaveních Wine, pokud chtějí.

       

Komentáře

[Honz]

Wine určitě patří mezi nejzajímavejší kusy OSS kódu, přimlouvám se za pravidelné novinky od Vína...

[ike]

tak se primlouvam...

[Luboš Doležel (Doli)]

Tak to mě těší. Zpravodaj neměl v poslední době až tak dobrou čtenost, tak jsem myslel, že to moc zajímavé není.

[PetrHL]

Rozhodně to zajímavé je! Taky prosím o pokračování. Díky!

[Bedňa]

+1

Wine stále zaujímavejší projekt a už som narazil na program ktorý ide pod Linuxom lepšie, ako natívne vo Windows.

[Mustafa]

No jo, akorát že v tom článku není to, co dřív běžně bývalo., Takovéto silver, gold apod.

[Luboš Doležel (Doli)]

To tam dávám, jen když vycházejí díly pravidelně. Takhle by to bylo silver/gold za poslední půlrok, což by bylo na několik stránek.

[Limoto]

+1, patří to pro mě mezi top věci na ábíčku...

[LuděkS]

Určitě to má význam. Také to sleduji a děkuji!

[Bedňa]

Dík za spravodaj, len táto veta by sa zišla upraviť:

Austin English zareagoval slovy, že to, že to dělají všichni, neznamená, že to je zrovna moudré.

[Marián Kyral]

Podle mně je to správně. Může to to připadat nezvykle, ale to neznamená, že to je špatně. A když tak na to tak koukám, nenapadá mně, jak to napsat jinak. Leda tak to převést na přímou řeč,

[Marián Kyral]

s/to to/ti to/

[David Watzke]

první "že to" změnit na "že skutečnost"

[Marián Kyral]

Jo tak to by šlo.

[Sten]

Doporučuji spíše „že [ani] když to dělají všichni, neznamená to“, dvoje „že to“ za sebou je typograficky podivné.

[David Watzke]

Ok, tak nějak jsem to tam dal.

[Belias]

Děkuji za skvělý článek o dění kolem Wine :)

[Vin]

Jo, zajímavý článek, rozhodně pokračujte v překladech.

[tomo_tn]

Istotne pokracujte v prekladoch, ono podla mna menej diskuzie pod clankom znaci dobry/ zaujimavy clanok, vecsinou totiz diskutujuci...

[stativ]

Myslím, že tohle je origiální tvorba, žádný překlad. Jinak článek se mi líbil, pokračování bych se rozhodně nebránil .

[Marián Kyral]

Taktak, pokračovat v originální tvorbě a překládat do angličtiny a nabízet i jinde

Já si o změnách ve Wine vždy rád přečtu.