Wine - krewniak jądra #127 For 20 Jun 2002

Oto 127. numer Wine, krewniaka jądra, którego głównym zadaniem jest informowanie o pracach i działaniach związanych z Wine - emulatorem Windows dla platform Un*ksowych.

There were 53 different contributors. 30 posted more than once. 28 posted last week too.

1. Nowiny: wIndependence Day (Dzień Niezależności od Windows?), Lindows w Wal-Mart, Kohan z TransGaming

DesktopLinux.com ogłosił 4 lipca Dniem nielzależności od Windows (wIndependence Day): "Dzień Niezależności od Windows jest świętem z okazji rosnącego zastosowania Linuksa w biznesie, organizacjach rządowych, instytucjach edukacyjnych i na komputerach osobistych użytkoników końcowych, jako alternatywa dla Microsoft Windows oraz powiązanych produktów. " Cytowani są Michael Robertson z Lindows.com i Jeremy White z CodeWeavers. Ogłoszono konkurs na eseje, którego zwycięzcy otrzymają wspaniałe nagrody.

A skoro o konkursach mowa, TransGaming przedłuża czas trwania obydwu konkursów: Win a Gaming PC oraz Name the Logo. W pierwszym mogą wziąć udział tylko ci, którzy namówili kogoś na wykupienie członkostwa w TransGaming, drugi jest otwarty dla wszystkich członków TransGaming. W każdym razie, to nie są interesujące wieści.

Na sajdbarze strony TransGaming można było zobaczyć odnośnik do "WKRÓTCE: Trzy tytuły KOHAN dostępne na TransGaming" . Kohan to bardzo popularna gra strategii czasu rzeczywistego.

Największa nowina ze wszystkich pochodzi z Wal-Mart. Można już zakupić przez sieć PC Mikrotela z preinstalowanym Lindows SPX. NewsForge wskazało, że sformułowania na stronie zmieniły się od czasu pierwotnego ogłoszenia prasowego.

Po zapoznaniu się z ogłoszeniem prasowym byłem trochę rozczarowany. Michael Robertson obiecał opublikować kod źródłowy, kiedy produkt ukaże się na rynku. Cóż, nie chciałem tak po prostu wyskoczyć i oskarżać ich o niedotrzymywanie własnych warunków publikacji, troszkę więc poszukałem. Niestety, nie mogę znaleźć oryginalnego wywiadu, z którego mam tę wiadomość, ale Robertson podał odnośnik do kodu źródłoweego LindowsOS. Spędziłem trochę czasu grzebiąc w nich i znalazłem dość dużo odniesień do Xandors - dokładniej do czegoś, co wygląda jak filrty drukowania oraz kod umsdos i autofs. Wewnątrz odwołują się do tego kodu jako, jako do wersji 0.91, co może mieć związek z drugim wydaniem przeglądowym (preview release). W jednym z plików wspomina się o Wine:

3. W szczególności, nie ma tu źródeł modułów do Wine, po0nieważ WSZYSTKIE wprowadzone przez nas zmiany w Wine (nawet te, których dokonaliśmy, gdy Wine było na licencji X11) przesłaliśmy do włączenia do głównego, LGPL-owego drzewa Wine. Niemal wszystkie nasze zmiany został zaakceptowane i znajdują się aktulanie w Wine. Obecnie Lindows.com prowadzi prace rozwojowe na drzewie LGPL Wine, odsyłając wszelkie zmiany.

Następny wątek otarł sie o dokumentację, wymyśliłem więc, że mogę ponownie podać trochę odnośników do dokumentacji Wine. Ta dokumentacja jest bardziej linearna, niż standardowe Wine FAQ. W zależności od tematyki, jakość dokumentacji Wine waha się się od doskonałej, do nieistniejącej. Czasami jest przedawniona i niepoprawna. Jeśli dopiero zaczynasz pracę z Wine i nie oglądałeś różnych przeowników do Wine, możesz uznać te za przydatne. Lepiej nawet, jeśli wydaje Ci się, że możesz nam pomóc, masz wolną ręke w uzupełnianiu wyraźnie białych plam:

Sylvain Petreoll zapytał: " Chcę uruchomic program korzystający z d3d8.dll. Po uzyciu windeump widzę, że eksporowanych jest tylko pięc funkcji. Jaki jest więc sposób na stworzenie zrębu dll-a? "

