Wine - krewniak jądra #132 For 24 Aug 2002

Oto 132. 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 64 different contributors. 36 posted more than once. 26 posted last week too.

Informacja prasowa TransGaming zawiera ogłoszenie trzech nowych gier: ,,KOHAN: Immortal Sovereigns'', ,,KOHAN: Ahriman's Gift'' i ,,KOHAN: Immortal Sovereigns - Special Awards Edition.'' Gdzie? W nowym sklepie TransGaming. Potrzebujecie nowego uzależnienia? Dwadzieścia dolarów i gra jest wasza. Kohan można pobrać ze stron sklepu.

CodeWeavers wypuścili betę serwerowej wersji CrossOver Office 1.2. Z ich strony:

CrossOver Office Wydanie Serwerowe umożliwia uruchamianie ulubionych aplikacji windowsowych w otoczeniu sieciowym na Linuksie, bez konieczności posiadania licencji na system operacyjny Microsoftu na każdej maszynie. CrossOver Office Wydanie Serwerowe umożliwia spełnienie oczekiwań dosłownie setek użytkowników równocześnie, za pomocą jednego serwera.

Wydanie Serwerowe jest także wspaniałym dodatkiem do systemu Solaris, ponieważ wbudowana przez nas obsługa Soralisa również umożliwia uruchamianie programów windowsowych na stacjach roboczych Suna. To sprawia, że CrossOver Office Wydanie Serwerowe jest doskonałym wyborem dla inżynierów, CAD/CAM, zastosowań naukowych i innych wysokowydajnościowych grup roboczych.

Wyobrażam sobie, że pierwsze pytanie, jakie ludzie sobie stawiają, dotyczy licencji. Oczywiście, powyższe stwierdzenie o ,,niekonieczności posiadania licencji na system operacyjny Microfostu na każdą maszyne kliencką'' nie różni się od standardowego produktu CrossOver Office. Ale co z użytkowaniem aplikacji? Nie ma wątpliwości, że CodeWeavers myśleli nad tym intensywnie. Na swojej stronie umieścili informację o licencjach.

Byli również CodeWeavers, prezentując Office na Linuksie, i tworzą dwa nowe produkty, z których jednym jest mozliwość prawidłowego uruchomienia Photoshopa na Linuksie! Mieli już po prawdzie gotoą betę, ale w ostatniej chwili znaleźli kilka błędów, które opóźniły wydanie.

Fabian Cenedese chciał poznać dobrą metodę na czytanie dokumentacji Wine: " Jaki jest nałatwiejszy sposób przeglądania lub drukowania plików sgml z pomocą Wine? Bawiłem się sgmltools, ale nie uzyskałem przydatnego wyniku."

Vincent Beron odpowiedział jako pierwszy: " Uruchom ,,make'' w katalogu z dokumentacją. To stworzy kopię w HTML i PS. Poza tym, wydaje mi się, że na http://www.winehq.org zjaduje się aktualna kopia. "

Andriy Palamarchuk wyjaśnił: " Obawiam się, że po prostu wykonanie ,,make'' to nie wszystko. Musisz zrobić tak: ,,make html''. "

Lawson Whitney nadesłał mały jednolinijkowy skyrpt, którego można użyć jako przeglądarki:

Używam tego:



#!/bin/sh

#<wine>/documentation/*.sgml reader (c) 2000- Lawson Whitney

# Use, distribute, or change at your own risk.

sed -e 's/<[^<>]*>//g' -e 's/&lt;/</g' -e 's/&gt;/>/g' $1 |less -ni

NAJŁATWIEJ będzie pobrać wersję PDF z: http://www.winehq.com/Docs/

To da Ci nalepsze wyniki. Drukowanie HTML-i nie będzie wyglądało nawet w połowie tak ładnie.

Mógłbyś sam stworzyć PDF-a, ale musiałbyś mieć zainstalowane wszystkie właściwe narzędzia SGML-PDF. W katalogu z dokumentacją jest skrypt ,,make_winehq''. Zajrzyj do niego albo uruchom, żeby zbudować dokumentację w wersjach HTML, PDF i PS.

Shachar Shemesh nadesłał infrastrukturę dla nadchodząceej obsługi bidi za pośrednictwem biblioteki fribidi. Alexandre zasugerował:

Sugeruję, abyś najpierw napisał prawdziwy kod, a potem pozwolił nam martwić się konfiguracją. Nie ma sensu dodawać zależności konfiguracyjnych dla nieistniejącego kodu, kiedy bowiem kod już będzie gotowy, łatwiej zorientujemy się, jakich zależności wymaga.

