Wine - krewniak jądra #126 For 13 Jun 2002

Wraz z wersją 1.1, CodeWeavers oficjalnie wspiera zarówno Microsoft Outlook jak i Internet Explorer, jako dodatek do już obsługiwanych Microsoft Word, Excela i PowerPointa oraz IBM Lotus Notes. Umozliwia to firmom przeniesienie się na Linuksa bez zmiany systemów wewnętrznych. ,,Wraz z dodaniem obsługi Outlooka i Internet Explorera odnosimy wrażenie, że obsługujemy najważniejsze cechy Microsoft Office Suite i umożliwiliśmy firmom bezbolesne wdrożenie dekstopów pracujących pod kontrolą Linuksa.'' powiedział Jeremy White, założyciel i CEO CodeWeavers.

Cześć wszystkim,

W ciągu kilku ostatnich miesięcy byliśmy świadkami znaczącej zmiany licencji Wine i TransGaming, jak wiele innych organizacji, musiało przez jakiś czas zastanowić się nad skutkami, jakie przynosi ta zmiana nam, naszym sybskrybentom i naszym partnerom. Poświęciliśmy też trochę czasu, aby uważnie wysłuchać komentarzy na Wine-Licence a także przysyłanych do nas prywatnie. Ponosimy odpowiedzialność za podejmowanie pragmatycznych decyzji, które zapewnią naszej firmie ciągły rozwój oraz uchronią interesy naszych klientów.

Aby ukrócić trwającą dyskusję nad zmianą licencji, postanowiliśmy skoncentrować nasze wysiłki na drzewie ReWind. Mamy nadzieję, że deweloperzy, którzy zdają sobie sprawę ze znaczenia naszego dotychczasowego i planowanego wkładu w rozwój Wine, wesprą nas udostępniając swoje łaty ReWind na licencji X11.

W ciągu nadchodzących dni będziemy włączać kolejne dodatki do ReWind, również te, które pierwotnie udostępnialiśmy na wymianę, jak i kilka, których wcześniej nie oferowaliśmy. Kilka bardziej ekscytujących kawałków to rozwijany przez nas silnik DIB, a także nowa architektura DCOM. Nowy DCOM eleminuje kłopoty powodowane przez poprzednie przetaczanie biblioteczne (typelib-only marshalling - tak, wiem, nic innego mi do głowy nie przyszło:/ D.W.) zarówno w WineX, jak i w Wine. DCOM obsługuje przetaczanie międzywątkowe (inter-thread marshalling), a będzie obsługiwać przetaczanie zdefiniowane w aplikacjach (niebiblioteczne), jako dodatek do poprzednich przetaczań (bibliotecznych) OLE Automation. Włączyliśmy również wstępny kompilator IDL, który pozwala aktualnie na automatyczne tworzenie z IDL-i definicji makr COM dla Wine. Kompilator IDL nie potrafi jeszcze tworzyć kodu z przetaczaniem.

Nowy system DCOM wciąż jest w stadium rozwojowym i nadal trochę nam brakuje do pełnej obsługi InstallShield 6. Mamy nadzieję, że ktokolwiek jest zainteresowany DCOMem i obsługą OLE, zechce z nami współpracować nad rozwojem. Jest kilka rzeczy do zrobienia (włączając interpreter kodu z przetaczaniem), o których Ove którko opowie.

Dopóki drzewa ReWind (i Winex) nie będą miały lepszego wsparcia oddzielania DLLi, TransGaming nie będzie mogło brać bezpośredniego udziału w żadnych pracach związanych z licencją LGPL, w związku z prawnymi i ekonomicznymi powodami, dyskutowanymi tu już wcześniej. Inni deweloperzy mogą, oczywiście, włączać, to co dodamy do ReWind, do drzewa Wine na LGPL-u.

Zajmiemy się oddzielaniem DLLi w ReWind, abyśmy w przyszłości mogli pracować nad drzewem LGPL na poziomie pojedynczych elementów. Każda pomoc innych deweloperów byłaby mile widziana, włączając zmianę licencji łat, które obecnie są tylko na LPGL-u. Bez jakiejkolwiek pomocy może minąc sporo czasu, zanim będziemy mogli podzielić się swoją pracą bezpośrednio z Wine.