Zrąb to po prostu niezaimplementowana funkcja Windows. W Wine taka funkcja zostanie wywołana, ale zazwyczaj nie spowoduje niczego poza komunikatem o błędzie. Raz na jakiś czas konieczna funkcja nie robi nic ważnego, zatem zrąb może wystarczyć, aby program zadziałał. W wielu przypadkach jednak wymagana jest przynajmniej częściowa funkcjonalność. Zrębowy DLL wskazuje na cały DLL niezaimplementowanych funkcji. W tym przypadku Sylvain szuka DirectX 8.0. Lionel Ulmer skomentował: " Tak, tylko jeżeli program naprawdę potrzebuje D3D8, po prostu udawanie tych funkcji w zrębie niewiele Ci pomoże... Kłopot w tym, że D3D (i całe DirrctX) jest zaimplementowane z uzyciem COM: tylko kilka funkcji eksportuje się z DLL-i, ale to ukrywa CAŁĄ MASĘ kodu, jako wskaźników funkcji w obiektach COM. Zatem NIE jest rzeczą trywialną stworzenie zrębu (o ile nie chcesz zwracać ,,nie zaimplementowane'' :) )."

Ian Stewart podał odnośnik do dokumentacji: " Wykonałem początek pracy nad zaimplementowaniem zrębu ctl3d.dll (i zamierzam do tego wrócić, naprawdę!). Rozdział ,,Implementowanie nowych DLL-i'' w DEVELOPERS-HINTS wydaje mi się być dobrym punktem wyjścia. Alexandre twierdzi, że przewodnik jest bardzo przedawniony i ,,prawdziwa'' dokumentacja zostanie kiedyś napisana. Dopóki to jednak nie nastąpi, uważam, że lepsze DEVELOPERS-HINTS niż nic..."

Cóż, zwróć, na przykład, uwagę na ,,dinput8''. To najprostszy DLL jaki znam i powinien być dobrym zamiennikiem dla ,,d3d8''.

W zasadzie, musisz:

stworzyć katalog d3d8
stworzyć plik spec z zawartością, którą poda Ci winedump
stworzyć d3d8_main.c (lub cokolwiek) ze zrębami
stworzyć plik Makefile.in
(punkty od 2. do 4. to zwykłe kopiuj/wklej/zamień z tego co jest w dinput8 z użyciem informacji podanych Ci przez MSDN/winedump).
wykonaj make_dlls w katalogu z DLL-ami
dodaj linijkę 'dlls/d3d8/Makefile' do configure.ac i zregeneruj configure

I to powinno być wszystko :-)

Sylvain powiadomił o częściowym sukcesie" " Dziękuję Ci, Lionel, i pozostałym. Pojawia mi się teraz komunikat, że nie wykryto Direct3D, zamiast zawieszenia, a mój zrębowa funkcja raportuje to prawidłowo na kanale usuwania błędów d3d. "

Jason Edmeades napotkał problem: " Odpluskwiany przeze mnie program ma przycisk ,,Przeczytaj To'', którego naciśnięcie powoduje próbę załadowania pliku readme do write'a. Mała sugestia, ale gdy instalujemy domyślne aplikacje, czy można stworzyć dowiązanie symboliczne albo jakąś kukiełkę (dummy application), która ładowałaby notatnik wine? "

Francois Gouget odparł, że nie jest to takie proste: " Problem w tym, że write poradzi sobie z plikami RTF i dokuemntami Worda, tymczasem notatnik jest tylko edytorem plików tekstowych i wyświetli Ci wyłącznie śmieci... (tak, wordpad prawdopodobnie będzie miał kłopoty ze złożonymi dokumentami worda, ale zadziała z prostszymi). " Dmitry Timoshkov podał więcej szczegółów i możliwe rozwiązanie:

Wydaje mi się, Write poradzi sobie tylko z plikami w formacie Word 5.x/6.x (i, oczywiście, RTF-ami). RTF-y nie powinny powodować zbyt wielu kłopotów (po prostu skieruj je do kontrolki richedit). Co do formatu Word 5.x, tutaj jest fragment mojego bardzo starego kodu dla DOS-a, który radził sobie z tymi plikami (*.doc, *.wri) dobrze (ignorował jednak całkowicie formatowanie):

[ odnośnik ]

Jest tam przykładowy, długi na 128 bajtów, nagłówek z sygnaturą i długością tekstu).

Myślę, że nasz notatnik można z łatwością rozszerzyć o zdolność radzenia sobie z tymi formatami. Write mógłby być zwykłym dowiązaniem symbolicznym do notatnika.

Shachar Shemesh zastanawiał się, jak zabrać się za dodanie do Wine biblioteki FriBiDi, w celu obsługi tekstu dwukierunkowego:

Widzę dwa możliwe rozwiązania tego problemu:

Gdyby Fribidi było obecne podczas kompilacji, sprawdzić obecność podczas uruchamiania. Jeśli nie ma, wyłączyć obsługę podczas uruchamiania. Lub
Skopiować (przeportować?) Fribidi do kodu Wine. Jest na LGPL-u, zatem licencja na to zezwala.

Sposobem na poradzenie sobie z [tym ] jest coś jak w przypadku FreeType, np. ładować bibliotekę dynamicznie podczas uruchamiania i wyłączyć obsługę, jeśli się nie uda.