Jak już wspomniałem, myślę, że włączenie algorytmów fribidi bezpośrednio w kod jest lepszym rozwiązaniem, ale jedyny sposób aby poznać właściwe rozwiązanie, to mieć działający kod.

Shachar zauważył: " Mam niejasne przeczucie, że nie zdajesz sobie sprawy jak wielkim skrótem jest użycie fribidi. Wszystko to, co już mamy i oznaczamy jako ,,bardzo niekompletne'' zostanie zastąpione mniej więcej czterema do pięciu liniami kodu. "

Alexandre odparł: " Znając Microsoft, mam niejasne przeczucie, że nie będzie to takie łatwe. Cieszybłym się, gdyby okazało się inaczej, ale jest tylko jeden sposó aby to zrobić i jest nim pokazanie kodu. Nie fragmentów dotyczących konfiguracji, właściwego kodu. "

Shachar miał jednak kilka pomysłów dotyczących implementacji: " W tej chwili uważam posiadanie koniecznej obsługi BiDi w Wine za nieefektywne, oznacza to bowiem (oprócz zwykłego włączenia alogrytmu BiDi) tłumaczenie każdego drukowanego łańcucha do UTF-32 i spowrotem (chyba że możemy z całą pewnością stwierdzić, że BiDi nie będzie konieczne - nie znalazłem jeszcze żadnego dobrego algorytmu do tego, ale pracuję nad nim). Brak odpowiedniej biblioteki na komputerze jest dobrym sposobem na stwierdzenie, że BiDi Cię nie interesuje (i to jest, mniej więcej ten sam sposób, w jaki problem rozwiązał Microsoft)."

Alexandre zastanawiał się nad używaniem FriBiDi jako zewnętrznej biblioteki:

No cóż, oczywistym powodem włączenia tego kodu do Wine jest mozliwość pracy z UTF-16 i pominięcie konwersji. A jeśli naprawdę zajdzie potrzeba wyłączenia BiDi z powodu wydajności, opcja konfiguracyjna jest o wiele lepsza niż zgadywanka na podstawie obecności zewnętrznej biblioteki.

Jedyne interesujące pytanie to takie, czy używanie zewnętrznej biblioteki umożliwi nam zrobienie wszystkiego, czego potrzebujemy z rozsądną wydajnością i czy sprawi, że coś się uprości. Jedyny psosób na poznanie odpowiedzi, to spróbować jednego lub drugiego sposobu i zobaczyć wyniki.

Jeśli wydaje Ci się, że używanie zewnętrznej biblioteki to dobry sposób, świetnie, napisz to właśnie tak i nadeślij łatę. Wtedy możemy naprawdę zacząć poruszać temat. I nie martw się o opcje konfiguracyjne i pakietowanie; zajmiemy się tym później.

To jeszcze nie jest właściwa łata, ponieważ mam wciąż kilka błędów. Podłączyłem jednakże wstępne ,,Wine z zewnętrznym libfribidi''. Czyńcie waszą powinność i wracajcie z uwagami. Jeszcze nie oczyściłem tej łaty, ale interfejs jest dobrym przykładem tego, co czeka nas w ostatecznej wersji.

Jako PS dodam, że libfribidi może nie być tak dojrzała, jak miałem nadzieję, że jest, i jeśli kłopoty będą ciągle się pojawiały, osobiście włączę to do kodu (a dokładniej, spróbuję). To nie będzie łatwe, ponieważ aktualnie biblioteka ma własne tablice unicode, slrypty konfiguracyjne itd. Skoro zgłosiłeś się na ochotnika, żeby z tym pomóc... ;-).

Później dodał: " Czy fribidi obsłuży wszystko, czego potrzebujemy? Tak, wierzę, że tak. Właśnie dlatego starałem się tak podkreślić ilość uproszczeń, które daje nam tak biblioteka. Implementowanie różnych algorytmów unicode to ogromny wysiłek, którego da się uniknąć. Jeśli w którymś momencie w przyszłości okaże się, że pewne programy naprawdę wymagają klas z GetCharacterPlacement, cóż, powtórzymy tę dyskusję. "

Alexandre się nie zgodził: " To nie do zaakceptowania. Będzie zupełnie w porządku, jeśli nie będziemy czegoś implementować aż do momentu, gdy znajdzie się aplikacja, które tego wymaga, ale nie będzie w porządku, jeśli przyjmiemy założenie, które uniemozliwi nam późniejszą implementację funkcjonalności gdy będzie potrzebna (a *będzie* potrzebna w przyszłości). "