Kontynuujemy nasze prace nad rozwojem ReWind i Wine do momentu, na który pozwala nasza sytuacja prawna i ekonomiczna i robimy wszystko, co tylko jest w naszej mocy, aby zaoferować graczom korzystającym z Linuksa najlepszy sposób na uruchamianie swoich ulubionych gier na swojej ukochanej platformie. Doceniamy wkład nie tylko subskrybentów i współpracowników, ale również wszystkich osób i instytucji, które pomogły w ciągu tych lat rozwijać Wine. Dzięki naszym połączonym wysiłkom, mogliśmy do tej pory udostępnić uzytkownikom komputerów z Linuksem setki gier dla Windows, a TransGaming mogło dodać dziesiątki tysięcy linii kodu do Wine. Oczekujemy dalszej udanej współpracy.

Dzięki,

-Gav

Piszę tylko, żeby ,,zdać raport'' ze stoiska Wine na LinuxTag w Karlsruhe, w Niemczech. Deweloperami obsługującymi stoisko byli Andreas Mohr i Uwe Bonnes. Zainteresowanie było duże, równie duże są nadzieje wiązane z projektem Wine, prośby o obsługę aplikacji skupiały się głównie na MS Office (zazwyczaj Word i Access, również aplikacje Visio i MS Project), Lotus Notes (ale to już całkiem nieźle działa, choć nie przeprowadziliśmy demonstracji), edytory WYSIWYG stron www (Dreamweaver, Homesite) i aplikacje DTP (bardzo popularna była obsługa PageMakera, który był protoplastą Adobe InDesignera). Proszono również o Illustratora i Photoshopa. Inną wartą uwagi aplikacją jest Act 2000, będący czymś w rodzaju oprogramowania do zarządzania informacjami osobistymi (i nie działało :)). Często proszono też o programy CAD, aczkolwiek padało wiele różnych nazw.

Próbowaliśmy analizować większośc problemów - mam nadzieję, że uda mi się dołączyć do późniejszego raportu listę błędów. Udało nam się rozwiązać *dwa* problemy - oprogramowanie do modelowania 3d Rhinoceros (Andi wyśle łatę później) i różne poprawki dla BuildCommDCB (dla jakiegoś specjalnego oprogramowania do projektowania sprzętu).

Osobista lista życzeń: chciałbym mieć jakiś dokument na temat trudniejszych obszarów Wine, np. komunikacji między procesami i zarządzanie oknami (głownie, jak to odrobaczać).

Odkryliśmy, że odpluskwiacz Wine nie działa jeszcze tak sprawnie :-) (jak dla mnie, działał tylko po wyłączeniu korzystania z xterma/wconsoli).

Na chwilę zajrzał do nas Marcus Meissner i odkrył, że większość programów (Homesite, Dreamweaver, Adobe InDesign 2.0) używają szyfrowania, aby chronić dane aplikacji, nie udało nam się uruchomić deszyfrowania. Wiele programów zaczęłoby działać, gdybyśmy obsługiwali ,,szyfrowane'' pliki binarne. Postaram się podać więcej szczegółów później, jednak możecie pobrać wersje demonstracyjne i zobaczyć na własne oczy.

Innym powodem do konsternacji była obsługa instalatorów, chociaż większość instalatorów opartych na InstallShield działało z natywnym stdole32.tlb (może dobrym pomysłem byłaby wiadomośc do użytkownika, że potrzebuje tego pliku, skoro nie możemy sami generować plików bibliotecznych (typelib files), albo może da się użyć czegoś z rewind?).

Na temat gier: pokazaliśmy Half-life, Diablo 2, Starcraft i Grim Fandango, ale użyliśmy do tego WineX. Reakcje na nie-wolne dodatki z TransGaming (i czasem CodeWeavers) były różne. Trochę smutne było, że większość programów nie będących grami miało błędy (błąd Office w WordArt, kłopoty dibengine w MS IE, niedziałający backend kompilatora w Visual Studio (mogło byc spowodowane problemami z konkretnym komputerem) i, no cóż... pokazanych przez nas aplikacji nie było wiele więcej, ponieważ większość po prostu nie dała się uruchomić :))