Mam jednak inne pytanie, które już prawdopodobnie przewidzieliście (mogliście już nawet je tutaj przedyskutować, aczkolwiek nie przypominam sobie): FriBiDi jest Uniksową biblioteką unikodu (Unix Unicode library), zakładam więc, że używa czterobajtych znaków Unicode'u? Czy nie będzie to kłopotliwe, skoro Wine używa dwubajtowych znaków Unicode'u?

To może być następny argument za włączeniem FriBiDi w Wine.

Behdad Esfahbod wtrącił uwagę, że FriBiDi obsługuje dwu i czterobajtowe znaki, w zależności od kompilacji. Proste sprawdzenie konfiguracji może wyjaśnić, z którą opcją mamy do czynienia. Behdad zastanawiał się również, czy nie ma przypadkiem potrzeby włączenia własnej wersji FriBiDi do źródeł Wine.

Alexandre stwierdził, że dodanie tego do Wine jest prawdopodobnie dobrym pomysłem: " I tak potrzebujemy szesnastobitowych znaków Unicode, pewnie więc nie możemy używać standardowego FriBiDi. Tym sposobem możemy także współdzielić tablice Unocode z resztą naszego kodu, zamiast je duplikować. Wszystko, czego tak naprawdę potrzebujemy z FriBiDi to algorytmy, a one nie zmieniają się zbyt często, włączenie ich zatem do Wine nie jest takie złe."

Ian Pilcher miał kłopoty z odświeżaniem klienta Lotus Notes (wersja 4.6.7). W trakcie dysksusji Ian wspomniał, że wszystko działało około roku temu, ale jakaś łatka to zepsuła. Tony Lambregts wspomniał: " Oceniam, że znalezienie dnia, w którym dodano psującą łatkę, zajęłoby nie więcej niż 12 itineracji. " Ian chciał jednak uniknąć wielokrotnej instalacji Wine ze względu na trudności w dostosowywaniu konfiguracji. Kilka osób zauważyło, że to nie jest aż takie trudne. Pierwszą sugestę podał Vincent Beron:

Czy nie byłoby możliwe po prostu zainstalować w nowym katalogu w katalogu domowym albo w /tmp? Tak właśnie robię na potrzeby kompilacji testowych i działa mi to całkiem nieźle. Po prostu używam skryptu (tak, kolejnego) do Wine, który ustawia mi potrzebne zmienne środowiskowe (PATH, LD_LIBLARY_PATH itd.).

W zasadzie, podpinam to tutaj, na wypadek, gdybyś potrzebował skorzystać (lub gdyby ktokolwiek tego potrzebował). Oczywiście, musisz też powiedzieć ./configure --prefix=/gdzie/być/to/chciał, a potem to już zwykłe make depend, make, make install.

Za pierwszym razem będziesz musiał zmodyfikować wine.conf i zainstalować podstawowe rejestry. Kiedy już skończysz, rm -rf (albo F8 w mc).

Nawet nie musisz tego instalować. Nigdy nie instalowałem Wine na moim systemie.

Robię coś w tym stylu:



  export WINE_ROOT=/home/fgouget/wine/wine

  export LD_LIBRARY_PATH="$WINE_ROOT:$LD_LIBRARY_PATH"

  export PATH="$WINE_ROOT:$WINE_ROOT/server:$WINE_ROOT/tools:$PATH"

  export WINEDLLPATH="$WINE_ROOT/dlls"

Właściwie, to mam skrypt, który robi to za mnie, a używam go do wybierania pomiędzy drzewami Wine. (,,. wenv wine'' albo ,,. wenv wine2'', etc.).

I also have a ~/.wine directory with a fake_windows configuration that I reuse from one time to the next. I also have it tarred so I can in essence "rm -rf ~/.wine && tar xvfz dotwine.tar.gz".

WINE_ROOT jest zwykłą zmienną, której używam, aby nie wpisywać w kółko pełnej ścieżki dostępu do źródeł Wine. Jeszcze bardziej przydaje się w moim skrypcie wenv.

WINEDLLPATH mówi Wine, gdzie ma szukać wbudowanych dll-i. U mnie /home/fgouget/wine/dlls

WINE_PREFIX mówi, gdzie Wine ma szukać swojego pliku konfiguracyjnego. Standardowo jest to $HOME/.wine


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	14 Jun 2002 - 20 Jun 2002	(3 posts)	Nowiny: wIndependence Day (Dzień Niezależności od Windows?), Lindows w Wal-Mart, Kohan z TransGaming
2.		(1 post)	Odnośniki związane z dokumentacją
3.	18 Jun 2002 - 20 Feb 2002	(12 posts)	Tworzenie zrębów
4.	16 Jun 2002	(3 posts)	Obsługa MS Write
5.	18 Jun 2002 - 19 Jun 2002	(11 posts)	Dodawanie obsługi FriBiDi
6.	19 Jun 2002 - 20 Jun 2002	(10 posts)	Wie konfiguracji Wine

Wine - krewniak jądra #127 For 20 Jun 2002

By Brian Vincent

Translated By: Damian Wojsław