Portál AbcLinuxu, 6. května 2025 18:19
Zpravodaj o Víně – 1. 10. 2011
Články
-
Zpravodaj o Víně – 1. 10. 2011
Aktuální verze Wine. Stav DIB enginu. Asociace souborů .bat a .com. Repozitář s aktuální Git verzí pro Ubuntu. Pořádná podpora iTunes (a USB obecně).
Obsah
Aktuální verze Wine
link
Od posledního vydání Zpravodaje o Víně uplynulo mnoho času. Nemusíte se ale bát, že bychom přeskočili důležité dění. Každopádně vyšla celá řada nových verzí Wine – žádné stabilní, jen samé vývojové. Podívejme se na dvě poslední:
Wine 1.3.28 vyšlo 9. září 2011 s následujícími novinkami:
- Počáteční verze parseru pro VBScript.
- Automagický výběr zvukového ovladače.
- Podpora informací o svazku na souborových systémech UDF.
- OpenGL renderer je nyní výchozím pro DirectDraw.
- Dialog pro konfiguraci zařízení v DirectInput.
- Podpora SetDIBitsToDevice v DIB enginu.
- Několik vylepšení v parseru cmd.
- Různé opravy chyb.
Wine 1.3.29 vyšlo 23. září 2011 s následujícími novinkami:
- Rozsáhlá podpora VBScriptu.
- Různá vylepšení pro komponentu kalendáře.
- Řada oprav a optimalizací v podpoře XRender.
- Několik nových funkcí v runtimu MSVCP.
- Řada oprav v podpoře zvuku.
- Pročištění v DirectDraw.
- Různé opravy chyb.
Stav DIB enginu
link
O DIB enginu už slýcháme velmi dlouho. Připomeňme, že jeho existence je zásadní pro (nyní dost nízký) výkon vykreslování klasických okenních aplikací. Po řadě zavržených implementací se nyní do Wine konečně postupně jedna dostává. Massimo Del Fedele je autorem jedné ze zavržených implementací a teď ho zajímá, jak postupuje práce na té vyvolené:
V poslední době jsem zpozoroval mnoho patchů souvisejících s DIB enginem, sestavil jsem si poslední verzi zdrojáků a vyzkoušel jsem to... Žádné zlepšení výkonu v AutoCADu, mé testovací aplikaci. Takže by mě zajímalo, jestli už engine funguje, aspoň částečně, nebo nefunguje vůbec. Pokud funguje, je třeba nějaký přepínač/hodnota proměnného prostředí pro zapnutí?
Omlouvám se, že se tu tak vyptávám, ale kromě git commitů jsem neviděl žádné vysvětlení, co se děje. I některé uživatele mého starého enginu, co jsou nuceni používat starou verzi Wine (už jej kvůli nedávným změnám nelze aplikovat na současnou verzi), by zajímalo, co se děje.
Odpověděl mu Octavian Voicu, který ale upozorňuje, že vychází jen z commitů a vlastního zkoumání kódu:
Většina doposud udělané práce byla na úrovni architektury – vytváření infrastruktury, která zvládne inkrementální vývoj DIB enginu (viz dlls/gdi32/dibdrv/). Nový DIB engine je standardně povolen a je aktivován automaticky (přidán na zásobník ovladačů), pokud SelectObjectu předáte DIB. Když DIB engine nějakou funkci neimplementuje, je předána dalšímu ovladači na zásobníku. Pokud nejsou některé funkce podporovány (např. specifické formáty pixelů; styly pera nebo štětce), opět se volání přesune na další ovladač na zásobníku, kdykoliv je tyto funkce třeba použít (např. při kreslení čáry, když není aktuální pero podporováno).
Aktuální stav je:
- většina formátů pixelů je podporována, pokud už ne všechny (1 bpp je ale trochu zvláštní případ a má ještě nějaké problémy);
- většina per je implementována (vyjma geometrických per nebo per s tloušťkou větší než 1);
- podpora štětců vypadá docela úplně;
- většina grafických primitiv zatím NENÍ implementována.
Faktem je, že jedinými primitivy, která jsou aktuálně implementována, jsou LineTo, Rectangle, PaintRgn a PatBlt, minimum potřebné pro ozkoušení, že pera a štětce správně fungují; žádné blity; žádné polygony, ani další podivné tvary; žádné kreslení fontů; dokonce ani ne get/set pixel. To je asi důvod, proč AutoCAD ještě nejeví známky zlepšení. Na druhou stranu je většina zrádných architektonických věcí hotová, takže hádám, že viditelná zlepšení nejsou daleko.
Od odeslání tohoto e-mailu se věci posunuly dále, v posledních verzích už můžeme vidět např. podporu dalších Blt operací. Massimo řekl, že bez podpory fontů je jasné, že není v AutoCADu nic znát. James McKenzie se zapojil do debaty s návrhem:
Možná by stálo za to přepracovat kód nad opravami od Huwa tak, aby tvé patche fungovaly, než Huw dokončí svou práci.
Tohle by ti pomohlo s rozjezdem, kdyby se Huw rozhodl, že tvůj kód je lepší než jeho!
Massimo ale odpověděl, že přístup Huwa je příliš odlišný od jeho na to, aby taková věc byla možná. Dále k tomu napsal:
[...] Navíc, z toho (mála samozřejmě), co jsem pochopil z titulků patchů, některé nízkoúrovňové primitivy byly vyexportovány z winex11 – ovladačů gdi32, což je věc, o které mi bylo řečeno, že je „nemožná“, když jsem vyvíjel svůj DIB engine, a umožňuje snadno vyřešit ten největší zbývající problém, totiž efektivní DIB-DDB konverzi.
Takže si počkám na to, co se bude dít s Huwovým enginem. Je to škoda, protože poslední pokrok ve Wine vyřešil mnoho jiných problémů nesouvisejících s DIB. Uživatelé AutoCADu mohou prozatím doufat, že primitivy fontů budou brzo začleněny 
Asociace souborů .bat a .com
link
Nowres Rafid navrhl, že by soubory .bat a .com měly být v GNOME, KDE a dalších asociovány s wine cmd. Na tento návrh zareagoval Damjan Jovanovic:
COM soubory jsou AFAIK samostatný prehistorický DOSový kód reálného režimu bez možnosti načítat DLL. Neměly být spíše načítány DOSBoxem, kam na architektuře AMD64 stejně posíláme DOSové aplikace?
BAT soubory by se měly asociovat s Wine, ale při dvojkliku na Windows se spustí v terminálovém okně (když jsem to posledně zkoušel). Takže bychom museli vytvořit nový wine-cmd.desktop, který se asociuje s BAT soubory. Mrknu na to.
Když už jsem u toho, EXE soubory také čistě nepatří Wine – mohou to být DOS programy reálného režimu nebo .NET kód určený na *nixech Monu. Někdy budou muset Wine/Mono/DOSBox a související projekty začít mluvit o nějakém rozhodovacím mechanismu.
Vincent Povirk poskytl další informace:
Nejsem si jistý, že DOSBox jen tak otevře nějaký náhodný soubor. Museli bychom vytvořit konfigurační soubor, který nastaví mapování jednotek, spustí soubor a ukončí se. Pokud Wine dokáže takové věci dělat (a možná také ošetřit situace, kdy binárka COM očekává, že je spouštěna na stroji s Windows, například DOSovém stroji s nainstalovanými Win3.1), přijde mi to jako dobrá volba.
Je tu nenulová šance, že wine start /unix pro soubory BAT doopravdy spustí cmd a vytvoří terminál. Dělá to pro konzolové aplikace. Pokud tak nečiní, je tu možnost, že to start.exe udělá na Windows, v tomto případě je to chyba ve Wine, kterou bychom měli opravit. Měl bys to ozkoušet, než začneš dělat něco nového.
Na #mono (nebo #monodev) se o tom mluvilo ve smyslu, že rozhodovací mechanismus se nazývá MIME typy a DOS exe, x86/x64 PE exe a CLR exe jsou všechny odlišné a měly by mít odlišné MIME typy.
Damjan to ozkoušel a zjistil, že zatímco na Windows dvojklik zaručuje automatické zavření okna a „start“ znamená, že zůstane otevřené, na Wine „start“ způsobuje automatické zavření. Dále se někdo další zeptal, zda je možné typy EXE binárek nějak snadno rozlišit u shared-mime-info, na což Damjan odpověděl:
Parsování hlaviček EXE vyžaduje následování ukazatelů (například musíš jít na offset určený v dwordu e_lfanew v IMAGE_DOS_HEADER na offsetu 0x40 v souboru, aby ses dostal na rozšířenou hlavičku, která v případě binárky Win16 začíná na „NE“). Zatímco „file“ toto dokáže a „man 5 magic“ obsahuje dokonce příklady, jak to je udělané u EXE souborů, jednoduché parsování prováděné u shared-mime-info zjevně ukazatele následovat nedovede.
Diskuze na toto téma pak brzy utichla. Ozval se ale André Hentschel, který dal vědět, že na podpoře DOSBoxu pracuje (winevdm/winevdm.c:start_dosbox).
Repozitář s aktuální Git verzí pro Ubuntu
link
Scott Ritchie informuje, že pro snazší testování je nyní možné si na Ubuntu snadno nainstalovat poslední verzi Wine z Gitu. Oproti běžné instalaci se namísto ppa:ubuntu-wine/ppa přidává repozitář ppa:ubuntu-wine/daily. Instalace pak může vypadat následovně:
sudo add-apt-repository ppa:ubuntu-wine/daily
sudo apt-get update
sudo apt-get install wine1.3
Pořádná podpora iTunes (a USB obecně)
link
Na mailing listu Wine se rozhořela debata o podpoře iTunes ve Wine, která vlastně nikdy nebyla úplná. Především možnost kopírování dat do iPodů, iPhonů a podobných je pak důvodem, proč by si někdo tento software na Linuxu instaloval – a právě to nefunguje.
Keith Curtis vyvolal dohady tím, že prohlásil, že by práci na podpoře iTunes měli vývojáři dát prioritu. Samozřejmě, kdykoliv někdo začne dobrovolníkům říkat, co by měli ve svém volném čase dělat, nedopadne to dobře. I tak se později vyjasňování a srovnávání dostalo k produktivní diskuzi.
Zatímco starým iPodům stačilo standardní USB Mass Storage, nová zařízení od Apple vyžadují přímou komunikaci přes USB. Na tom se pracuje, ale je to běh na dlouhou trať. A právě autor této podpory, Damjan Jovanovic, popsal v dlouhém e-mailu, jak se věci mají:
Jako člověk, co pracoval v Microsoftu, vám říkám, že byste všichni měli docenit velikost a komplexnost architektury ovladačů na Windows. Proto bych řekl, že toto „selhání“ je především kvůli rozsáhlosti problému, který se tu řeší.
Moje první pokusy o přidání podpory USB do Wine byly bolestivé a pomalé. V roce 2006 mé první patche zaslané do Wine řešily problémy v SETUPAPI.DLL. Kolem roku 2007 mé hacky ve Wine a linuxovém jádře pro emulaci USBSCAN.SYS umožnily mému user-space USB vypisovači pro Windows, aby fungoval pod Ubuntu 6.06. Některé z těchto hacků byly nakonec pročištěny a dostaly se v roce 2009 do Wine STI.DLL, ale můj patch jádra nikdy nefungoval na jiné verzi jádra a pochybuji, že by ve Wine nebo linuxovém jádře přijali ten pochybný kód, co jsem používal. Začal jsem zkoumat možnost implementování USBSCAN jako ovladače v uživatelském prostoru s něčím jako FUSE, ale pak Wine získalo základní NTOSKRNL.EXE a schopnost načítat SYS soubory pro Windows. Od té doby bylo cílem implementovat vše ve Wine a pro USB I/O použít libusb.
V roce 2010 jsem do Wine přidal některé funkce z USBD.SYS a hlavičkové soubory pro USB. Později jsem se pokusil přidat podporu libusb, monitorování USB zařízení a základní infrastrukturu načítání ovladačů podle potřeby, ale nic z toho nebylo z různých důvodů do Wine přijato. Nyní se postupně snažím zobecnit načítání ovladačů ve Wine. Pak snad přidám načítání ovladačů při připojení USB zařízení. Pak podporu libusb. Pak teprve přidám samotné základní USB I/O. Pak musím rozchodit ReadFile/WriteFile u ovladačů. A stejně pak zbude nutnost napsat vysokoúrovňové ovladače (např. USBSCAN.SYS) a spousta chyb v SETUPAPI.DLL a funkce jako podpora instalátorů tříd [class installers], které bude nutné přidat, než se ovladače vůbec úspěšně nainstalují. A pak budeme doufat, že nezačnou používat příliš mnoho neimplementovaných funkcí z NTOSKRNL.EXE.
Takže to postupuje pomalu a musí se toho udělat hodně a moc vývojářů Wine se o to nezajímá. Můžeme jen doufat, že jakmile nějaké ovladače začnou fungovat, vyvolá to větší zájem o Wine (a Linux) a do Wine pak půjde více patchů .
Damjan se po dalších několika e-mailech, které mailing listem proběhly, rozloučil se slovy, že se ozve, jakmile bude mít gitový strom, ve kterém bude něco zajímavého.
Další články z této rubriky
Diskuse k tomuto článku
12.10.2011 00:23
D.A.Tiger | skóre: 8
| Brno
Re: Zpravodaj o Víně – 1. 10. 2011
12.10.2011 09:20
Bedňa | skóre: 34
| blog:
Žumpa
| Horňany
Re: Zpravodaj o Víně – 1. 10. 2011
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
12.10.2011 00:23
12.10.2011 09:09
13.10.2011 12:42
15.10.2011 22:39
Taková mohutná zpětná kompatibilita se opravdu jen tak nevidí. Ale BAT soubory už neotvírá, tím jsem si celkem jistý.
12.10.2011 09:20