Odnośniki do wersji demonstracyjnych programów: (wspomnianych wyżej przeze mnie)

• InDesign 1.5: ?
• InDesign 2.0 (równie interesujący byłby PageMaker, można go pobrać z tej samej strony)
• Illustrator 10
• Act 2000
• CoolEdit 2000
• Homesite (uwaga: rejestracja nie powinna być obowiązkowa, kliknijcie w ,,kontunuuj bez zalogowania'')
• Dreamweaver
• Rhinoceros 3D (działa już z łatą Andiego!)

(a teraz te wspomniane rzadko lub tylko raz i nie były wymienione przeze mnie)

• Gandke & Schubert EAR and GS-Verein
• Lemmings Revolution
• Mindmap (z rejestracją)
• Q-Stat (nie ma mozliwości darmowego pobrania. Kontakt przez e-mail i prośba o demo na zwykły adres powinna wystarczyć)
• Xara X

Zdjęcia: zrobiliśmy kilka. Mam nadzieję, że Andi poda później URL na wine-devel.

(Mam nadzieję, że uda mi się nadesłać trochę logów z odrobaczania i dodać kilka pozycji do systemu śledzenia bedów. Niczego jednak nie objecuję, ale przecież możecie sami wypróbowac większość aplikacji.)

1. dodaj fake_windows w $HOME/.wine
   
   http://chem.skku.ac.kr/~wkpark/kle/wine/dotwine/make_dotwine
2. zainstaluj trochę czcionek ttf($ wine NEWFNT32.exe;wine corfnt32.exe)
   
   wget ftp://ftp.microsoft.com/developr/drg/TrueType/NEWFNT32.EXE
wget ftp://ftp.microsoft.com/developr/drg/TrueType/corfnt32.exe
3. zainstaluj dcom98.exe($ wine dcom98.exe)
   
   wget http://download.microsoft.com/msdownload/dcom/98/x86/en/dcom98.exe
4. instaluj ie5setup.exe ($ wine ie5setup.exe)
   wget http://download.microsoft.com/download/ie501sp2/Install/5.01_SP2/WIN98/EN-US/ie5setup.exe
5. usuń .wine/fake_windows/Windows/WinInit.ini (?) zajrzyj do Wininit.ini i znajdziesz tam trochę instrukcji...
6. uruchom explorer.exe z następującą konfiguracją: (explorer.exe!! nie iexplore.exe, możesz skopiować go z maszyn z Windows) tak mi się wydaje... kiedy uruchomiono explorer.exe... tworzone są wpisy do rejestru, wymagane przez iexplore.exe.
   [AppDefaults\\explorer.exe\\x11drv]
"Managed"="N"
"Desktop"="800x600"


[AppDefaults\\explorer.exe\\DllOverrides]
;;
"gdi32" = "builtin"
"kernel32" = "builtin"
;;"shell" = "native"
;;"shell32" = "native"
;;"commctl" = "native"
;;"comctl32" = "native"
"shell" = "builtin"
"shell32" = "builtin"
"commctl" = "builtin"
"comctl32" = "builtin"
;
"imm" = "builtin"
;"ntdll" = "native"
"shdocvw" = "native"
"shlwapi" = "native"
"wininet" = "native"
"*" = "native, builtin"
7. uruchom iexplore.exe !!
   
   
   [AppDefaults\\iexplore.exe\\DllOverrides]
;;
"gdi32" = "builtin"
"kernel32" = "builtin"
;;"shell" = "native"
;;"shell32" = "native"
;;"commctl" = "native"
;;"comctl32" = "native"
"shell" = "builtin"
"shell32" = "builtin"
"commctl" = "builtin"
"comctl32" = "builtin"
"imm" = "builtin"
;"ntdll" = "native"
"shdocvw" = "native"
"shlwapi" = "native"
"wininet" = "native"
"*" = "native, builtin"

a oto mój zrzut ekranu.

• ( z "Windows"="win95" )
• ( z "Windows"="win98" )