Shachar uważał, że to wystarczająco dobre i nie będzie nigdy potrzeby dalej tego rozwijać. Alexandre jednak był ostrożny: " Chcę powiedzieć, że złym pomysłem jest zacząć używać fribidi, tworzyć zależności i kłopoty twórcom pakietów itd., skoro wiemy, że to zły projekt i trzeba będzie go wymienić. Prawda jest taka, że dibi nie jest jakąś priorytetową opcją (jak pokazuje liczba osó zainteresowanych jej uruchomieniem), nie ma zatem większego znaczenia, czy będzie działać jutro, czy za trzy miesiące. To co ma znaczenie, to wybór właściwego rozwiązania, aby, kiedy więcej osób będzie zainteresowanych, można było na nim budować, a nie wyrzucić i pisać od zera. "

Alexandre umieścił kod w CVS-ie i zauważył: "Przeniosłem dużą ilość funkcji 16-bitowych do oddzielnego pliku gdi16.c. " Dimi Paun stwierdził, że to dobry początek:

To świetny pomysł, który postulowałem już od dłuższego czasu <g>.

Myślę, że przeniesienie 16-bitowego kodu do osobnego pliku jest fajne:

wydajność podczas pracy: jesli kod 16-bitowy nie zostanie wywołany, nie będzie stronicowany podczas pracy,
czystość kodu: programiści pracujący nad kodem 32-bitowym (będący _kodem_ wine) nie będą rozpraszać się śmiesznymi konwersjami 16-na-32 bity.
wspomaga poprawność: 16-bitowy kod to z reguły proste:
- konwersja 16-na-32 bity
- wywołanie substytucyjnej fukcji 32-bitowej
- konwersja 32-na-16 bity
Oznacza to, że mamy dużo powtórzeń i szkieletowego kodowania. Jakiekolwiek odstępstwo od zwyczajowego wzoru dużo łatwiej znaleźć gołym okiem w pliku, który robi tylko to.
16-na-32 bity: dużo łatwiej będzie znaleźć (i naprawić) przypadki, gdzie 32-bitowy kod wywołuje 16-bitowy kod.

Myślę, że z tych powodów powinniśmy przenosić _cały_ 16-bitowy kod do osobnych plików. Zawsze. Kto wie, może możemy zrobić makefile w ten sposób, abyśmy mogli w ogóle uniknąć kompilowania 16-bitowego kodu! :) Nawet jesli ma to odbyc się prostym sprawdzeniem, czy kod 32-bitowy wywołuje kod 16-bitowy...

I znowu, _te same_ argumenty dotyczą finkcji xxxW & xxxA, ale nie będę teraz drążył tematu. :)

Właśnie dowiedziałem się, że TransGaming mają w swoim CVS-ie nowe ,,quartz.dll''. Wygląda na to, że używa ffmpeg libavacodec.

Dobra wiadomość: libavcodec to LGPL!!!

Jest zatem spora szansa na to, że cały quartz dll będzie LGPL.

Będzie? Juz od jakiegoś czasu jest... Z pliku LICENCJA obowiązującego od WineX 2.1 (CVS ,,winex-2-1'' w ,,winex-2-0-branch'', gdzie nowy dll quartz nabiera kształtu):

Dodatkowo, następujące komponenty podlegają licencji GNU LGPL, umieszczonej w pliku LICENCE.LGPL:

Ktoś wskazał na zestaw narzędzi używający Wine do kompilacji aplikacje EPOC:

GnuPoc umożliwia tworzenie aplikacji EPOC na komputerze z GNU/Linux.

Używa GNU make, Wine i GCC jako kroskompilatora na ARM.

http://gnupoc.sourceforge.net/

Zapytacie, czym jest EPOC? To ,,32 bitowy system operacyjny stworzony przez Psion, a teraz Symbian Ltd (zwany także Symbian OS)''. Typowe zastosowania to telefony komórkowe i PDA. Przy użyciu Wine można uruchomić zestawy do tworzenia oprogramowania wyprodukowane przez różne firmy.


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

1.	8 Aug 2002 - 24 Aug 2002	(2 posts)	Nowiny: CrossOver Office - Wydanie Serwerowe
2.	14 Aug 2002	(5 posts)	Konwersja SGML Wine Docs
3.	16 Aug 2002 - 20 Aug 2002	(12 posts)	Obsługa BiDi
4.	15 Aug 2002 - 16 Aug 2002	(2 posts)	Oddzielenie funkcji 16-bitowych
5.	9 Aug 2002 - 17 Aug 2002	(13 posts)	Zamiennik dla Quartz.DLL
6.	22 Aug 2002	(1 post)	Wine i GnuPOC

Wine - krewniak jądra #132 For 24 Aug 2002

By Brian Vincent

Translated By: Damian Wojsław