• uniemożliwi nam czytanie informacji z plików ,,.lnk''... przynajmniej z ,,obsługiwanych'' plików ,,.lnk''
• nie jest całkiem jasne, co chcą robić z nieobsługiwanymi plikami ,,.lnk''. Czy są po prostu ślepymi dowiązaniami symbolicznymi, czy też każdy może przeczytać ich zawartość? W pierwszym przypadku Wine znowu jest SOL, w drugim musimy grać w gierki, żeby dowiedzieć się, z którym rodzajem mamy do czynienia.
• sugerowano zaimplementowanie w wine obejścia, które pozwoli na odczytywanie plików ,,.lnk''. Tylko dlaczego mielibyśmy dodawać obejście specyficzne dla Linuksa, skoro nie robiąc tego mamy już działające rozwiązanie, do tego na każdym systemie Uniksowym?
• jeśli zdecydujemy się zrobić z tego domyślną opcję, nic a nic nie pomożemy Wine. Musimy wtedy powtarzać użytkownikom, żeby zmodyfikowali swoje pliki fstab, jeśli chcą, żeby Wine zadziałało.

W załączniku jest bardzo wstępna łata BiDi. Poniżej lista rzeczy, które zawiera oraz punkty, na temat ktorych chciałbym usłyszeć Wasze komentarze. Na tym etapie łata jest tylko objęta licencją LGPL.

Changes:

• Poprawiony plik heb.nls, tak aby system akceptował ustawienie LANG=he_IL.
• Zaimplementowany szkielet dla GetFontLanguageInfo.
• Wypełniłem szkielet tam, gdzie wiedziałem, czym go wypełnić. Zgaduję, że brakuje jeszcze wielu rzeczy.
• Byłbym bardzo wdzięczny za uwagi nad poprawnością u życia GetTextCharsetInfo jako źródła informacji.
• Usunąłem FIXME, ale jeszcze sporo rzeczy nie zostało zaimplementowanych. nie miałem pojęcia, co umieścić tam w zamian.
• GetCharacterPlacementW - to z pewnością jedna z bardziej przeładowanych funkcji w otoczeniu Win32 (jako druga przychodzi mi na myśl Select object, ale przez tę przechodzi znaczenie więcej wykonań (execution flows)). Na razie, na ile się orientuję, tylko przepływ z czcionkami Latin był zaimplementowany. Dodałem (bardzo podstawowe) przeporządkowanie. Bardzo zależy mi na Waszych komentarzach na temat poniższych:
• Pracowałem zgodnie z instrukcjami autodokumentowania. Czy w ogóle jest to nadal obsługiwane lub potrzebne?
• Użyty przeze mnie algorytm jest daleki od ideału. Wciąż nie obsługuje akapitów zapisywanych od prawej do lewej i całej grupy niezbędnych rzeczy. Wszystko, co to na razie robi, to upewnia się, że seryjne wykonania jednej dyrektywy są, mniej lub bardziej, czytelne.
• Dodałem opcję fastpath, kiedy nie ma nic do wykonania. Na razie, kiedy obsługiwane jest tylko przeporządkowanie, ma to nawet sens. Kiedy jednak dojdzie kerning, ligatura itd., fastpath będzie bezsensowne. Opinie?
• ExtTextOutW
• Wywołuję GetFontLanguageInfo dla każdego ExtTextOutW (punkt skupienia wszystkich funkcji renderujących tekst). Jaki będzie to miało wpływ na wydajność? Nie zapomnijcie, że to za co płacę pytając, czy przeporządkowanie jest konieczne, odzyskuję nie wywołując GetCharacterPlacementW i nie alokując bufora. Jednakże niektóre czcionki Unicode muszą sobie radzić zarówno z alokacją, jak i brakiem przeporządkowania.
• Wywołuję backendową funkcję drukowania tekstu w dwóch przepływach. Jeden używa alokowanego bufora uzywanego do GetCharacterPlacementW, drugi jest oryginalny (nie ma sensu alokowac bufora, skoro nie wykonano żadnej pracy). Powinienem wykonać ciężką robotę i połączyć te dwa wywołania?
• Zakładam, że sterownik nie będzie wykonywał przeporządkowania. Nie mam pewności, na ile poprawne będzie to z, powiedzmy, KDE3 (Hetz?).