Sweden-Number/documentation/installation-und-konfigurat...

2147 lines
109 KiB
Plaintext
Raw Normal View History

Installations- und Bedienungsanleitung f<>r WINE
Peter Ganten
peter@ganten.org
7. Juli 2000
1. Zusammenfassung
Dieser Text beschreibt die Installation, Einrichtung und Bedienung von
WINE. WINE ist eine Laufzeitumgebung zum Ausf<73>hren von Programmen f<>r
MS-Windows unter GNU/Linux und anderen UNIX-kompatiblen
Betriebssystemen auf Intel-x386-kompatiblen Computern, das Programm kann
au<EFBFBD>erdem dazu genutzt werden, den Quellcode existierender
Windows-Programme nach UNIX zu portieren. In diesem Text geht es in
erster Linie jedoch um die Installation und Konfiguration der
Laufzeitumgebung f<>r Windows-Programme. Der Text wurde
urspr<EFBFBD>nglich als Begleitmatierial f<>r einen Vortrag <20>ber WINE und die
Integration von Windows-Anwendungen unter GNU/Linux auf dem LinuxTag
2000 vom 30. Juni bis zum 2. Juli 2000 in Stuttgart geschrieben.
2. Einleitung
Mit WINE wird ein umfassender Ansatz zur Integration von
Windows-Anwendungen unter GNU/Linux verfolgt. WINE besteht u.a. aus
einem Loader, mit dem Windows- und DOS-Programme unter Linux in den
Speicher geladen und vom Prozessor des Rechners ausgef<65>hrt werden
k<EFBFBD>nnen. Au<41>erdem stellt das Programm einen gro<72>en Teil der
Schnittstellen (APIs) Windows-basierter Betriebssysteme zur Verf<72>gung.
Diese Schnittstellen werden von Windows-Programmen, die mit WINE
ausgef<EFBFBD>hrt werden, benutzt, so dass solche Programme die selbe,
erwartete Umgebung vorfinden, wie unter Windows. Weil diese
Schnittstellen mit WINE vorhanden sind und deren Definitionen in Form
von Header-Dateien vorliegen, kann WINE auch benutzt werden, um den
Quellcode von Windows-Programmen nach GNU/Linux oder anderen
UNIX-basierten Betriebssystemen zu portieren. Es entstehen dann echte
UNIX/Linux-Programme, welche die selbe Funktionalit<69>t haben, wie ihre
<EFBFBD>quivalenten Programme unter Windows. Die Verwendung eines
einheitlichen APIs unter Windows und Linux hat f<>r Softwarehersteller
den Vorteil, dass nur eine einzige Version des Quellcodes gepflegt und
weiterentwickelt werden muss, die sich unter beiden
Betriebssystemfamilien verwenden l<>sst.
Das WINE-Projekt wurde 1993 gestartet, es wird im wesentlichen von
Freiwilligen getragen, die <20>ber Mailinglisten miteinander
kommunizieren. In letzter Zeit hat WINE zus<75>tzliche Unterst<73>tzung
durch mehrere kommerzielle Unternehmen erfahren, die WINE dazu
einsetzen, ihre Windows-Programme nach GNU/Linux zu portieren. WINE
ist heute in der Lage einen gro<72>en Teil der existierenden
Windows-Programme (16- und 32bit) unter Linux auszuf<75>hren, in einem
begrenzten Umfang k<>nnen auch DOS-Programme mit WINE benutzt
werden. WINE f<>hrt Windows-Programme direkt unter Linux aus, es
ben<EFBFBD>tigt dazu keine speziellen Kernelerweiterungen, keine besonderen
Rechte und keine existierende Windows-Installation. Das Design erlaubt
es, die betreffenden Programme unter Linux genauso schnell
auszuf<EFBFBD>hren, wie unter Windows, weil keine Emulation im Sinne einer
Interpretation von Prozessoranweisungen stattfindet. Zur Ausf<73>hrung
eines bestimmten Programms werden unter GNU/Linux mit WINE theoretisch
die selben Systemressourcen ben<65>tigt, wie unter Windows. Optional kann
WINE eine bestehende Windows-Installation verwenden. Es ist dann
m<EFBFBD>glich, die Einstellungen dieser Installation f<>r Windows-Programme
zu <20>bernehmen und einige Original-Bestandteile von Windows mit WINE zu
verwenden, welche in WINE noch nicht in ausreichendem Umfang zur
Verf<EFBFBD>gung stehen.
Im folgenden wird beschrieben, wie WINE auf einem GNU/Linux-System
installiert und eingerichtet werden kann. Ausgegangen wird dabei von
der Linux-Distribution Debian GNU/Linux 2.2 (potato) und der
WINE-Version 20000614. Bei Verwendung einer anderen Linux-Distribution
oder einer anderen WINE-Version sind die beschriebenen Schritte
entsprechend anzupassen.
3. Bin<69>rpaket oder Quellcode?
In den meisten Linux-Distributionen sind heute WINE-Pakete
enthalten. Hierbei handelt es sich um Bin<69>rpakete, die WINE in einer
Form enthalten, in der es direkt ausgef<65>hrt werden kann. Aktuelle
Versionen solcher Pakete lassen sich auch von verschiedenen
Internetseiten herunterladen. Theoretisch sollte WINE nach der
Installation eines Bin<69>rpakets sinnvoll konfiguriert und sofort
benutzbar sein. Tats<74>chlich ist es in vielen F<>llen jedoch notwendig,
die mit dem Paket installierte Konfiguration zu <20>berarbeiten.
Aufgrund der schnellen Entwicklung von WINE wird zur Zeit empfohlen,
an Stelle eines Bin<69>rpakets den aktuellen Quellcode zu verwenden. Der
Quellcode muss, nachdem man ihn sich beschafft hat, entpackt,
konfiguriert und kompiliert (<28>bersetzt) werden. Dabei entsteht dann
eine Bin<69>rdatei, die genau an das eigene System angepasst ist und
deshalb eine h<>here Wahrscheinlichkeit f<>r optimale Ergebnisse bietet,
als Bin<69>rpakete, die u.U. f<>r ein anders konfiguriertes System
erstellt wurden. Die Verwendung des Quellcodes bietet au<61>erdem die
M<EFBFBD>glichkeit, das Programm relativ einfach aktualisieren zu k<>nnen,
wobei nicht immer wieder das komplette Paket heruntergeladen werden
muss. Dar<61>berhinaus kann mit der Verwendung des aktuellen Quellcodes
sichergestellt werden, dass evtl. auftretende Fehler wirklich in WINE
vorhanden sind und nicht bereits behoben worden sind. Dadurch wird die
M<EFBFBD>glichkeit gesteigert, sinnvolle Fehlerberichte an die
WINE-Entwickler schicken zu k<>nnen.
Die Installation von Bin<69>rpaketen ist abh<62>ngig vom eingesetzten
Paketformat der Distribution (zumeist wird das Redhat- oder
Debian-Format benutzt) sowie der Distribution selbst. Die hierzu
ben<EFBFBD>tigten Informationen sollten sich in der Dokumentation der von
Ihnen eingesetzten Distribution finden. In diesem Text wird die
Installation aus dem Quellcode von WINE beschrieben.
4.0 Systemvoraussetzungen
Damit WINE auf dem System <20>bersetzt und ausgef<65>hrt werden kann, m<>ssen
die folgenden Programme und Dateien installiert sein:
1. Linux-Kernel der Versionsfamilie 2.2.x. (WINE l<>sst sich auch
unter Linux-Kernels der Versionsfamilie 2.0.x ausf<73>hren,
allerdings unterst<73>tzen diese Kernels bestimmte von WINE ben<65>tigte
Eigenschaften nicht. Dies macht sich insbesondere dann bemerkbar,
wenn 32Bit-Windowsprogramme mit WINE ausgef<65>hrt werden sollen, bei
denen mehrere Threads gleichzeitig ausgef<65>hrt werden.) Die
Versionsnummer des aktuell ausgef<65>hrten Linux-Kernels wird
angezeigt, wenn der folgenden Befehl an der Kommandozeile
eingegeben wird:
uname -r
2. Es wird empfohlen, die GNU C-Bibliothek (libc6) ab Version 2.1
einzusetzen. Die Versionsnummer der aktuell eingesetzten
C-Bibliothek kann angezeigt werden, indem der folgende
Befehl benutzt wird:
ls -l /lib/libc.so.*
Auf einigen Systemen ist sowohl die <20>ltere C-Bibliothek libc5,
als auch die neuere Bibliothek libc6 vorhanden. Entscheidend
ist dann in der Regel die neuere Version. Die C-Bibliothek muss
Reentrant sein, damit WINE Multithreading unterst<73>tzen
kann. Dies ist bei allen neueren Linux-Distributionen der
Fall. Die C-Bibliothek befindet sich im Paket libc6. Um WINE zu
<20>bersetzen werden zus<75>tzlich die Entwicklerdateien zur
C-Bibliothek ben<65>tigt. Diese befinden sich unter Debian im
Paket libc6-dev.
3. Weil WINE das X Window System benutzt, werden die X-Bibliotheken
und, wenn WINE <20>bersetzt werden soll, die Entwicklerdateien f<>r
X ben<65>tigt. Die Bibliotheken sind unter Debian im Paket xlib6g
und die Entwicklerdateien im Paket xlib6g-dev enthalten.
4. Dar<61>berhinaus ben<65>tigt WINE die XPM-Bibliothek (Paket xpm4g),
damit das Programm <20>bersetzt werden kann, werden die
Entwicklerdateien f<>r XPM ben<65>tigt, diese befinden sich im Paket
xpm4g-dev.
5. F<>r Programme, die im Textmodus ausgef<65>hrt werden, kann WINE die
Bibliothek libncurses verwenden. Damit die Unterst<73>tzung daf<61>r in
das Programm eingebunden wird, m<>ssen die Entwicklerdateien f<>r
diese Bibliothek installiert sein (Paket libncurses5-dev). Die
Verwendung der ncurses-Bibliothek ist jedoch optional.
6. Ebenfalls optional ist die Unterst<73>tzung einer OpenGL-kompatiblen
Bibliothek, wie z.B. Mesa. Wenn die Unterst<73>tzung f<>r OpenGL in
das Programm eingebunden werden soll, m<>ssen die
OpenGL-Entwicklerdateien auf dem System installiert sein, wie sie
z.B. durch das Paket mesag-dev bereitgestellt werden. Zus<75>tzlich
sind dann nat<61>rlich die OpenGL-Bibliotheken selbst erforderlich.
7. Um WINE zu <20>bersetzen, muss der GNU-C-Compiler benutzt werden.
Empfohlen wird zur Zeit Version 2.95. Weiter werden einige
Standardwerkzeuge wie make, yacc und bison ben<65>tigt, die auf den
meisten Linuxsystemen bereits installiert sein sollten.
Je nachdem, ob in dem zu erzeugenden Bin<69>rcode Debug-Informationen
enthalten sein sollen, werden f<>r die <20>bersetzung und die
Installation von WINE zwischen ca. 100 MB und ca. 250 MB
Speicherplatz auf der Festplatte ben<65>tigt. An den Prozessor des
Rechners werden keine besonderen Anforderungen gestellt, so ist ein
Prozessor der Pentium-Klasse mit 133 Mhz ausreichend, um mit WINE
beispielsweise Textverarbeitungsprogramme auszuf<75>hren. F<>r Spiele
und andere Multimedia-Anwendungen wird allerdings in der Regel ein
schnellerer Rechner ben<65>tigt. Wichtig ist, dass sich in dem Rechner
ausreichend Arbeitsspeicher (RAM) befindet. Zur Ausf<73>hrung gr<67><72>erer
Windows-Programme sollte der Rechner mit 64 MB RAM ausgestattet
sein.
5.0 Beschaffung und Installation des Quellcodes
WINE kann von verschiedenen Servern im Internet per FTP oder HTTP
heruntergeladen werden. Normalerweise kann der jeweils aktuelle
Quellcode u.a. von den folgenden Adressen bezogen werden:
* ftp://metalab.unc.edu/pub/Linux/ALPHA/wine/development/
* ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/
* ftp://orcus.progsoc.uts.edu.au/pub/wine/development/
* http://metalab.unc.edu/pub/Linux/ALPHA/wine/development/
Bei der Entwicklung von WINE werden zur Zeit noch keine
Versionsnummern benutzt. An Stelle dessen tr<74>gt jede Ausgabe eine
Zahl, welche nach dem Schema Jahreszahl, Monat, Tag dem Datum
entspricht, an welchem die betreffende Version herausgegeben wurde.
Die Datei Wine-20000614.tar.gz in einem der oben aufgef<65>hrten
Verzeichnisse enth<74>lt also die Version von WINE. die am 14. Juni
2000 herausgegeben wurde. Prinzipiell ist es zu empfehlen, die
jeweils neueste Version zu verwenden. Nachdem der Quellcode
heruntergeladen worden ist, kann er durch die Eingabe des folgenden
Befehls im aktuellen Arbeitsverzeichnis entpackt werden:
tar -xvzf Wine-20000614.tar.gz
Dabei ist Wine-20000614.tar.gz nat<61>rlich durch den Namen der
heruntergeladenen Datei zu ersetzen. Der Quellcode wird dann in ein
Unterverzeichnis des aktuellen Verzeichnisses entpackt, dessen Name
sich aus der Bezeichnung wine und, getrennt von einem Bindestrich,
dem Herausgabedatum der benutzten Version zusammensetzt, also
beispielsweise wine-20000614. Normalerweise empfiehlt es sich,
dieses Verzeichnis in wine umzubenennen, wie es durch Eingabe des
folgenden Befehls geschehen kann:
mv wine-20000614 wine
5.1 Aktualisieren des Quellcodes mit Patchdateien
Neben den komprimierten Tar-Archiven, welche den Quellcode von WINE
beinhalten, befinden sich in den aufgef<65>hrten Verzeichnissen auch
so genannte Patch-Dateien, welche lediglich die <20>nderungen
enthalten, die zwischen zwei Ausgaben an WINE vorgenommen
wurden. Diese Dateien sind normalerweise viel kleiner als der
komplette Quellcode, so dass es sich empfiehlt, sie zu verwenden,
wenn das Programm von einer Version auf die n<>chste aktualisiert
werden soll. Falls auf einem Rechner beispielsweise Wine-20000614
installiert ist und auf WINE-20000614 aktualisiert werden soll, so
w<>re die Datei WINE-20000614.diff.gz herunterzuladen. Die in der
Datei beschrieben Ver<65>nderungen k<>nnen auf den installierten
Quellcode angewandt werden, indem zun<75>chst in das Basisverzeichnis
des Quellcodes (also in das Verzeichnis wine, welches durch die
oben beschriebenen Schritte entstanden ist) gewechselt wird und
dann das Programm patch wie folgt aufgerufen wird:
gunzip -c ../Wine-20000526.diff.gz | patch -p1
Hier wird davon ausgegangen, dass sich die Patch-Datei in dem
Verzeichnis befindet, welches dem WINE-Verzeichnis (wine)
<20>bergeordnet ist und den Namen Wine-20000526.diff.gz tr<74>gt. Der
Dateiname ist entsprechend anzupassen, wenn eine Datei mit einem
anderen Namen oder aus einem anderen Verzeichnis benutzt wird.
5.2 Herunterladen und Aktualisieren von WINE mit CVS
Alternativ kann der Quellcode vom CVS-Server des WINE-Projektes
installiert werden. Der Vorteil dieses Verfahrens besteht darin,
dass es jederzeit unkompliziert m<>glich ist, den eigenen Quellcode
an den Entwicklungsstand des Projekts anzupassen ohne dass auf eine
neue Ausgabe des Programms gewartet werden muss. F<>r jeden, der
plant, selbst an dem Projekt mitzuarbeiten, ist die Verwendung von
CVS normalerweise erforderlich. Damit CVS benutzt werden kann, muss
das Programm cvs nat<61>rlich installiert sein. Unter Debian ist es in
dem gleichnamigen Paket enthalten. Wenn dies sichergestellt ist,
kann durch die Umgebungsvariable CVSROOT eingestellt werden, von wo
der Quellcode bezogen, bzw. aktualisiert werden soll. Bei
Verwendung der Bash kann dazu der folgende Befehl eingegeben
werden:
export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine
Danach kann man sich bei dem CVS-Server anmelden. Hierzu dient
dieser Befehl:
cvs login
Das Programm erfragt dann ein Passwort f<>r den Zugriff auf den
Server. Hier ist das Passwort cvs zu verwenden. Nun kann der
Quellcode vom Server heruntergeladen werden, indem der n<>chste
Befehl eingegeben wird:
cvs -z 3 checkout wine
Im aktuellen Arbeitsverzeichnis wird dann ein Unterverzeichnis mit
der Bezeichnung wine angelegt. Sobald der Befehl abgeschlossen ist,
befinden sich in diesem Verzeichnis der aktuelle Quellcode des
Projekts und einige zus<75>tzliche Dateien, die von CVS ben<65>tigt
werden.
Um den Quellcode auf den neuesten Stand zu bringen, kann dieser
Befehl benutzt werden:
cvs -z 3 update -PAd WINE
Informationen <20>ber die hier verwendeten Parameter beim Aufruf von
CVS und <20>ber weitere M<>glichkeiten des Programms befinden sich
u.a. in der Manualseite zu cvs(1) sowie auf der CVS-Homepage, die
unter http://www.sourcegear.com/CVS zu erreichen ist. Weitere
Hinweise im Hinblick auf CVS und WINE sind unter der Adresse
http://www.winehq.com/dev.html verf<72>gbar.
6.0 Konfiguration und <20>bersetzung des Quellcodes
Vorausgesetzt, der Quellcode befindet sich im Unterverzeichnis wine
des aktuellen Arbeitsverzeichnisses, ist zun<75>chst in dieses
Verzeichnis zu wechseln, um alle weiteren Schritte durchzuf<75>hren:
cd wine
Dann kann das Skript configure aufgerufen werden. Dieses Skript
f<>hrt eine Reihe von Tests durch, die u.a. untersuchen, ob das
System alle notwendigen Eigenschaften erf<72>llt und die ben<65>tigten
Entwicklerdateien installiert sind. Daraufhin erzeugt es die
Dateien, durch welche die <20>bersetzung des Quellcodes gesteuert
wird. Dem Skript k<>nnen verschiedene Parameter <20>bergeben werden,
mit denen sich beispielsweise bestimmen l<>sst, dass in den zu
erzeugenden Programmen und Bibliotheken keine Debug-Mitteilungen
enthalten sein sollen. Die vollst<73>ndige Liste der verf<72>gbaren
Optionen f<>r configure wird angezeigt, wenn das Skript mit der
Option --help aufgerufen wird. Normalerweise reicht es aus, das
Skript folgenderma<6D>en aufzurufen:
./configure
Falls wichtige Dateien oder Eigenschaften des Systems von configure
nicht gefunden werden k<>nnen, erfolgt unter Umst<73>nden eine Warn-
oder Fehlermeldung. Solche Fehler sollten behoben werden, bevor mit
der <20>bersetzung des Quellcodes fortgefahren wird.
Im n<>chsten Schritt wird der Quellcode <20>bersetzt. Dazu sind
hintereinander die folgenden beiden Befehle zu benutzen:
make depend
make
Auf der Partition, auf welcher sich das Verzeichnis mit dem
Quellcode befindet, werden f<>r die komplette <20>bersetzung zur Zeit
ungef<65>hr 230 MB Speicherplatz ben<65>tigt. Der gr<67><72>te Teil dieses
Speicherplatzes wird dabei von den Debug-Informationen in den
Objektdateien, die beim <20>bersetzen erzeugt werden, ben<65>tigt. Falls
nicht beabsichtigt wird, irgendwelche Fehler in WINE zu
untersuchen, k<>nnen die Bin<69>rdateien auch ohne Debug-Informationen
erzeugt werden, dazu ist der letzte der beiden oben genannten
Befehle durch den n<>chsten Befehl zu ersetzen (f<>r die <20>bersetzung
werden dann nur noch ungef<65>hr 80 MB Speicherplatz ben<65>tigt).
make CFLAGS="-O2"
Nun kann WINE auf dem System installiert werden. Hierzu ist mit den
Rechten des Administrators der folgende Befehl einzugeben:
make install
Dadurch werden die ausf<73>hrbaren Programme von WINE standardm<64><6D>ig in
das Verzeichnis /usr/local/bin, die Programmbibliotheken in das
Verzeichnis /usr/local/lib, die Manualseiten unterhalb des
Verzeichnisses /usr/local/man und einige Header-Dateien in das
Verzeichnis /usr/local/include/wine installiert.
Achtung:
Standardm<64><6D>ig wird bei einigen Distributionen (z.B. bei Debian
GNU/Linux) in dem Verzeichnis /usr/local/lib nicht nach
Programmbibliotheken gesucht. Falls beim Start von WINE gemeldet wird,
dass bestimmte Bibliotheken nicht geladen werden k<>nnen, sollte der
Name dieses Verzeichnisses in die Datei /etc/ld.so.conf (in eine
eigene Zeile) eingetragen und danach das Programm ldconfig aufgerufen
werden.
7.0 Konfiguration
Wie viele UNIX-Programme kann WINE entweder <20>ber eine systemweit
g<>ltige Konfigurationsdatei oder <20>ber eine benutzerspezifische
Datei im Heimatverzeichnis des betreffenden Benutzers konfiguriert
werden. Die benutzerspezifische Konfigurationsdatei tr<74>gt den
Namen .winerc. Wenn diese Datei existiert, wird die systemweit
g<>ltige Konfigurationsdatei (standardm<64><6D>ig
/usr/local/etc/wine.conf) nicht beachtet und es werden alle
Einstellungen aus der Konfigurationsdatei des betreffenden
Benutzers gelesen. F<>r den Anfang ist es zu empfehlen, mit einer
benutzerspezifischen Konfigurationsdatei zu beginnen.
7.1 Aufbau der Konfigurationsdatei
Von Ihrem Aufbau und den M<>glichkeiten zur Konfiguration
unterscheidet sich die globale Konfigurationsdatei nicht von der
benutzerspezifischen. Das Format orientiert sich an den von Windows
her bekannten *.ini-Dateien, die Datei besteht aus einzelnen
Bl<42>cken, welche durch Bezeichner eingeleitet werden, die in eckigen
Klammern und in einer eigenen Zeile stehen. Innerhalb eines Blockes
befinden sich Paare von Variablen und Werten, die durch ein
Gleichheitszeichen miteinander verbunden sind. Diese Paare stehen
ebenfalls jeweils in einer Zeile. Kommentare werden in der Datei
durch ein Semikolon eingeleitet. Au<41>erdem d<>rfen leere Zeilen
benutzt werden, um die Datei zu strukturieren. Ein Beispiel f<>r
einen solchen Block w<>re also:
[Drive C]
Path=/home/karl
Type=hd
Label=Laufw.C
Filesystem=win95
Au<41>erdem ist es m<>glich, innerhalb der Konfigurationsdatei mit
Werten von Umgebungsvariablen zu arbeiten. Dazu ist an Stelle eines
Wertes der Name der zu verwendenden Umgebungsvariablen in
geschweiften Klammern und mit einem vorangestellten Dollarzeichen
anzugeben. Soll beispielsweise der Variablen Path aus dem obigen
Beispiel der Wert zugeordnet werden, den die Umgebungsvariable HOME
zur Zeit der Ausf<73>hrung von WINE hat, so w<>re die entsprechende
Zeile folgenderma<6D>en zu schreiben:
Path=${HOME}
Im Basisverzeichnis des WINE-Quellcodes befindet sich in der Datei
wine.ini ein Beispiel als Vorlage f<>r die Erstellung einer eigenen
Konfigurationsdatei. Die Datei enth<74>lt alle wichtigen Bl<42>cke und
Variablen, sie muss jedoch an die eigene Konfiguration angepasst
werden, bevor WINE das erste Mal benutzt wird. Angenommen, das
Basisverzeichnis des WINE-Quellcodes tr<74>gt den Namen wine und ist
ein Unterverzeichnis des eigenen Heimatverzeichnisses, dann kann
diese Vorlage durch den folgenden Befehl an den richtigen Platz
kopiert werden:
cp ~/wine/wine.ini ~/.winerc
Die Werte, welche Variablen in der Konfigurationsdatei zugewiesen
werden, lassen sich in drei Typen einteilen: Zeichenketten, Zahlen
und Boolsche Werte. Im Fall von Boolschen Werten l<>sst sich
entweder true oder false, 1 oder 0 beziehungsweise yes oder no
angeben. In den folgenden Beispielen wird die true / false
-Schreibweise benutzt.
7.2 Konfiguration von Laufwerksbuchstaben
Zwischen UNIX/Linux auf der einen und DOS bzw. Windows auf der
anderen Seite gibt es einige Unterschiede in der Art, wie
Datentr<74>ger und Dateien bezeichnet werden. Unter UNIX/Linux gibt es
ein Dateisystem mit einem Wurzelpunkt (/), in das unterschiedliche
Datentr<74>ger durch einen speziellen Befehl (mount) eingebunden
werden. Alle Dateien auf eingebundenen Datentr<74>gern k<>nnen deswegen
innerhalb dieses Dateisystems angesprochen werden. DOS und Windows
verwenden jedoch f<>r jeden erkannten Datentr<74>ger ein eigenes
Dateisystem. Um eine bestimmte Datei eindeutig zu bezeichnen, ist
es bei diesen Betriebssystemen deswegen notwendig, neben dem Pfad-
und Dateinamen einen so genannten Laufwerksbuchstaben
anzugeben. <20>blicherweise entspricht dabei der Laufwerksbuchstabe A
dem ersten Diskettenlaufwerk und der Buchstabe C der ersten
Festplattenpartition des Systems.
Weil Programme, die f<>r DOS oder Windows geschrieben sind,
Laufwerksbuchstaben verwenden, um Dateien zu bezeichnen, muss WINE
diese Buchstaben auf das UNIX-Dateisystem abbilden. Das Problem ist
auf die folgende Art gel<65>st: In der Konfigurationsdatei (.winerc
oder /usr/local/etc/wine.conf) wird jedem Laufwerksbuchstaben ein
Verzeichnis im UNIX-Dateisystem zugeordnet. Dieses Verzeichnis
stellt dann (aus Sicht der Windows-Programme) das Basisverzeichnis
des entsprechenden Laufwerks dar. Ist also beispielsweise das
Verzeichnis /var/winroot dem Laufwerksbuchstaben C zugeordnet und
w<>rde ein Windows-Programm unter WINE versuchen, die Datei
C:\Dokumente\finanzamt.doc zu <20>ffnen, so w<>rde in Wirklichkeit die
Datei /var/winroot/Dokumente/finanzamt.doc ge<67>ffnet werden,
vorrausgesetzt, diese Datei existiert tats<74>chlich. Durch diesen
Mechanismus kann auch erreicht werden, dass von Windows-Programmen,
die unter WINE ausgef<65>hrt werden, nur auf einen Teil des
UNIX-Dateisystems zugegriffen werden kann.
Ein weiterer Unterschied zwischen den Dateisystemen unter DOS und
Windows auf der einen und UNIX/Linux auf der anderen Seite besteht
in der Ber<65>cksichtigung von Gro<72>- und Kleinschreibung bei
Dateinamen. W<>hrend es unter Linux durchaus m<>glich ist, dass sich
in einem Verzeichnis gleichzeitig Dateien mit den Namen brief.txt,
Brief.txt und brief.TXT befinden, ist dies unter Windows
ausgeschlossen, hier wird beispielsweise die Datei brief.txt
ge<67>ffnet, falls diese existiert, aber eigentlich die Datei
Brief.txt angefordert wurde. Die meisten Programme, die f<>r DOS
oder 16Bit-Windows geschrieben wurden, erwarten dar<61>berhinaus, dass
Dateinamen aus nicht mehr als acht Zeichen zuz<75>glich einer drei
Zeichen langen Erweiterung bestehen. WINE muss aus diesen Gr<47>nden
entscheiden, welche Datei tats<74>chlich ge<67>ffnet wird, wenn es
aufgrund von Gro<72>- und Kleinschreibung unterschiedliche
M<>glichkeiten gibt. Au<41>erdem muss es die Dateinamen in acht Zeichen
lange Namen <20>bersetzen, falls sie von 16bit-Programmen abgefragt
werden.
Wenn WINE mit einer bestehenden Windows-Installation benutzt werden
soll, sollte darauf geachtet werden, dass die Laufwerksbuchstaben
unter Windows und WINE <20>bereinstimmen. Befindet sich die
Windows-Installation also beispielsweise auf der Partition
/dev/hda1, welche unter Windows <20>ber den Laufwerksbuchstaben C
angesprochen wird, so sollte diese Partition unter GNU/Linux in ein
beliebiges Verzeichnis eingebunden werden und dieses Verzeichnis in
der Konfigurationsdatei von WINE wieder dem Laufwerksbuchstaben C
zugeordnet werden.
Ein Beispiel f<>r die Zuordnung von UNIX-Verzeichnissen und
Laufwerksbuchstaben in der Konfigurationsdatei wurde weiter oben
bereits gebracht. Eine solche Definition besteht aus einem Block,
dessen Name sich aus dem Schl<68>sselwort Drive und dem Buchstaben des
Laufwerks zusammensetzt, f<>r das die Definition gelten soll. Ein
Beispiel w<>re also [Drive C]. Darauf folgen verschiedene Variablen,
mit denen die Eigenschaften des Laufwerkes festgelegt werden. Die
wichtigste dieser Variablen ist Path. Hiermit wird bestimmt,
welchem UNIX-Verzeichnis das Laufwerk entsprechen soll (Beispiele:
Path=/home/karl, Path=${HOME}). Die weiteren Variablen haben die
folgende Bedeutung:
Type
Windows kann Anwendungen mitteilen, von welchem Typ
(Festplatte, CDROM usw.) ein bestimmter Datentr<74>ger ist. Mit
dieser Variablen wird WINE mitgeteilt, welchen Typ das
entsprechende Laufwerk haben soll. M<>gliche Werte sind
floppy (Diskettenlaufwerk), hd (Festplattenpartition), cdrom
(CDROM-Laufwerk) und network (Netzwerklaufwerk). Im
allgemeinen empfiehlt es sich, hier den Typ anzugeben, der
dem UNIX-Verzeichnis, welches dem Laufwerk zugeordnet ist,
entspricht. Beispiel: Type=floppy.
Label
Unter DOS und Windows k<>nnen Laufwerke eine so genannte
Datentr<74>gerbezeichnung haben. Diese Bezeichnung kann von
Windows-Anwendungen abgefragt werden. Mit dieser Variable
kann angegeben werden, welchen Datentr<74>gerbezeichnung WINE
zur<75>ckliefern soll, falls eine Anwendung diese f<>r das
Laufwerk abfragt. Die Datentr<74>gerbezeichnung darf aus nicht
mehr als 11 Buchstaben bestehen. Beispiel: Label=Platte1.
Serial
Jedes Laufwerk hat unter Windows eine so genannte
Seriennummer, die ebenfalls von Windows-Programmen abgefragt
werden kann. Mit dieser Variablen l<>sst sich in Form eine
acht-stelligen hexadezimalen Zahl angeben, welche
Seriennummer in solchen F<>llen zur<75>ckgeliefert werden
soll. Beispiel: Serial=23f78a6b.
Filesystem
Hiermit wird bestimmt, welche Eigenschaften das emulierte
Dateisystem auf dem betreffenden Laufwerk haben soll. Es
sind die folgenden Werte m<>glich:
msdos
Auf dem Laufwerk sind nur Dateinamen mit einer L<>nge
von acht Zeichen und einer Erweiterung, die aus drei
Zeichen besteht, zugelassen. Unterschiede in Gro<72>- und
Kleinschreibung werden nicht
ber<65>cksichtigt. Alternativ f<>r msdos k<>nnen die
Bezeichnungen dos oder fat f<>r diesen Dateisystemtyp
benutzt werden.
win95
Auf dem Laufwerk sind lange Dateinamen zugelassen. DOS
und 16bit-Windowsprogramme k<>nnen jedoch weiterhin
kurze Dateinamen benutzen. Unterschiede in Gro<72>- und
Kleinschreibung werden nicht ber<65>cksichtigt. Dies ist
die empfohlenen Einstellung f<>r fast alle Anwendungen.
Alternativ f<>r win95 kann dieser Dateisystemtyp auch
als vfat bezeichnet werden.
unix
Das Dateisystem auf dem Laufwerk verh<72>lt sich <20>hnlich
wie ein typisches UNIX-Dateisystem, d.h. Dateinamen
k<>nnen die normalerweise erlaubte L<>nge haben und die
Gro<72>- und Kleinschreibung ist bedeutsam. Mit dieser
Einstellung kommen die meisten Windows-Programme nicht
zurecht. Probleme treten beispielsweise dann auf,
wenn ein Windows-Programm eine Datei zun<75>chst unter
dem Namen Daten speichert und dann unter dem Namen
DATEN wieder <20>ffnen will.
Achtung:
Es ist zu beachten, dass mit dieser Einstellung nicht
angegeben wird, welche Eigenschaften das zugrunde liegende
UNIX-Dateisystem hat, sondern welche Eigenschaften von WINE
f<>r das entsprechende Laufwerk emuliert werden sollen. Es
ist also durch aus m<>glich (und in den meisten F<>llen
erforderlich) f<>r ein Laufwerk, das sich auf einem
UNIX-Dateisystem befindet, die Einstellung win95 zu
verwenden. Falls es sich bei dem Datentr<74>ger, auf dem sich
das dem Laufwerk zugeordnete Verzeichnis befindet,
allerdings um ein FAT-Dateisystem handelt, welches mit dem
FAT-Treiber von Linux (und nicht, wie <20>blich, mit dem
VFAT-Treiber) betrieben wird, dann muss hier der
Dateisystemtyp msdos benutzt werden, weil es sonst passieren
k<>nnte, dass WINE versucht, auf dem betreffenden Datentr<74>ger
Dateien mit langen Namen anzulegen, was dann zu einem Fehler
f<>hren w<>rde. Beispiel: Filesystem=win95.
Device
In besonderen F<>llen ist es notwendig, dass die
Windows-Programme direkt, also unter Umgehung des
Dateisystems, auf den Datentr<74>ger schreiben oder von ihm
lesen. Damit dies auch mit WINE m<>glich ist, kann hier der
Name der Ger<65>tedatei angegeben werden, welcher den
Datentr<74>ger unter Linux repr<70>sentiert. Dies ist nur dann
sinnvoll, wenn das dem betreffenden Laufwerk zugeordnete
Verzeichnis dem Mountpunkt des hier angegebenen Datentr<74>gers
entspricht. Der direkte Ger<65>tezugriff sollte normalerweise
nur f<>r solche Datentr<74>ger gestattet werden, deren Inhalt
nicht besonders gesch<63>tzt werden muss (u.U. Disketten) oder
von denen ohnehin nur gelesen werden kann
(z.B. CDROMs). Damit auf den Datentr<74>ger geschrieben werden
kann, ist es zus<75>tzlich nat<61>rlich notwendig, dass die Rechte
an der betreffenden Ger<65>tedatei ausreichend sind. Beispiel:
Device=/dev/fd0.
FailReadOnly
Eine Reihe von Windows-Programmen <20>ffnen Dateien prinzipiell
zum Lesen und Schreiben, auch wenn aus den betreffenden
Dateien lediglich gelesen werden soll. Dieses Verhalten
f<>hrt normalerweise dazu, dass Dateien, in die von WINE
nicht geschrieben werden darf oder die sich auf Datentr<74>gern
befinden, auf die nicht geschrieben werden kann (etwa
CDROMs), nicht ge<67>ffnet werden k<>nnen. Aus diesem Grund
<20>ffnet WINE Dateien standardm<64><6D>ig zum Lesen, falls eine
Datei nicht zum Lesen und zum Schreiben ge<67>ffnet werden
konnte. Wenn die Variable FailReadOnly auf den Wert true
gesetzt wird, verh<72>lt sich WINE so wie unter UNIX <20>blich und
liefert eine Fehlermeldung an das Windows-Programm, falls
eine Datei nicht zum Schreiben ge<67>ffnet werden kann. In der
Regel empfiehlt es sich, hier die Standardeinstellung zu
<20>bernehmen. Beispiel: FailReadOnly=true.
ReadVolInfo
Wenn der Wert dieser Variablen auf true gesetzt ist,
versucht WINE, die Seriennummer und die
Datentr<74>gerbezeichnung des betreffenden Laufwerks direkt von
dem Datentr<74>ger zu lesen. Dazu muss dem Laufwerk eine
Ger<65>tedatei zugeordnet sein (Variable device). Diese
Einstellung ist vor allem f<>r solche Programme sinnvoll, die
nur dann funktionieren, wenn sich beispielsweise die
richtige CDROM im Laufwerk befindet und die dies anhand der
Seriennummer oder der Datentr<74>gerbezeichnung
feststellen. Beispiel: ReadVolInfo=true
7.3 Allgemeine Einstellungen
Im Abschnitt [wine] der Konfigurationsdatei werden die wichtigsten
allgemeinen Einstellungen vorgenommen. Im wesentlichen handelt es
sich dabei um Verzeichnisangaben. Es ist zu beachten, dass diese
Verzeichnisangaben in der unter DOS und Windows <20>blichen Weise zu
erfolgen haben. D.h., jedem Verzeichnis muss ein Laufwerksbuchstabe
vorangestellt werden. Laufwerksbuchstaben und Verzeichnis werden
durch einen Doppelpunkt voneinander getrennt, au<61>erdem werden
einzelne Verzeichnisse nicht durch einen normalen Schr<68>gstrich,
sondern durch einen umgekehrten Schr<68>gstrich (Backslash)
voneinander separiert. Die Angaben werden durch die im vorherigen
Abschnitt beschriebenen Zuordnungen von Laufwerksbuchstaben in
UNIX-Dateinamen <20>bersetzt.
Windows
Unter Windows spielt das Windows-Verzeichnis eine besondere
Rolle. Programme legen hier oft Initialisierungsdateien ab
und Installationsprogramme kopieren gelegentlich
verschiedene Dateien in dieses Verzeichnis. Mit der
Variablen Windows wird eingestellt, welches Verzeichnis von
den unter WINE ausgef<65>hrten Programmen als
Windows-Verzeichnis behandelt werden soll. Das hier
angegebene Verzeichnis muss existieren, bevor WINE das erste
Mal gestartet wird. Wenn WINE eine bestehende
Windows-Installation verwenden soll, muss hier das
Verzeichnis angegeben werden, in dem sich die Installation
befindet.
Falls WINE mit einer existierenden Windows-Installation
verwendet werden soll und diese Installation sich auf der
Festplattenpartition befindet, die unter Windows den
Laufwerksbuchstaben C: tr<74>gt und unter Linux durch die
Ger<65>tedatei /dev/hda1 repr<70>sentiert wird, so k<>nnte diese
Partition beispielsweise unter Linux beispielsweise in das
Verzeichnis /Windows eingebunden werden. Diesem Verzeichnis
w<>re dann im Abschnitt, welcher die
Laufwerksbuchstabenkonfiguration enth<74>lt der
Laufwerksbuchstabe C: zuzuordnen:
[Drive C]
Path=/Windows
Type=hd
Label=windows
Filesystem=win95
Wenn weiter der Name des Windows-Verzeichnisses dieser
Installation windows lautet (unter Windows also C:\windows
und unter Linux /Windows/windows), so w<>re im Abschnitt
[wine] der Konfigurationsdatei folgende Angabe vorzunehmen:
Windows=C:\Windows
Soll WINE jedoch ohne existierende Windows-Installation
benutzt werden, so kann ein beliebiges Verzeichnis als
Wurzelverzeichnis f<>r das Laufwerk dienen, welches das
Windows-Verzeichnis beinhaltet, beispielsweise k<>nnte
hierf<72>r das Verzeichnis /Windows angelegt werden. In diesem
Verzeichnis m<>sste nun das Windows-Verzeichnis erzeugt
werden, welches daraufhin wie oben beschrieben im Abschnitt
[wine] als Windows-Verzeichnis deklariert werden m<>sste.
System
Das System-Verzeichnis hat eine <20>hnliche Bedeutung wie das
Windows-Verzeichnis. Unter Windows befinden sich in diesem
Verzeichnis im wesentlichen die Programmbibliotheken, es ist
normalerweise ein Unterverzeichnis des
Windows-Verzeichnisses. Dieses Verzeichnis muss ebenfalls
existieren, bevor WINE das erste Mal gestartet wird. Auch
hier muss das System-Verzeichnis der bestehenden
Windows-Installation angegeben werden, falls eine solche
benutzt werden soll. Unter Windows 95/98 tr<74>gt dieses
Verzeichnis normalerweise den Namen system und unter Windows
NT den Namen system32. Beispiel: System=C:\Windows\System.
Temp
Das Temp-Verzeichnis wird von vielen Windows-Programmen dazu
benutzt, tempor<6F>re Dateien abzulegen. Damit dies gelingt,
muss hier ein Verzeichnis angegeben werden, welches sich auf
einem Laufwerk befindet, das einem UNIX-Verzeichnis
entspricht, in dem Schreibberechtigung besteht. Beispiel:
Temp=D:\tmp.
Path
Diese Variable hat die gleiche Bedeutung wie die
Umgebungsvariable PATH unter UNIX. Ihr Wert besteht aus
einer Kette einzelner Verzeichnisnamen, die nach einem
auszuf<75>hrenden Programm durchsucht wird, wenn der Name eines
solchen Programms nicht mit Verzeichnisnamen angegeben
wurde. Es ist zu beachten, dass die einzelnen Elemente diese
Variable unter Windows nicht durch einen Doppelpunkt sondern
durch ein Semikolon voneinander getrennt werden, au<61>erdem
erwarten viele Windows-Programme, dass das Windows- und das
System-Verzeichnis in dieser Variablen enthalten
sind. Beispiel:
Path=C:\Windows;C:\Windows\System;D:\Winstuff.
Profile
Diese Variable wird von WINE benutzt, um den
benutzerspezifischen Teil der Systemregistratur einer
bestehenden Windows-Installation zu laden. Falls es sich bei
der bestehenden Installation um Windows 95/98 handelt, das
nicht mit mehreren Benutzern betrieben wird oder ohne eine
bestehende Windows-Installation gearbeitet werden soll,
braucht die Variable Profile nicht gesetzt zu werden. Wenn
jedoch eine Windows NT- oder eine Windows 95/98-Installation
mit mehreren Benutzern eingesetzt wird, muss hier angegeben
werden, aus welchem Verzeichnis WINE die benutzerspezifische
Registrationsdaten laden soll. Diese Verzeichnisse befinden
sich normalerweise im Unterverzeichnis Profiles des
Windows-Verzeichnis und tragen den Namen des Benutzers,
dessen Konfigurationsdaten sie beherbergen. Beispiel:
Profile=C:\Windows\Profiles\Peter.
GraphicsDriver
WINE kann unterschiedliche Treiber f<>r die graphische
Ausgabe verwenden. Welcher Treiber zu verwenden ist, wird
mit dieser Variablen festgelegt. Zur Zeit stehen zwei
Treiber zur Verf<72>gung, n<>mlich x11drv f<>r die Verwendung des
X Window Systems und ttydrv f<>r die Verwendung von WINE an
der Konsole. Der Treiber ttydrv ist zur Zeit nicht voll
funktionsf<73>hig, weswegen sich hier nur die Verwendung des
Treibers x11drv empfiehlt, dies ist auch die
Standardeinstellung, wenn die Variable nicht gesetzt
wird. Beispiel: GraphicsDriver=x11drv.
7.4 Konfiguration der zu verwendenden Bibliotheken
Wie UNIX/Linux-Programme bestehen Windows-Programme in der Regel
aus der eigentlichen Programmdatei und einer Reihe von
Programmbibliotheken, die beim Laden des Programms oder sp<73>ter mit
dem Programm verbunden werden. Eine Reihe der Programmbibliotheken
unter Windows stellt dabei gleichzeitig die Schnittstelle zum
Betriebssystem dar. Neben dem eigentlichen Windows-Programm werden
also die Bibliotheken ben<65>tigt, um das Programm ausf<73>hren zu
k<>nnen.
WINE stellt eine gro<72>en Anzahl der normalerweise unter Windows
verf<72>gbaren Bibliotheken zur Verf<72>gung. Diese Bibliotheken liegen
entweder in Form eigener Dateien vor, welche sich standardm<64><6D>ig im
Verzeichnis /usr/local/lib befinden oder sie sind direkt in der
Programmdatei wine enthalten. WINE ist jedoch auch in der Lage, die
normalen Windows-Bibliotheken zu verwenden, dies ist beispielsweise
dann notwendig, wenn von einem Programm eine Bibliothek ben<65>tigt
wird, bei der es sich nicht um eine standardm<64><6D>ige
Windows-Bibliothek handelt, sondern um eine, die dem System w<>hrend
der Installation des betreffenden Programms hinzugef<65>gt worden
ist. Solche Bibliotheken werden normalerweise nicht von WINE zur
Verf<72>gung gestellt.
Falls WINE mit einer bestehenden Windows-Installation benutzt wird,
bietet es sich u.U. an, in einigen F<>llen an Stelle der von WINE
zur Verf<72>gung gestellten Bibliotheken die Bibliotheken der
Windows-Installation zu verwenden. Diese sind in vielen F<>llen
vollst<73>ndiger und k<>nnen dem auszuf<75>hrenden Programm deswegen eher
die erwartete Funktionalit<69>t zur Verf<72>gung stellen. Dabei ist
jedoch zu beachten, dass dies nur mit solchen Bibliotheken m<>glich
ist, die keine Betriebssystemfunktionen beinhalten. Bibliotheken,
die lediglich einfachen Programmcode, wie beispielsweise den f<>r
h<>ufig ben<65>tigte Dialoge, beinhalten, k<>nnen hingegen problemlos
aus einer bestehenden Windows-Installation benutzt werden.
Die meisten Bibliotheken stehen unter Windows (95/98) in zwei
verschiedenen Versionen zur Verf<72>gung, einer 32Bit Version, die von
32Bit-Programmen geladen werden kann und einer 16Bit-Version, die
von 16Bit-Programmen benutzt werden kann. Beide Versionen benutzen
in der Regel Programmcode aus der jeweils zugeh<65>rigen anderen
Version (Unter Windows 95/98 befindet sich die eigentliche
Funktionalit<69>t meist in den 16Bit-Bibliotheken, die von den
32Bit-Versionen geladen und aufgerufen werden). Deswegen ist es
erforderlich, dass immer jeweils beide Versionen einer Bibliothek
als Windows- oder als WINE-Bibliothek geladen werden, andere
Einstellungen f<>hren in der Regel direkt nach dem Aufruf von WINE
zu Fehlern. Die folgende Tabelle zeigt, welche der wichtigsten 16-
und 32-Bit Bibliotheken zusammen geh<65>ren und gibt Auskunft dar<61>ber,
ob diese Bibliotheken aus einer bestehenden Windows-Installation
geladen werden k<>nnen oder unbedingt von WINE zur Verf<72>gung
gestellt werden m<>ssen. Es wird jeweils zun<75>chst die 16-Bit Version
und dann die 32-Bit Version genannte
krnl386
kernel32
Diese Bibliothek stellt die Schnittstelle zu den grundlegenden
Funktionen, wie Dateizugriff, Ein- und Ausgabe oder
Prozesssynchronisation, von Windows-Betriebssystemen zur Verf<72>gung.
Deswegen k<>nnen hier nicht die Bibliotheken einer
Windows-Installation benutzt werden.
-
ntdll
Diese Bibliothek enth<74>lt die Schnittstelle zu dem Betriebssystem
Windows NT. Es muss deswegen die WINE-Version benutzt werden.
-
advapi32
Hier befinden sich u.a. Funktionen zum Zugriff auf die
Windows-Registratur sowie Sicherheitsfunktionen und
kryptographische Funktionen. In der Regel empfiehlt es sich, WINEs
Version dieser Bibliothek zu verwenden.
winsock
wsock32
Hier befindet sich die Internet Protokoll (IP) Schnittstelle von
Windows. Mit WINE wird die IP-Funktionalit<69>t des Betriebssystems
(Linux) benutzt, so dass hier die WINE-Versionen dieser
Bibliotheken benutzt werden m<>ssen, welche die IP-Aufrufe von
Windows-Programmen an Linux weiterleiten.
gdi
gdi32
GDI steht f<>r Graphic Device Interface. Die Bibliothek stellt eine
einheitliche Schnittstelle zur Bildschirmausgabe und zu Druckern
dar. Auch hier m<>ssen die WINE-Versionen benutzt werden.
user
user32
User stellt u.a. Funktionen zur Fensterverwaltung, zu Men<65>s oder
zur Bedienung der Zwischenablage bereit. Die Windows 95/98
Versionen dieser Bibliotheken k<>nnen theoretisch unter bestimmten
Bedingungen mit WINE benutzt werden. Die USER-Bibliotheken von
Windows NT rufen in der Regel Funktionen im NT-Kernel auf und
k<>nnen deswegen nicht mit WINE benutzt werden. Normalerweise
empfiehlt es sich, die User-Bibliotheken von WINE zu verwenden.
lzexpand
lz32
Diese beiden Bibliotheken stellen Funktionen zum dekomprimierieren
von LZ-Archiven zur Verf<72>gung. Solche Funktionen werden im
wesentlichen von Installationsprogrammen ben<65>tigt. Die zu Windows
geh<65>renden Versionen dieser Bibliotheken benutzen einige Funktionen
aus der Kernel-Bibliothek, die in WINE zur Zeit nicht implementiert
sind. Es m<>ssen deswegen die von WINE bereitgestellten Versionen
benutzt werden.
commctrl
comctl32
Diese Bibliothek (common controls) stellt Funktionen zur Erzeugung
oft benutzter Fensterelemente, wie Werkzeugleisten oder
Statusanzeigen, zur Verf<72>gung. Es k<>nnen sowohl die Version von
WINE als auch die Windows-Version der Bibliothek benutzt werden.
commdlg
comdlg32
Hier befinden sich komplette Dialoge, die oft von
Windows-Programmen benutzt werden (Farbauswahl, Auswahl der
Schriftart, Suchen und Ersetzen usw.). Auch hier k<>nnen wahlweise
die Windows- oder WINE-Versionen benutzt werden.
shell
shell32
Die Shell-Bibliothek beinhaltet den gr<67><72>ten Teil der
Benutzerschnittstellen von Windows. Sie wird unter Windows
besonders vom Explorer (dem Dateimanager) und vielen anderen
Anwendungen benutzt, die Funktionen wie beispielsweise
Drag-and-Drop unterst<73>tzen. Prinzipiell kann sowohl die Windows-
als auch die WINE-Version benutzt werden.
-
crtdll
Dies ist die standardm<64><6D>ige C-Laufzeitbibliothek von Windows. Zur
Zeit ist die Windows-Version vollst<73>ndiger, weswegen einige
Programme mit der WINE-Version nicht richtig funktionieren.
Neben den hier genannten wichtigsten Systembibliotheken stellt WINE
eine Reihe weiterer Bibliotheken zur Verf<72>gung, beispielsweise zur
Unterst<73>tzung von Multimedia-Anwendungen. Falls eine
Windows-Installation zur Verf<72>gung steht, empfiehlt es sich in
vielen F<>llen, auszuprobieren ob ein Programm besser mit den
WINE-Versionen oder den Windows-Versionen dieser Bibliotheken
funktioniert.
In der Datei .winerc bzw. wine.conf gibt es zwei Abschnitte mit
denen bestimmt wird, welche Bibliotheken aus einer
Windows-Installation geladen werden sollen. Dar<61>berhinaus k<>nnen
diese Einstellungen beim Aufruf von WINE an der Kommandozeile
<20>berschrieben werden. Im allgemeinen empfiehlt es sich, die
Einstellungen in der Beispielversion der Konfigurationsdatei
(wine.ini) zu <20>bernehmen und diese nur dann zu ver<65>ndern, falls
bestimmte Programme mit den Voreinstellungen nicht richtig
funktionieren. Falls die Bibliotheken einer Windows-Installation
benutzt werden sollen, ist darauf zu achten, dass diese auch von
WINE gefunden werden k<>nnen. Dies setzt in der Regel voraus, dass
mit den Variablen Windows und System im allgemeinen Teil der
Konfiguration auf das Windows- bzw. das Systemverzeichnis einer
g<>ltigen Windows-Installation gezeigt wird und dass diese beiden
Verzeichnisse im Wert der Variablen Path genannt werden.
Im Abschnitt [DllDefaults] k<>nnen die folgenden beiden Einstellungen
vorgenommen werden:
EXTRA_LD_LIBRARY_PATH
Mit dieser Variablen k<>nnen, durch Doppelpunkte voneinander
getrennt, UNIX-Verzeichnisse angegeben werden, in denen WINE
zus<75>tzlich zu den normalerweise nach dynamisch ladbaren
Bibliotheken durchsuchten Verzeichnissen, nach Bibliotheken
suchen soll. Die Variable beeinflusst nur die Suche nach den
WINE-Versionen der Bibliotheken und nicht die Suche nach
Windows-Bibliotheken. Beispiel:
EXTRA_LD_LIBRARY_PATH=/home/peter/WINE_libs:/usr/local/WINE/libs.
DefaultLoadOrder
Hiermit wird bestimmt, welche Reihenfolge WINE standardm<64><6D>ig
benutzen soll, wenn versucht wird, eine Bibliothek zu laden.
Diese Reihenfolge wird durch die folgenden Schl<68>sselw<6C>rter
definiert:
native
Es soll versucht werden, die Windows-Version der
betreffenden Bibliothek zu laden.
builtin
Es soll versucht werden, die WINE-Version der
betreffenden Bibliothek zu laden.
elfdll
Elfdlls sind eine besondere Form von
Windows-Bibliotheken, welche von WINE zur Verf<72>gung
gestellt werden. Sie sind urspr<70>nglich geplant worden,
um die eingebauten Bibliotheken abzul<75>sen, allerdings
haben die eingebauten Bibliotheken mit der Zeit viele
der f<>r Elfdlls geplanten Funktionen bekommen, so dass
diese Form von Bibliotheken zur Zeit keine besondere
Bedeutung hat.
so
In einigen F<>llen gibt es von einer Bibliothek Linux-
und Windows-Versionen, die sich sowohl hinsichtlich
ihrer Funktionalit<69>t als auch hinsichtlich der
aufrufbaren Funktionen in der Bibliothek nicht
unterscheiden. Falls ein Windows-Programm die
Windows-Version einer solchen Bibliothek laden will,
kann WINE versuchen, an Stelle dessen die Linux-Version
zu laden und die Funktionen dieser Version an Stelle
der in der Windows-Version aufrufen. Mit dem
Schl<68>sselwort so kann dieses Verhalten hervorgerufen
werden.
Durch die Reihenfolge, mit der diese Schl<68>sselw<6C>rter der
Variablen DefaultLoadOrder zugeordnet werden, wird
festgelegt, in welcher Reihenfolge WINE die einzelnen
Strategien benutzt. Wurde beispielsweise DefaultLoadOrder =
native, builtin, so angegeben, so versucht WINE, wenn eine
Bibliothek geladen werden muss, zun<75>chst die
Windows-Version zu laden. Wenn dies nicht funktioniert (in
der Regel, weil die Bibliothek nicht vorhanden ist oder
nicht gefunden werden kann), wird versucht, die WINE-Version
der Bibliothek zu verwenden und falls auch eine solche nicht
vorhanden ist, wird versucht, direkt die UNIX-Version der
entsprechenden Bibliothek zu laden.
Im Abschnitt [DllOverrides] l<>sst sich das im vorherigen Abschnitt
spezifizierte Verhalten f<>r einzelne Bibliotheken wieder
<20>berschreiben. W<>hrend es n<>mlich im allgemeinen eine gute
Strategie ist, zun<75>chst zu versuchen, die Windows-Versionen von
Bibliotheken zu laden, darf dies (wie oben beschrieben) bei
bestimmten Bibliotheken auf keinen Fall geschehen und es m<>ssen in
jedem Fall die WINE-Versionen benutzt werden. Als Variablen werden
in diesem Abschnitt die Bibliotheken genannt, f<>r die eine
spezielle Reihenfolge gelten soll. Hinter dem Gleichheitszeichen
wird dann die f<>r diese Bibliotheken gew<65>nschte Reihenfolge in der
gleichen Form angegeben, wie es im vorherigen Abschnitt beschrieben
ist. Beispiel:
[DllOverrides]
krnl386, kernel32 = builtin
gdi, gdi32 = builtin
user, user32 = builtin
shell,shell32 = native, builtin
7.5 Konfiguration des X11 Graphiktreibers
Der X11 Graphiktreiber stellt die Schnittstelle zwischen den
Graphikfunktionen der Windows-Betriebssysteme und dem X Window
System dar. Er erm<72>glicht es also, dass Windows-Programme unter
WINE das X Window System <20>hnlich benutzen k<>nnen, wie sie unter
echtem Windows eine normale Graphikkarte benutzen. Das Verhalten
des Treibers wird im Abschnitt x11drv der Konfigurationsdatei
eingestellt. Dort stehen die folgenden Variablen zur Verf<72>gung:
PrivateColorMap
Wenn diese Variable auf true gesetzt ist, verwendet WINE
eine eigene Farbpalette. Bei X-Servern die mit eine
Farbtiefen von 256 Farben (8bpp) oder weniger betrieben
werden, hat das zur Folge, dass andere Fenster u.U. in
falschen Farben dargestellt werden, wenn zu WINE geh<65>rende
Fenster in den Vordergrund geschaltet sind. Daf<61>r kann WINE
jedoch Farben besser darstellen als ohne diese
Einstellung. Falls der X Server mit einer Farbtiefe von mehr
als 256 Farben betrieben wird, ist die Einstellung
wirkungslos.
AllocSystemColors
Wenn WINE keine eigene Farbpalette verwendet, kann hier
angegeben werden, wieviele Farben von der systemweit
geteilten Palette maximal von WINE benutzt werden
d<>rfen. Der h<>chstm<74>gliche Wert ist hier 256, weil bei
besseren Farbtiefen keine Palette benutzt wird. Beispiel:
AllocSystemColors = 100.
PerfectGraphics
An einigen Stellen hat WINE die M<>glichkeit,
Graphikoperationen entweder so durchzuf<75>hren, dass sie
besonders schnell sind oder so, dass sie besonders korrekt
ausgef<65>hrt werden. Wenn diese Variable auf den Wert true
gesetzt wird, wird der Genauigkeit Vorzug gegeben. Beispiel:
PerfectGraphics = false.
UseDGA
DGA (Direct Graphics Access) ist eine Erweiterung von
XFree86, welche den direkten Zugriff auf den Speicher der
Graphikkarte erm<72>glicht. Dadurch lassen sich
Graphikoperationen wesentlich schneller durchf<68>hren als
normalerweise. Die DirectDraw-Bibliothek (DirectX) von WINE
kann diese Erweiterung benutzen, wodurch sich insbesondere
Spiele mit einer <20>hnlichen Geschwindigkeit wie unter Windows
ausf<73>hren lassen. Weil DGA den direkten Hardwarezugriff
erfordert, sind dazu in der Regel Administratorrechte
erforderlich. Die Verwendung von DGA wird mit UseDGA = true
ein- und mit UseDGA = false ausgeschaltet.
Achtung:
Anwendungen, die DirectDraw benutzen, versuchen
normalerweise den Bildschirm in eine bestimmte Aufl<66>sung und
Farbtiefe zu schalten. WINE kann die Aufl<66>sung zwar
ver<65>ndern, falls sich in der Datei XF86Config eine
Definition f<>r den angeforderten Modus befindet, weil das X
Window System jedoch nicht den Wechsel der Farbtiefe
unterst<73>tzt, ist es oft erforderlich, den X-Server in der
ben<65>tigten Farbtiefe zu starten, bevor WINE gestartet wird.
UseXShm
Hierbei handelt es sich um eine andere Erweiterung des X
Window Systems, die schnellere Graphikoperationen
erm<72>glicht. Beispiel: UseXShm = true.
DXGrab
Diese Option bewirkt, dass der Mauszeiger - bei der
Verwendung von DirectDraw (DirectX) - das von DirectDraw
gesteuerte Fenster nicht verlassen kann. Dies ist notwendig,
um einige Programme richtig bedienen zu k<>nnen, allerdings
wird dadurch verhindert, mit der Maus in ein anderes Fenster
zu schalten, beispielsweise um WINE zu beenden. Beispiel:
DXGrab = false.
ScreenDepth
Einige X-Server unterst<73>tzen unterschiedliche Farbtiefen auf
dem selben Bildschirm. Mit dieser Variable kann ausgew<65>hlt
werden, welche Farbtiefe in einem solchen Fall benutzt
werden soll.
Managed
WINE kann von Windows-Programmen dargestellte Fenster
u.a. unabh<62>ngig vom eingesetzten Window-Manager anzeigen
oder sie unter die Kontrolle des Window-Managers
stellen. Das zweite Verfahren bietet eine bessere
Integration von Windows-Programmen in die Arbeitsumgebung
unter Linux, weil die Fenster dann genauso wie die von
Linux-Programmen erscheinen und zu steuern sind. Welcher der
verf<72>gbaren Anzeigemodi verwendet werden soll, wird
normalerweise an der Kommandozeile beim Aufruf von WINE
angegeben. Durch diese Variable in der Konfigurationsdatei
l<>sst sich festlegen, ob von WINE gesteuerte Fenster
standardm<64><6D>ig den Window-Manager verwenden sollen (Managed =
true).
DesktopDoubleBuffered
Diese Option sollte auf den Wert true gesetzt werden, wenn
mit WINE Programme benutzt werden, die OpenGL
benutzen. Hierdurch wird die Darstellung solcher Anwendungen
verbessert.
7.6 Konfiguration der zu verwendenden Schriftarten
Der X11-Graphiktreiber x11drv verwendet zur Darstellung von Schrift
die Schriftarten, die dem X-Server direkt oder <20>ber einen Fontserver
zur Verf<72>gung stehen. Eine Reihe von Windows-Anwendungen erwarten
allerdings ganz bestimmte Schriften, die unter Windows in der Regel
verf<72>gbar sind und viele Anwendungen werden anders als unter Windows
dargestellt, falls andere Schriftarten benutzt werden m<>ssen.
Windows verwendet normalerweise zwei unterschiedliche Typen von
Schriftarten, n<>mlich so genannten TrueType-Schriften und einfache
Bitmap-Schriftarten. Beide Schrifttypen k<>nnen von XFree86 in der
Versionsfamilie 3.x standardm<64><6D>ig nicht zur Verf<72>gung gestellt
werden. Allerdings ist es m<>glich, Windows-Bitmap-Schriftarten in
ein Format zu <20>bersetzen, welches von XFree86 eingebunden werden
kann. TrueType-Schriftarten k<>nnen <20>ber spezielle
TrueType-Fontserver, die mittlerweile in den meisten Distributionen
enthalten sind, eingebunden werden. Falls eine Windows-Installation
zur Verf<72>gung steht, empfiehlt es sich im allgemeinen, die dort
vorhandenen Schriftarten auch unter Linux einzubinden, damit unter
WINE ausgef<65>hrte Windows-Anwendungen die erwarteten Schriftarten
vorfinden. Wenn WINE ohne Windows-Schriftarten benutzt wird,
versucht das Programm, die angeforderten Schriften durch die
Schriften des X Window Systems zu ersetzen, wodurch sich
Ver<65>nderungen im Erscheinungsbild der Anwendungen ergeben k<>nnen.
7.6.1 Einbinden von Bitmap-Schriften
Windows Bitmap-Schriftarten befinden sich normalerweise im
Unterverzeichnis fonts des Windows-Verzeichnisses und haben die
Dateinamensendung .fon. Es ist aber auch m<>glich, dass sie in
ausf<73>hrbaren Dateien oder in Bibliotheken enthalten sind. Im
Unterverzeichnis tools des Basisverzeichnisses mit dem
WINE-Quellcode befindet sich das Programm fnt2bdf, mit dem die
Fonts aus diesen Dateien extrahiert und in das Bitmap Distribution
Format (.bdf) umgewandelt werden k<>nnen. Dazu ist das Programm
folgendermassen aufzurufen:
fnt2bdf -o Basisname Schriftdatei
Dabei ist f<>r Schriftdatei der Name der Datei anzugeben, in der
sich die zu extrahierenden Schriften befinden und f<>r Basisname
eine Bezeichnung, mit der die Namen der zu extrahierenden Dateien
beginnen sollen. Es ist zu beachten, dass sich in der Regel in
einer Windows-Schriftartendatei mehrere Schriftarten befinden, die
in unterschiedliche Dateien extrahiert werden. Bei einigen
Schriftarten ist es notwendig, dem Programm mitzuteilen, wie die
Schriftarten kodiert sind. Hierzu ist die Option -c zu verwenden
und dahinter die Bezeichnung der Kodierung anzugeben. Eine
<20>bersicht <20>ber alle von dem Programm unterst<73>tzten Optionen wird
ausgegeben, wenn es ohne Parameter aufgerufen wird. Um also
beispielsweise die Bitmap-Schriften aus der Datei SERIFF.FON in
Dateien zu extrahieren, deren Namen mit der Bezeichnung seriff
beginnen, w<>re das Programm so aufzurufen:
fnt2bdf -o seriff SERIFF.FON
Es werden dann eine Reihe von Dateien mit unterschiedlichen Fonts
aus der Originaldatei erzeugt. Im n<>chsten Schritt sind diese
Dateien mit dem Programm bdftopcf(1) in das so genannte Portable
Compiled Format zu <20>bersetzen. Dieses Programm sollte Bestandteil
jeder X11-Installation sein und ist durch eine Manualseite
dokumentiert. Um beispielsweise die Datei seriff_r400-23.bdf zu
<20>bersetzen und das Ergebnis in die Datei seriff_r400-23.pcf zu
schreiben, k<>nnte das Programm so aufgerufen werden:
bdftopcf -o seriff_r400-23.pcf seriff_r400-23.bdf
Die auf diese Weise erzeugten Dateien k<>nnen nun in eines der, von
dem X-Server oder einem Fontserver benutzten, Font-Verzeichnis
kopiert werden. In diesem Verzeichnis ist danach der Befehl
mkfontdir aufzurufen, damit der dort befindlich Fontindex neu
erzeugt wird. Bevor die Schriften dann tats<74>chlich unter X zur
Verf<72>gung stehen und damit von WINE benutzt werden k<>nnen, muss X
neu gestartet oder der folgende Befehl an der Kommandozeile
eingegeben werden:
xset fp +rehash
Im Unterverzeichnis tools des WINE-Quellcodeverzeichnisses befindet
sich ein Shellskript mit dem Namen font_convert.sh, welches die
oben genannten Schritte automatisch durchf<68>hrt und alle unterhalb
eines Verzeichnisses befindlichen Bitmap-Schriftarten automatisch
konvertiert und installiert.
7.6.2 Einbinden von TrueType-Schriften
Wie bereits erw<72>hnt, k<>nnen die X-Server von XFree86 in der
Versionsfamilie 3.x keine TrueType-Schriften darstellen. Seit
XFree86 4.0 hat sich dies allerdings ge<67>ndert, so dass solche
Schriften zuk<75>nftig problemlos unter X - und damit auch mit WINE -
zur Verf<72>gung gestellt werden k<>nnen. Leider k<>nnen <20>ber das
X-Font-Protokoll nicht alle von manchen Windows-Programmen
ben<65>tigten Informationen <20>ber TrueType-Fonts dargestellt werden, so
dass manche Windows-Programme auch dann noch nicht richtig
funktionieren, wenn die ben<65>tigten Fonts zur Verf<72>gung gestellt
worden sind. Mit XFree86 3.x bietet sich der Einsatz eines
TrueType-Fontservers an. Zur Zeit stehen drei unterschiedliche
solcher Programme zur Verf<72>gung, n<>mlich: xfs-xtt (Debian-Paket:
xfs-xtt), xfstt (Debian-Paket xfstt) und xfsft (im Internet unter
der Adresse http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/
verf<72>gbar).
Der Autor hat mit dem Programm xfsft die besten Ergebnisse erzielt.
Dieser Server l<>sst sich leicht konfigurieren und ist kompatibel zu
herk<72>mmlichen Fontservern, so dass nicht zwei verschiedene
Fontserver auf einem Rechner ausgef<65>hrt werden m<>ssen. Dieses
Programm diente auch als Grundlage f<>r die Integration der
TrueType-Unterst<73>tzung in XFree86 4.0.
Um die von einem Fontserver zur Verf<72>gung gestellten Schriften zu
verwenden, muss dem X-Server die Adresse des Fontservers mitgeteilt
werden. Dies kann entweder in der Datei /etc/X11/XF86Config oder
durch Eingabe dieses Befehls geschehen:
xset fp+ tcp/localhost:7100
Dabei muss localhost u.U. gegen den Namen des Rechners ausgetauscht
werden, auf dem der Fontserver ausgef<65>hrt werden und 7100 durch den
Port, der vom Fontserver benutzt wird. Wenn der Fontserver auf dem
selben Rechner ausgef<65>hrt wird wie der X-Server, dann k<>nnen zur
Kommunikation zwischen X-Server und Fontserver auch
UNIX-Domain-Sockets benutzt werden. Der entsprechende Befehl k<>nnte
dann folgenderma<6D>en aussehen:
xset fp+ unix/:7100
7.6.3 Font-Einstellungen in der WINEs Konfigurationsdatei
In der Konfigurationsdatei .winerc bzw. wine.conf stehen die
folgenden Variablen zur Verf<72>gung, mit denen WINEs Umgang mit
Schriftarten beeinflusst werden kann:
Resolution
Unter Windows k<>nnen Programme die Gr<47><72>e eines zu
verwendenden Fonts in Punkten (an Stelle von Pixeln)
angeben. Damit die Schriftart dann in der richtigen Gr<47><72>e
angezeigt werden kann, muss die tats<74>chliche Gr<47><72>e des
Bildschirms bekannt sein, was unter X nicht unbedingt der
Fall ist. Mit der Variable Resolution kann deswegen justiert
werden, welche Schriftgr<67><72>en in solchen F<>llen von WINE
ausgew<65>hlt werden. Der Standardwert ist 96, sinnvolle Werte
liegen zwischen 60 und 120. Beispiel: Resolution = 100.
Default
Mit dieser Variable wird angegeben, welche Schriftart WINE
als Standard verwenden soll. Die dabei anzugebende
Zeichenkette besteht aus der Herstellerbezeichnung der zu
verwendenden Schriftart und ihrem Namen, diese Bezeichnungen
werden durch ein Minuszeichen miteinander verbunden,
au<61>erdem muss sich zu Beginn und am Ende der Zeichenkette
ein Minuszeichen befinden. Die unter X11 verf<72>gbaren Fonts
k<>nnen beispielsweise mit den Programmen xfontsel(1) oder
xlsfonts(1) ausgew<65>hlt werden.
Beispiel: Default = -adobe-times-
DefaultFixed
Hiermit wird festgelegt, welchen Font WINE als
standardm<64><6D>ige Schriftart mit gleichm<68><6D>iger Buchstabenbreite
verwenden soll. Der Name der gew<65>nschten Schrift ist wie
bei der Variablen Default anzugeben. Beispiel:
DefaultFixed = -sony-fixed-
DefaultSerif
Hiermit wird festgelegt, welchen Font WINE als
standardm<64><6D>ige Schriftart mit Serifen verwenden
soll. Beispiel: DefaultSerif = -adobe-times-
DefaultSansSerif
Hiermit wird bestimmt, welchen Font WINE als standardm<64><6D>ige
Schriftart ohne Serifen verwenden soll. Beispiel:
DefaultSansSerif = -adobe-helvetica-
Fontmetric
Wenn WINE das erste Mal gestartet wird, fragt es vom
X-Server die Eigenschaften der verf<72>gbaren Fonts ab. Weil
diese Operation recht zeitaufwendig ist, wird das Ergebnis
der Abfrage in einer Datei im Heimatverzeichnis des
betreffenden Benutzers gespeichert. Die Abfrage braucht dann
bei einem sp<73>teren Aufruf des Programms nur ausgef<65>hrt zu
werden, falls sich die verf<72>gbaren Fonts ge<67>ndert haben. Mit
dieser Variablen kann angegeben werden, in welcher Datei die
Fontdaten zwischengespeichert werden sollen. Dadurch l<>sst
sich beispielsweise vermeiden, dass die Abfrage f<>r jeden
Benutzer erneut ausgef<65>hrt werden muss. Beispiel:
Fontmetric=/var/lib/WINE/font.cache.
Alias
Wie weiter oben bereits angesprochen, kann es vorkommen,
dass Windows-Anwendungen bestimmte Schriftarten benutzen
wollen, die vom X-Server nicht zur Verf<72>gung gestellt
werden. Mit der Variable Alias k<>nnen solchen Fontnamen
anderen, unter X verf<72>gbaren Schriftarten zugeordnet
werden. Werte, die dieser Variablen zugeordnet werden,
bestehen aus drei Elementen, die durch Kommata voneinander
zu trennen sind. Das erste Element ist der Name der zu
ersetzenden Schriftart, das zweite Element der Name der X
Schriftart, in der Form, wie sie auch bei der Definition der
Variablen Default anzugeben ist. Als drittes Element kann
optional das Schl<68>sselwort subst angegeben werden. Dieses
Schl<68>sselwort bewirkt, dass durch die Aliasdefinition eine
bereits vorhandene Definition (die von WINE automatisch
erstellt wurde) <20>berschrieben wird. Weil es m<>glich ist,
mehrere Alias-Definitionen vorzunehmen, muss der
Variablenbezeichnung Alias jeweils eine Zahl nachgestellt
werden, mit der angegeben wird, um die wievielte
Alias-Definition es sich handelt. Dabei ist mit der Zahl
Null zu beginnen, es darf keine Zahl ausgelassen
werden. Beispiel: Alias0 = System, --international-, subst
7.7 Konfiguration von Schnittstellen und Hardwarezugriff
WINE kann Anwendungen den direkten Zugriff auf serielle und
parallele Schnittstellen sowie auf weitere beliebige Ein- und
Ausgabeadressen gestatten. Grunds<64>tzlich ist dabei zu bedenken,
dass der betreffende WINE-Prozess mit ausreichenden Privilegien
ausgestattet sein muss, damit ein solcher Zugriff tats<74>chlich
m<>glich wird. Wird WINE mit gew<65>hnlichen Benutzerrechten (und nicht
mit den Privilegien des Administrators) ausgef<65>hrt, bedeutet dies
in der Regel, dass die Zugriffsrechte auf die Ger<65>tedateien, welche
Ger<65>te repr<70>sentieren, auf die Windows-Programmen der Zugriff
gestattet werden soll, <20>berpr<70>ft werden m<>ssen. Der direkte Zugriff
auf Ein- und Ausgabeadressen ist unter Linux ausschlie<69>lich dem
Administrator gestattet.
Zur Konfiguration der seriellen Schnittstellen dient der Abschnitt
[serialports] in der Konfigurationsdatei. Die einzelnen Variablen in
diesem Abschnitt bezeichnen die seriellen Schnittstellen so wie es
unter DOS und Windows <20>blich ist (Com1, Com2 usw.). Als Wert wird
diesen Variablen der Name der Ger<65>tedatei <20>bergeben, welche die
entsprechende Schnittstelle unter Linux repr<70>sentiert. Falls also
Windows-Anwendungen unter WINE <20>ber die Schnittstelle Com1 auf das
Ger<65>t zugreifen sollen, dass unter Linux durch die Ger<65>tedatei
/dev/ttyS0 repr<70>sentiert wird, so muss in der Konfigurationsdatei
der folgende Abschnitt zu finden sein:
[serialports]
Com1=/dev/ttyS0
Die Konfiguration paralleler Schnittstellen erfolgt analog zur
Konfiguration serieller. Der Name des entsprechenden Abschnitts
lautet [parallelports] und die Namen paralleler Schnittstellen
unter DOS und Windows lauten Lpt1, lpt2 usw. Wenn also von
Windows-Programmen unter WINE <20>ber den Namen Lpt1 auf die parallele
Schnittstelle zugegriffen werden soll, welche unter Linux durch die
Ger<65>tedatei /dev/lp0 repr<70>sentiert wird, so w<>re in die
Konfigurationsdatei dieser Abschnitt aufzunehmen.
[parallelports]
Lpt1=/dev/lp0
Um den Zugriff auf bestimmte Ein- und Ausgageadressen zu erm<72>glichen
sind die gew<65>nschten Adressen in hexadezimaler Schreibweise im
Abschnitt [ports] anzugeben. Als Adressen lassen sich entweder
einzelne Adressen (Beispiel: 0x779) oder Adressbereiche angeben. Bei
Adressbereichen werden die untere und obere Adresse des gew<65>nschten
Bereichs, verbunden durch einen Bindestrich angegeben (Beispiel:
0x280-0x2a0). Wenn mehrere Adressen oder Adressbereiche konfiguriert
werden sollen, sind diese hintereinander - durch Kommata getrennt -
anzugeben. Adressen, von denen gelesen werden soll, sind der Variablen
read zuzuordnen und solche, auf die geschrieben werden soll, der
Variablen write. Falls auf eine bestimmte Adresse sowohl lesend als
auch schreibend zugegriffen werden soll, ist sie beiden Variablen
zuzuordnen. Beispiel:
[ports]
read=0x378,0x379,0x220-0x2a0
write=0x379,0x220-0x2a0
7.7.1 Zugriff auf SCSI-Ger<65>te
WINE erm<72>glicht auch den direkten Zugriff auf SCSI-Ger<65>te (<28>ber die
ASPI-Schnittstelle). Hierzu sind keine speziellen Angaben in der
Konfiguration notwendig, allerdings muss der Kernel des Systems so
konfiguriert worden sein, dass er die Unterst<73>tzung f<>r generischen
SCSI-Zugriff enth<74>lt. Au<41>erdem m<>ssen die Ger<65>tedateien, welche die
generischen SCSI-Ger<65>te repr<70>sentieren (normalerweise /dev/sg0,
/dev/sg1 usw.) mit ausreichenden Rechten f<>r den Zugriff
ausgestattet sein.
7.8 Konfiguration der Windows-Systemregistratur
Windows-Betriebssysteme stellen eine Datenbank zur Verf<72>gung, in
der Programme u.a. Konfigurationsdaten ablegen und sp<73>ter wieder
auslesen k<>nnen. Diese so genannte Registratur wird von WINE
ebenfalls bereitgestellt. WINE ist ferner in der Lage, die
Registratur einer bestehenden Windows-Installation zu importieren,
damit den mit WINE ausgef<65>hrten Programmen alle Daten zur Verf<72>gung
stehen, die auch unter Windows verf<72>gbar sind. Dies ist
insbesondere dann von Bedeutung, wenn Programme unter Windows
installiert worden sind und unter WINE ausgef<65>hrt werden. Es ist zu
beachten, dass WINE die Registratur einer bestehenden
Windows-Installation niemals ver<65>ndert. Falls Programme also unter
WINE Daten in die Registratur schreiben, stehen diese unter Windows
nicht zur Verf<72>gung. WINE speichert die Registratur vielmehr in
eigenen Dateien, welche sich <20>blicherweise unterhalb des
Heimatverzeichnisses des betreffenden Benutzers befinden. Neben den
benutzerspezifischen Registraturdaten k<>nnen vom Administrator
systemweit g<>ltige Dateien bereit gestellt werden. Diese befinden
sich <20>blicherweise in dem gleichen Verzeichnis wie die systemweit
g<>ltige Konfigurationsdatei, also in /etc oder in /usr/local/etc,
wenn WINE mit den Standardeinstellungen <20>bersetzt wurde. Im
Abschnitt [registry] der Konfigurationsdatei stehen die folgenden
Variablen zur Verf<72>gung, mit denen u.a. bestimmt werden kann, ob
eine bestehenden Registratur importiert werden soll und wo WINE die
eigene Registratur ablegen soll.
LoadGlobalRegistryFiles
Wenn diese Variable auf den Wert true gesetzt ist, liest
WINE die systemweit g<>ltigen Registraturdaten ein. Dies ist
die Standardeinstellung. Beispiel: LoadGlobalRegistryFiles =
true
LoadHomeRegistryFiles
Wenn diese Variable auf den Wert true gesetzt ist, liest
WINE die Registraturdaten aus dem Verzeichnis .wine im
Heimatverzeichnis des aufrufenden Benutzers ein. Die
Registraturdaten des Benutzers werden nach den systemweit
g<>ltigen Daten geladen, so dass Benutzer die
Voreinstellungen aus der globalen Registratur mit eigenen
Werten <20>berschreiben k<>nnen. Beispiel:
LoadHomeRegistryFiles = true
LoadWindowsRegistryFiles
Mit dieser Variablen wird bestimmt, ob die Registratur einer
bestehenden Windows-Installation geladen werden soll. Wenn
die Variable auf den Wert true gesetzt ist, stellt WINE
selbstst<73>ndig fest, um welche Version von Windows es sich
bei der bestehenden Installation handelt und liest die
Registraturdaten der Installation ein, Es ist zu beachten,
dass dies nur funktioniert, wenn das Windows- und das
Systemverzeichnis im allgemeinen Teil der
Konfigurationsdatei richtig angegeben worden sind und der
bestehenden Installation entsprechen. Au<41>erdem ist es
u.U. notwendig, die Variable Profile im allgemeinen Teil
richtig zu setzen. Beispiel: LoadWindowsRegistryFiles = true.
WriteToHomeRegistryFiles
Wird diese Variable auf den Wert true gesetzt, versucht WINE
alle <20>nderungen, die w<>hrend der Laufzeit von WINE an der
Registratur vorgenommen werden in die Registraturdateien im
Verzeichnis .wine des aufrufenden Benutzers zu
schreiben. Dies ist in der Regel notwendig, damit
Windows-Programme (insbesondere Installationsprogramme)
<20>nderungen an der Konfiguration abspeichern
k<>nnen. Beispiel: WriteToHomeRegistryFiles = true.
PeriodicSave
Wenn Ver<65>nderungen an der Registratur von WINE gespeichert
werden sollen, geschieht dies normalerweise automatisch,
w<>hrend WINE beendet wird. Allerdings werden die <20>nderungen
dann nicht gespeichert, wenn WINE aufgrund eines Fehlers
nicht korrekt beendet werden kann. Deswegen ist es m<>glich,
mit dieser Variablen anzugeben, in welchem Zeitintervall das
Programm die Registratur automatisch sichern soll. Die
dieser Variablen <20>bergebene Zahl wird als Zeitintervall in
Sekunden interpretiert. Damit die Registratur also
beispielsweise alle 10 Minuten automatisch abgespeichert
wird, w<>re diese Variable so zu setzen: PeriodicSave = 600.
SaveOnlyUpdatedKeys
Mit dieser Variablen kann bestimmt werden, ob WINE lediglich
solche Teile der Registratur sichern soll, die sich w<>hrend
der Laufzeit ver<65>ndert haben oder ob immer die gesamte
Registratur gespeichert werden soll. Das folgende Beispiel
speichert die Registratur komplett:
SaveOnlyUpdatedKeys=false.
Hinweis:
Weil das Importieren einer gro<72>en Windows-Registratur ein relativ
zeitaufwendiger Vorgang ist, empfiehlt es sich, die
Windows-Registratur nur beim ersten Start von WINE zu importieren
(LoadWindowsRegistryFiles=true) und diese dann komplett von WINE
speichern zu lassen (SaveOnleUpdatedKeys=false). Danach liegt die
Registratur vollst<73>ndig in WINEs eigenem Format vor, so dass bei
sp<73>teren Starts von WINE auf den Import der Windows-Registratur
verzichtet werden kann (LoadWindowsRegistryFiles=false).
7.9 Einstellung des Look and Feel
Im Abschnitt Tweak.Layout der Registratur l<>sst sich durch die
Variable WINELook bestimmen, welches Look and Feel von Windows
durch WINE nachempfunden werden soll. Der Wert Win31 bewirkt, dass
WINE alle Fensterelemente in dem Erscheinungsbild erzeugt, wie es
von Windows 3.11 bekannt ist. Analog dazu bewirken die Werte Win95
und Win98 ein moderneres Erscheinungsbild. Beispiel:
[Tweak.Layout]
WINELook=Win98
7.10 Konfiguration der Windows-Console
Im Gegensatz 16-Bit-Windows-Versionen ist es mit dem Win32 API wie
unter UNIX m<>glich, Programme f<>r den Textmodus zu erstellen, die
unter Windows normalerweise in einem so genannten "MS-DOS-Fenster"
ausgef<65>hrt werden (obwohl diese Programme nicht viel mit MS-DOS zu
tun haben). Unter WINE verwenden solche Programme standardm<64><6D>ig die
Standardeingabe und -Ausgabe des Terminals, von dem aus WINE
gestartet wurde. Im Abschnitt [Console] der Konfigurationsdatei ist
es m<>glich die Eigenschaften der Konsole f<>r Windows-Programme
n<>her zu bestimmen.
Drivers
Hermit wird festgelegt, wie die Konsole zur Verf<72>gung
gestellt werden soll. WINE kann dazu das mit dem
WINE-Prozess verbundene Terminal verwenden oder f<>r jedes
Windows-Programm, welches eine neue Konsole anfordert ein
neues Terminalfenster (wie z.B. xterm) starten. Im
allgemeinen ist es zu empfehlen, f<>r jede Konsole ein
eigenes Terminalfenster zu verwenden, weil es zu
unerw<72>nschten Nebeneffekten kommen kann, wenn verschiedene
Windows-Prozesse und WINE selbst das selbe Terminal
verwenden. Es ist ferner m<>glich, die ncurses-Bibliothek zu
benutzen, um bestimmte Eigenschaften, wie die Darstellung
unterschiedlicher Farben, zu benutzen. Der Variablen Drivers
kann zur Zeit eine Kombination aus den folgenden
Schl<68>sselw<6C>rtern <20>bergeben werden: tty, xterm und
ncurses. Wenn mehrere diese Schl<68>sselw<6C>rter benutzt werden,
sind diese durch das Plus-Zeichen voneinander zu
trennen. Die Angabe tty bewirkt, dass WINE das Terminal f<>r
die Konsole verwendet, mit welchem der WINE-Prozess
verbunden ist. Durch die Angabe xterm wird ein neues
Terminalfenster ge<67>ffnet, wenn ein Windows-Programm eine
neue Konsole anfordert. Die Angabe ncurses bewirkt, dass die
ncurses-Bibliothek benutzt wird. Dies funktioniert nur, wenn
die Unterst<73>tzung daf<61>r beim <20>bersetzen des Programms
aktiviert wurde. Beispiel: Drivers=ncurses+xterm
XtermProg
Hiermit l<>sst sich angeben, welches Programm aufgerufen
werden soll, um die Konsole in einem eigenen Fenster
darzustellen (z.B. bei Drivers=xterm). Es lassen sich alle
Terminalemulationsprogramme verwenden, welche die von xterm
her bekannten Kommandozeilenargumente verstehen. Beispiel:
XtermProg=wterm.
InitialRows
Mit der Variablen wird angegeben, wieviele Zeilen die
Konsole nach ihrem Start haben soll. Beispiel:
InitialRows=24.
InitialColumns
Mit der Variablen wird angegeben, wieviele Spalten die
Konsole nach ihrem Start haben soll. Beispiel:
InitialColumns=80.
TerminalType
Hiermit l<>sst sich festlegen, von welchem Terminaltyp die
ncurses-Bibliothek ausgehen soll. Typische Werte sind xterm
oder linux.
7.11 Die Zwischenablage
Das Konzept der Zwischenablage unterscheidet sich zwischen Windows
und dem X Window System etwas. Um beispielsweise einen Text in die
Zwischenablage zu stellen, wird dieser unter Windows normalerweise
zun<75>chst markiert und dann <20>ber einen Men<65>befehl in die
Zwischenablage kopiert oder verschoben. Unter X stehen mindestens
zwei Typen von Zwischenablage zur Verf<72>gung. Nachdem ein Text dort
markiert worden ist, steht er als so genannte prim<69>re Auswahl zur
Verf<72>gung; er kann dann sofort in andere Anwendungen eingef<65>gt
werden (etwa durch Bet<65>tigung der mittleren Maustaste). Die
Zwischenablage ist eine weitere Auswahl in die Texte oder andere
Daten von vielen X-Anwendungen aus kopiert und von dort aus wieder
eingef<65>gt werden k<>nnen. Im Abschnitt [clipboard] der
Konfigurationsdatei l<>sst sich bestimmen, wie die
Windows-Zwischenablage mit der Zwischenablage des X Window Systems
interagiert.
ClearAllSelections
Wenn diese Variable auf true gesetzt ist, wird der Inhalt
der Windows-Zwischenablage gel<65>scht und durch den Inhalt der
Zwischenablage des X Window Systems ersetzt, falls in einer
anderen X Anwendung etwas in die prim<69>re Auswahl gestellt
wird. Wird bei Verwendung dieser Einstellung also zun<75>chst
etwas mit einem Windows-Programm in die Zwischenablage
gestellt und danach mit der Maus ein Text in einer X
Anwendung markiert, so geht der urspr<70>ngliche Inhalt der
Windows-Zwischenablage verloren und es steht dort der mit
der Maus markierte Text zur Verf<72>gung. Falls die Variable
auf false gesetzt ist, bleibt der Inhalt der Zwischenablage
durch die Ver<65>nderung der prim<69>ren Auswahl unber<65>hrt. Um
dann beispielsweise einen Text von XEmacs nach Word zu
kopieren, reicht es nicht aus, den Text in XEmacs zu
markieren, sondern er muss dort explizit in die
Zwischenablage kopiert werden, falls sich dort vorher eine
Auswahl befand, die von einer Windows-Anwendung aus
vorgenommen wurde. Beispiel: ClearAllSelections=true
PersistantSelection
Nachdem WINE beendet worden ist, kann der Inhalt der
Zwischenablage anderen X Programmen normalerweise nicht mehr
zur Verf<72>gung gestellt werden. Wenn diese Variable auf true
gesetzt ist, startet WINE deswegen ein kleines
Hintergrundprogramm (wineclipsrv) welches den Inhalt der
Zwischenablage so lange verf<72>gbar h<>lt, bis dieser durch ein
anderes Programm ersetzt wird und sich dann
beendet. Beispiel: PersistantSelection=true
7.12 Konfiguration des PostScript-Druckertreibers
WINE kann zwei Typen von Druckertreibern verwenden, n<>mlich echte
16bit Windows-Druckertreiber, wie Sie von Windows 3.11 oder Windows
95/98 benutzt werden oder einen eigenen PostScript- Druckertreiber,
mit dem sich aus den meisten Windows-Anwendungen heraus im
PostScript-Format drucken l<>sst. Diese PostScript-Ausgabe kann dann
<20>ber die Spooler-Software des Systems (normalerweise lpr/lpd) auf
einen direkt angeschlossenen oder fernen Drucker ausgegeben werden.
Hinweise zur Verwendung von 16bit Windows-Druckertreiber finden
sich u.a. in der Datei printing im Unterverzeichnis documentation
des WINE-Quellcodeverzeichnisses. Im folgenden soll lediglich auf
die Konfiguration des eingebauten PostScript-Druckertreibers
eingegangen werden.
Zun<75>chst ist das Vorhandensein des Druckertreibers anzumelden. Dazu
sind in der Datei win.ini im Windows-Verzeichnis die folgenden
<20>nderungen vorzunehmen:
[windows]
device=WINE PostScript Driver,WINEPS,LPT1:
[devices]
WINE PostScript Driver=WINEPS,LPT1:
Falls Sie WINE ohne eine bestehende Windows-Installation verwenden,
kann es sein, dass die Datei win.ini noch nicht existiert. In
diesem Fall kann die Datei neu angelegt und die oben gezeigten
Zeilen dort eingetragen werden. Falls die Datei bereits vorhanden
ist, m<>ssen die Abschnitte [devices] und [windows] in der Datei
lokalisiert und um die oben gezeigten Zeilen erg<72>nzt
werden. Keinesfalls sollten die Abschnitte devices oder windows
mehrmals in der Datei vorhanden sein.
Damit auch von 32bit Programmen aus gedruckt werden kann, ist es
notwendig, einige Eintr<74>ge in der Registratur vorzunehmen. Diese
Eintr<74>ge sind in der Datei psdrv.reg im Unterverzeichnis
documentation des WINE-Quellcodeverzeichnisses vorhanden und lassen
sich mit dem Programm regapi, welches sich im Unterverzeichnis
programs/regapi des Quellcodeverzeichnisses befindet,
importieren. Falls noch nicht geschehen ist regapi dazu zun<75>chst zu
<20>bersetzen. Zu diesem Zweck ist in das Verzeichnis programs/regapi
zu wechseln und dort der Befehl make einzugeben. (Dies setzt
voraus, dass WINE bereits erfolgreich <20>bersetzt wurde) Danach
k<>nnen die erforderlichen Schl<68>ssel durch die Eingabe des folgenden
Befehls importiert werden:
./regapi setValue < ../../documentation/psdrv.reg
Achtung:
Bei dem Programm regapi handelt es sich um ein so genanntes
WineLib-Programm. Solche Programme benutzen WINE, um
Windows-spezifische Funktionen verwenden zu k<>nnen. Damit sie
ausgef<65>hrt werden k<>nnen, muss bereits eine funktionsf<73>hige
WINE-Konfiguration vorhanden sein. Dieser Schritt sollte also nicht
durchgef<65>hrt werden, bevor die Erstellung der Konfigurationsdatei
abgeschlossen und die Funktionsf<73>higkeit von WINE getestet worden
ist.
Weiter wird eine so genannte PPD-Datei ben<65>tigt. Eine solche Datei
beschreibt verschiedene Eigenschaften des Druckers und wird
ben<65>tigt, damit WINE beispielsweise entscheiden kann, ob in Farbe
oder in Schwarz-Wei<65> gedruckt werden kann. Wenn kein
PostScript-f<>higer Drucker benutzt wird, dann ben<65>tigt man eine
PPD-Datei, welche die Eigenschaften des ghostscript-Treibers f<>r
den eingesetzten Drucker beschreibt, weil dieses Programm in der
Regel zur Umwandlung von PostScript in das Druckerformat benutzt
wird. Mit Debian stehen solche Dateien in dem Paket ppd-gs zur
Verf<72>gung. Wird dieses Paket benutzt, sollte vorher die Datei
/usr/doc/ppd-gs/README gelesen werden.
Eine Reihe von PPD-Dateien stehen unter der Adresse
ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/ppdfiles/ zur
Verf<72>gung. In dem Verzeichnis befinden sich selbstauspackende
ZIP-Archive, die PPD-Dateien f<>r Drucker verschiedener Hersteller
enthalten. Diese Archive k<>nnen mit dem Programm unzip(1) entpackt
werden. Um beispielsweise die Datei hp.exe auszupacken, w<>re
folgender Befehl einzugeben:
unzip -L hp.exe
Danach ist die gew<65>nschte PPD-Datei auszuw<75>hlen, hierbei muss
u.U. ein wenig experimentiert werden, um optimale Ergebnisse zu
erzielen. Die Datei kann dann beispielsweise in das Verzeichnis
/usr/local/etc/ kopiert werden und muss WINE durch den folgenden
Eintrag in der Konfigurationsdatei bekannt gemacht werden:
[psdrv]
ppdfile=/usr/local/etc/HP4M3_V1.PPD
Falls sich die Datei in einem anderen Verzeichnis befindet oder
einen anderen Namen tr<74>gt, ist der Wert f<>r die Variable ppdfile
nat<61>rlich entsprechend anzupassen.
Schlie<69>lich ben<65>tigt WINE die Fontmetric-Dateien der Schriftarten,
die auf dem Drucker (oder mit ghostscript) zur Verf<72>gung
stehen. Eine Reihe solcher Fontmetric-Dateien lassen sich unter
Debian beispielsweise mit dem Paket tetex-extra installieren. Sie
befinden sich nach der Installation unterhalb des Verzeichnisses
/usr/share/texmf/fonts/afm. Sie haben normalerweise die
Dateinamensendung .afm (Adobe FontMetric). Die zu verwendenden
Dateien sind im Abschnitt [afmfiles] der Konfigurationsdatei
anzugeben. Der Name jeder Datei ist dabei einer Variablen
zuzuordnen, deren Name sich aus der Zeichenkette file und einer
fortlaufenden Ziffer zusammensetzt. Bei der Auswahl der
AFM-Dateien ist zu beachten, dass nur die Dateien angegeben werden
brauchen, f<>r die der entsprechende Font tats<74>chlich in der vorher
definierten PPD-Datei genannt wurde. Die Bezeichnungen der Fonts
befinden sich normalerweise in den Fontmetric-Dateien, die mit
einem Texteditor betrachtet werden k<>nnen. Der Anfang des
entsprechenden Abschnitts in der Konfigurationsdatei k<>nnte
beispielsweise folgenderma<6D>en aussehen:
[afmfiles]
file1=/usr/share/texmf/fonts/afm/adobe/times/ptmb8a.afm
file2=/usr/share/texmf/fonts/afm/adobe/times/ptmbi8a.afm
file3=/usr/share/texmf/fonts/afm/adobe/times/ptmr8a.afm
file4=/usr/share/texmf/fonts/afm/adobe/times/ptmri8a.afm
file5=/usr/share/texmf/fonts/afm/adobe/helvetic/phvbo8an.afm
file6=/usr/share/texmf/fonts/afm/adobe/helvetic/phvb8a.afm
file7=/usr/share/texmf/fonts/afm/adobe/helvetic/phvb8an.afm
file8=/usr/share/texmf/fonts/afm/adobe/helvetic/phvbo8a.afm
file9=/usr/share/texmf/fonts/afm/adobe/helvetic/phvro8an.afm
file10=/usr/share/texmf/fonts/afm/adobe/helvetic/phvr8a.afm
file11=/usr/share/texmf/fonts/afm/adobe/helvetic/phvr8an.afm
file12=/usr/share/texmf/fonts/afm/adobe/helvetic/phvro8a.afm
Auch hier sind die Dateinamen nat<61>rlich an die tats<74>chlich
benutzten Fontmetric-Dateien anzupassen. Der Druckertreiber sollte
dann als WINE PostScriptDriver in den Druckdialogen der
Windows-Anwendungen zur Verf<72>gung stehen.
7.13 Konfiguration des Spoolers
Standardm<64><6D>ig werden Druckdaten in eine Datei im aktuellen
Arbeitsverzeichnis ausgegeben, deren Name der Bezeichnung des
Druckeranschlusses unter Windows, auf den gedruckt wurde, entspricht.
Im Abschnitt [spooler] der Konfigurationsdatei l<>sst sich die Ausgabe in
eine andere Datei umlenken oder an ein anderes Programm weiterleiten.
Dazu ist in dem Abschnitt der Name des Anschlusses als
Variablenbezeichnung anzugeben (Beispiel: LPT1:) und dieser Variable
der Name der Datei zu <20>bergeben, in welche die Druckausgabe gelenkt
werden soll. Um die Ausgabe an die Standardeingabe eines Programms zu
<20>bergeben, ist der Name des gew<65>nschten Programms hinter dem
Pipe-Zeichen (|) anzugeben.
Wenn also beispielsweise die Ausgabe auf den Anschluss LPT1: an das
Programm lpr <20>bergeben werden soll, um sie dem Spooler zuzuf<75>hren,
w<>re in die Konfigurationsdatei folgender Abschnitt aufzunehmen:
[spooler]
LPT1:|lpr
7.14 Multimedia Konfiguration
Die Multimedia-Architektur unter Windows besteht aus verschiedenen
Typen von Treibern und Schnittstellen, die von Windows-Programmen
benutzt werden k<>nnen. Diese Architektur wird von WINE
nachgebildet, wobei unterschiedliche Bestandteile mehr oder weniger
vollst<73>ndig vorhanden sind. Eine ausf<73>hrliche Beschreibung der
Multimedia-Architektur von WINE befindet sich in der Datei
multimedia um Unterverzeichnis documentation/status des
WINE-Quellcodes.
WINE stellt einen eigenen Treiber zur Ansteuerung der Soundhardware
zur Verf<72>gung. Diese Ansteuerung geschieht <20>ber die Ger<65>tedateien
/dev/dsp, /dev/audio, /dev/mixer usw. Deswegen muss darauf geachtet
werden, dass Schreib und Leseberechtigung f<>r diese Dateien
besteht, falls die Soundunterst<73>tzung von WINE benutzt werden
soll. Der Treiber setzt auf die OSS- (Open SoundSystem) Treiber
auf, die standardm<64><6D>ig Bestandteil des Linux-Kernels sind.
Bis auf die Bibliotheken winmm und mmsystem lassen sich alle
anderen Komponenten des Multimediasystems auch aus einer
bestehenden Windows-Installation verwenden. Dies ist vor allem bei
einigen MCI-Treibern hilfreich, die in WINE noch nicht vollst<73>ndig
implementiert sind. MCI-Treiber werden geladen, wenn im Abschnitt
[mci] der Datei system.ini im Windows-Verzeichnis Anweisungen in der
folgenden Form stehen:
[mci]
cdaudio=mcicda.drv
sequencer=mciseq.drv
Bei Verwendung einer bestehenden Windows-Installation sollten sich
die entsprechenden Anweisungen dort bereits befinden. Wird ohne
eine bestehende Windows-Installation gearbeitet, kann die Datei
system.ini im Unterverzeichnis documentation/samples des
WINE-Quellcodeverzeichnisses als Vorlage dienen. Durch die Variable
mci im Abschnitt [options] der Konfigurationsdatei von WINE lassen
sich die Definitionen aus der Datei system.ini <20>berschreiben. Das
ist sinnvoll, um bestimmte Treiber nicht zu laden, die in der Datei
system.ini angegeben sind, weil diese Treiber mit WINE nicht
richtig funktionieren. Dies ist zur Zeit mit dem MCI-Treiber
videodisk der Fall. Um alle MCI-Treiber (bis auf videodisk) zu
laden, k<>nnte in die Konfigurationsdatei der also der folgende
Abschnitt aufgenommen werden:
[options]
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
Ob ein Treiber aus einer bestehenden Windows-Installation geladen
oder der von WINE zur Verf<72>gung gestellte Treiber benutzt werden
soll, kann wie bei Bibliotheken im Abschnitt DllOverrides der
Konfigurationsdatei festgelegt werden, wie es weiter oben
beschrieben wurde. Dabei ist zu beachten, dass die
Dateinamensendung .drv bei Treibern - im Gegensatz zu Bibliotheken
- mit anzugeben ist. Um beispielsweise die MCI-Treiber mciavi und
mcianim aus einer bestehenden Installation zu laden und die <20>brigen
Treiber von WINE zu verwenden, w<>ren dem Abschnitt [DllOverrides]
die folgenden Zeilen zuzuf<75>gen:
mciavi.drv, mcianim.drv = native, builtin
mcicda.drv, mciseq.drv = builtin, native
msacm.drv, midimap.drv = builtin, native
mciwave.drv = builtin, native
7.15 Einrichten der Registratur
Eine Reihe von Windows-Programmen und WINE selbst ben<65>tigen
bestimmte Eintr<74>ge in der Registratur, damit sie richtig
funktionieren. Wenn WINE ohne eine bestehende Windows-Installation
benutzt wird oder die Windows-Registratur nicht importiert werden
soll, sind diese Eintr<74>ge noch nicht vorhanden und m<>ssen mit dem
weiter oben bereits erw<72>hnten Programm regapi importiert
werden. Als Vorlage kann dazu die Datei winedefault.reg im
Quellcodeverzeichnis von WINE dienen. Die Datei sollte jedoch
daraufhin <20>berpr<70>ft werden, ob alle dort angegebenen
Laufwerksbuchstaben und Pfade stimmen, bevor sie importiert wird.
Au<41>erdem sollte in der Konfigurationsdatei nat<61>rlich festgelegt
sein, dass die Registratur bei Beendigung des Programms gespeichert
wird, damit die importierten Daten auch beim n<>chsten Aufruf von
WINE zur Verf<72>gung stehen. Danach kann in das Unterverzeichnis
programs/regapi des Quellcodeverzeichnisses gewechselt werden. Dort
ist das Programm zun<75>chst durch Eingabe des Befehls make zu
erstellen, falls dies noch nicht geschehen ist. Danach k<>nnen die
erforderlichen Daten mit dem folgenden Befehl importiert werden:
./regapi setValue ../../WINEdefault.reg
8 Aufruf von WINE und Kommandozeilenoptionen
WINE l<>sst sich wie jedes andere Programm von der Kommandozeile aus
aufrufen. Der Name des auszuf<75>hrenden Windows-Programms ist WINE
dabei an der Kommandozeile angeben. Programme, die sich in einem
Verzeichnis befinden, das in der Variablen Path im Abschnitt WINE
der Konfigurationsdatei aufgef<65>hrt ist, k<>nnen dabei ohne Angabe
des Pfadnamens aufgerufen werden. Die Angabe der Dateinamensendung
.exe ist optional. Falls WINE also gestartet und das
Windows-Programm winmine (Minesweeper) geladen werden soll, w<>re
der folgende Befehl einzugeben, vorausgesetzt, die Datei
winmine.exe w<>rde sich in einem Verzeichnis befinden, welches in
der Variablen Path aufgef<65>hrt ist.
wine winmine.exe
Sollen Programme gestartet werden, die sich in Verzeichnissen
befinden, welche nicht in der Variablen Path befinden, ist es
erforderlich, den Pfadnamen mit anzugeben. Hier kann entweder der
DOS-/Windows-Pfadname oder der UNIX-Pfadname benutzt werden. Die
beiden folgenden Befehle w<>rden also das gleiche bewirken, falls
das Laufwerk C: dem UNIX-Verzeichnis /var/winroot zugeordnet w<>re.
wine c:\\windows\\winmine.exe
wine /var/winroot/windows/winmine.exe
Der R<>ckw<6B>rts-Schr<68>gstrich hat f<>r die Shell Bash eine besondere
Bedeutung und wird deswegen normalerweise nicht an WINE
<20>bergeben. Durch die doppelte Angabe dieses Zeichens wird bewirkt,
dass ein einfacher Schr<68>gstrich <20>bergeben wird. Datei- und
Verzeichnisnamen enthalten unter Windows gelegentlich
Leerzeichen. Auch hier ist es notwendig einen Trick anzuwenden,
damit die Leerzeichen nicht dazu f<>hren, dass die Shell die
einzelnen Teile der Namen in verschiedenen Argumente zerlegt. Der
folgende Befehl w<>rde beispielsweise nicht zum gew<65>nschten Ergebnis
f<>hren:
WINE /var/winroot/Programme/Microsoft Games/RoA Trial Version/PACDEMO.EXE
Hier w<>rde die Shell WINE vier Argumente <20>bergeben, n<>mlich
/var/winroot/Programme/Microsoft, Games/RoA, Trial und
Version/PACDEMO.EXE, woraufhin das zu startende Programm nicht mehr
gefunden werden w<>rde. Damit die Shell bei Leerzeichen keine
Trennung durchf<68>hrt, ist den betreffenden Leerzeichen ebenfalls ein
r<>ckw<6B>rtsgerichteter Schr<68>gstrich voranzustellen:
WINE /var/winroot/Programme/Microsoft\ Games/RoA\ Trial\ Version/PACDEMO.EXE
Argumente, die den zu startenden Windows-Programmen <20>bergeben
werden sollen, sind dem Programmnamen, getrennt durch Leerzeichen,
nachzustellen. Um beispielsweise das Programm notepad.exe zu
starten und diesem Programm das Argument readme.1st zu <20>bergeben,
w<>re WINE so aufzurufen:
wine notepad readme.1st
Wenn mehrere Windows-Programme hintereinander gestartet werden sollen,
muss WINE mehrmals hintereinander mit den entsprechenden Programmnamen
als Argument aufgerufen werden.
8.1 Kommandozeilenoptionen
Neben den Namen der zu startenden Programme versteht WINE eine Reihe
von Optionen, mit denen die Operation des Programms global beeinflusst
werden kann. Diese Optionen werden direkt von WINE interpretiert
und nicht an das aufzurufende Windows-Programm <20>bergeben.
--managed
Standardm<64><6D>ig laufen Windows-Programme mit WINE unabh<62>ngig
vom eingesetzten Windows-Manager. Dies kann zu Problemen bei
der gleichzeitigen Verwendung normaler X Programme und von
Windows-Programmen f<>hren. Durch Verwendung der Option
--managed werden auch Windows-Programme vom Window-Manager
verwaltet, sie erhalten dann die gleichen Verzierungen wie
normale X Programme (siehe auch Abschnitt 7.5)
--desktop BreitexH<78>he
Mit diesem Parameter werden alle Fenster von
Windows-Programmen in einem eigenen Fenster dargestellt. Die
Gr<47><72>e dieses Fensters wird in Bildpunkten mit Breite und
H<>he angegeben. Beispiel: --desktop 800x600. Dieser Modus
wird f<>r die Verwendung solcher Programme ben<65>tigt, die den
Bildschirm selbst komplett verwalten wollen, wie es
z.B. beim Windows-Explorer der Fall ist. Der Modus ist auch
erforderlich, um WINE mit den Bibliotheken user und user32
aus einer bestehenden Windows-Installation zu verwenden.
--config Dateiname
Hiermit kann WINE angewiesen werden, eine andere
Konfigurationsdatei zu verwenden.
--display Displaybezeichnung
Wie alle X-Programme verwendet WINE normalerweise den
X-Server, der mit der Umgebungsvariablen DISPLAY angegeben
ist. Um einen anderen Server zu verwenden, ist diese Option
zu benutzen. Beispiel: --display workstation:0.
--winver Version
Viele Windows-Programme funktionieren nur mit bestimmten
Versionen von Windows oder verhalten sich unterschiedlich,
je nachdem mit welcher Version von Windows sie ausgef<65>hrt
werden. Dieser Parameter dient dazu, WINE anzuweisen, als
welche Windows-Version es sich ausgeben soll, wenn Programme
dies erfragen. Standardm<64><6D>ig versucht WINE selbst
herauszufinden, welche Version von einem bestimmten Programm
erwartet wird. Mit Version kann folgendes angegeben werden:
win31 (Windows 3.1), win95 (Windows 95), win98 (Windows 98),
nt351 (Windows NT 3.51) oder nt40 (Windows NT 4.0). Im
Zweifelsfall empfiehlt sich win95, weil WINE zur Zeit die
meisten Gemeinsamkeiten mit dieser Windows-Version
aufweist. Beispiel: --winver win95.
--dosver Version
Wenn DOS-Programme mit Windows ausgef<65>hrt werden, erwarten
diese gelegentlich eine bestimmte Version von MS-DOS. Dazu
ist mit dem Parameter --dosver die gew<65>nschte Version, in
der Form x.xx anzugeben. Beispiel: --dosver 7.10 (diese
Version entspricht Windows 95b).
--language Sprache
W<>hrend Windows in Versionen f<>r verschiedene Sprachen
verf<72>gbar ist, befindet sich die Unterst<73>tzung f<>r eine
Reihe von Sprachen direkt in WINE. Welche Sprache benutzt werden
soll kann mit diesem Parameter angegeben werden. Um die
deutsche Sprache auszuw<75>hlen, ist f<>r Sprache De
anzugeben. Es ist zu beachten, dass einige Anwendungen nur
mit bestimmten Sprachen funktionieren. Wenn Anwendungen
irgendwelche Bibliotheken nicht finden k<>nnen, kann das
daran liegen, dass sie solche Bibliotheken suchen, die f<>r
die Sprache entwickelt wurden, mit der WINE arbeitet und
diese nicht verf<72>gbar sind. Hier hilft es, die richtige
Sprache anzugeben. Beispiel: --language De.
--help
Die Option bewirkt, dass eine <20>bersicht <20>ber die verf<72>gbaren
Optionen ausgegeben wird.
--version
Die Option bewirkt, dass die Versionsnummer von WINE
angezeigt wird.
--dll Bibliothek[,Bibliothek ...]=b|n[:Bibliothek[,Bibliothek,...]=b|n]
Mit dieser Option lassen sich die Einstellungen aus dem
Abschnitt [DllOverrides] aus der Konfigurationsdatei
<20>berschreiben, es kann also angegeben werdem, welche
Bibliotheken aus einer bestehenden Windows-Installation
geladen und welche direkt von WINE zu Verf<72>gung gestellt
werden sollen. Der Option ist ein Ausdruck zu <20>bergeben,
welcher aus den Namen der betreffenden Bibliotheken besteht,
die durch Kommata (ohne Leerzeichen) voneinander getrennt
werden. Danach folgt ein Gleichheitszeichen und daraufhin
entweder der Buchstabe b, um zu bestimmen, dass die
angegebenen Bibliotheken von WINE zur Verf<72>gung gestellt
werden sollen, oder der Buchstabe n, damit versucht wird,
die Bibliotheken aus einer bestehenden Installation zu
laden. Solche Ausdrucke k<>nnen wiederholt angegeben werden,
sie sind dann durch einen Doppelpunkt (ohne Leerzeichen)
voneinander zu trennen. Sollen beispielsweise die
Bibliotheken shell, commdlg und commctrl mit ihren
zugeh<65>rigen 32bit Bibliotheken aus einer bestehenden
Installation geladen werden und die Bibliothek advapi32 von
WINE zur Verf<72>gung gestellt werden, obwohl dies in der
Konfigurationsdatei anders angegeben ist, so k<>nnte man die
Option so einsetzen:
--dll commdlg,comdlg32,commctrl,comctl32,shell,shell32=n:advapi32=b.
--debugmsg +|-foo,+|-bar
Diese Option dient dazu, zu kontrollieren, welche Art von
Informationen WINE zur Fehler- und Ablaufverfolgung ausgeben
soll. Es stehen eine Reihe so genannter Kan<61>le zur Verf<72>gung,
deren Namen angezeigt werden, wenn die Option ohne weitere Angaben
benutzt wird. Die einzelnen Kan<61>le entsprechen normalerweise
unterschiedlichen Teilbereichen von WINE, deren Verhalten durch
die Ausgabe bestimmter Informationen <20>berpr<70>ft werden kann. Um
beispielsweise die Meldungen f<>r den Kanal file einzuschalten,
w<>re die Option --debugmsg +file zu benutzen. Wenn die
Meldungen der Kan<61>le file und dosfs ausgegeben werden sollen,
w<>re --debugmsg +file,+dosfs anzugeben. Weitere Informationen
hierzu befinden sich in der Datei debug-msg im Unterverzeichnis
documentation des WINE-Quellcodeverzeichnisses. Zwei besonders
wichtige Kan<61>le sind relay und snoop. Wenn der Kanal relay
eingeschaltet ist, wird ausgegeben, welche Funktionen in WINE
von Windows-Programmen mit welchen Parametern aufgerufen werden
und welche R<>ckkehrwerte diese Funktionen liefern. Der Kanal
snoop zeigt an, welche Funktionen aus echten
Windows-Bibliotheken aufgerufen werden. Die Ausgabe des Kanals
relay dient WINE-Entwicklern oft dazu, festzustellen, wo ein
Fehler aufgetreten ist. Deswegen ist es ratsam, bei
Fehlerberichten in die WINE-Newsgroup die letzten 200 Zeilen
der Ausgabe von WINE mitzuschicken, die bei dem Aufruf des
Programms mit der Option --debugmsg +relay vor Auftreten des
Fehlers entstanden sind.
9 Fehlerquellen
WINE befindet sich zur Zeit noch mitten in der Entwicklung, weswegen
viele Windows-Programme nur teilweise oder <20>berhaupt nicht damit
funktionieren. Mit gro<72>er Wahrscheinlichkeit werden einige Programme
sogar nie mit WINE funktionieren, beispielsweise weil sie eigene
Windows-Treiber brauchen, die unter Linux nicht geladen werden k<>nnen.
Trotzdem funktionieren viele Windows-Programme ausgesprochen gut mit
WINE und die Anzahl funktionierender Programme erh<72>ht sich relativ
schnell. Wenn ein Programm nicht wie gew<65>nscht funktioniert, kann es
deswegen hilfreich sein, die folgenden Fragen zu untersuchen:
WINE funktioniert <20>berhaupt nicht
In bestimmten Paketversionen der C-Bibliothek (Version
2.1.3) liegt ein Fehler vor, der dazu f<>hrt, dass WINE
direkt nach dem Start mit Fehlermeldungen abbricht. Sie
k<>nnen das Problem beheben, indem Sie eine neuere Version
der C-Bibliothek installieren oder die Variable LANG auf
einen Wert setzen. Bei Verwendung der Bash kann dies
beispielsweise durch Eingabe des folgenden Befehls
geschehen: export LANG=de_DE.
WINE funktioniert immer noch nicht
Wenn Sie WINE auf die beschriebene Art installiert haben,
sollten Sie <20>berpr<70>fen, dass sich nicht gleichzeitig noch
eine andere, <20>ltere Version des Programms auf dem Rechner
befindet, welches u.U. von Ihrer Distribution mitinstalliert
wurde. Dies k<>nnte n<>mlich dazu f<>hren, dass versucht wird,
inkompatible Bibliotheken zu laden.
Windows- und Windows/system-Verzeichnis sind nicht richtig angegeben
Die Meldung Invalid path 'c:\windows' for windows directory
besagt, dass im Abschnitt WINE der Konfigurationsdatei mit
der Variablen Windows ein Windows-Verzeichnis angegeben
wurde, welches nicht existiert. Es ist dann zu <20>berpr<70>fen,
ob das Windows-Verzeichnis vorhanden ist und ob das
Laufwerk, auf dem es sich befindet, dem richtigen
UNIX-Verzeichnis zugeordnet ist.
Die Zuordnungen der Laufwerksbuchstaben stimmen nicht
Wenn beim Start von WINE Meldungen wie Warning:
/var/winroot/windows/sol.exe not accessible from a DOS drive
ausgegeben werden, teilt WINE mit, dass das auszuf<75>hrende
Programm sich in einem Verzeichnis befindet, dass aufgrund
der Zuordnungen in der Konfigurationsdatei mit keinem
Laufwerk assoziiert ist. Es sollten dann die
Laufwerkszuordnungen <20>berpr<70>ft werden.
Windows-Programme finden Einstellungen und Bibliotheken nicht
Wenn WINE mit einer bestehenden Windows-Installation benutzt
wird, ist es erforderlich, dass die Laufwerksbuchstaben
unter Windows und WINE <20>bereinstimmten. Falls ein Programm
n<>mlich beispielsweise in der Registratur gespeichert hat,
dass sich eine bestimmte Komponente im Verzeichnis
C:\Windows\System befindet, dann ist es erforderlich, dass
dieses Programm die Komponente auch unter WINE in dem selben
Verzeichnis findet. Es ist jedoch m<>glich mit WINE
zus<75>tzliche Laufwerke zu verwenden (also z.B. das eigene
Heimatverzeichnis einem Laufwerksbuchstaben zuzuordnen), die
unter Windows nicht vorhanden sind.
Spiele werden im Fenster dargestellt, obwohl Vollbild ausgew<65>hlt wurde
und sind zu langsam
Die meisten Spiele benutzen einen bestimmte Farbtiefe, in
die Windows umschaltet, wenn das betreffende Spiel gestartet
wird. Mit dem X Window System ist es leider nicht m<>glich
die Farbtiefe w<>hrend des laufenden Betriebs zu <20>ndern,
weswegen WINE die gew<65>nschte Farbtiefe in einem Fenster
emulieren muss, falls der X-Server nicht in der richtigen
Farbtiefe l<>uft. Dadurch wird sehr viel Rechenleistung
ben<65>tigt und au<61>erdem kann nicht in einen Vollbildmodus
geschaltet werden. Abhilfe schafft hier nur, den X-Server in
der richtigen Farbtiefe zu starten, bevor WINE aufgerufen
wird. Hierzu dienen die Optionen -bpp, bei X-Servern des
XFree86-Projekts der Versionsfamilie 3.3.x bzw. -depth in
der Versionsfamilie 4.0) Gelegentlich empfiehlt es sich
auch, einen zweiten X-Server zu starten, was am einfachsten
mit dem Befehl xinit(1) geschehen kann. Um beispielsweise
das Programm q2test.exe mit WINE auf einem zweiten X-Server
mit einer Farbtiefe von 8 Bit pro Pixel aus dem aktuellen
Arbeitsverzeichnis zu starten, k<>nnte der folgende Befehl
benutzt werden:
xinit /usr/local/bin/WINE q2test.exe --display :1 -- -bpp 8 :1
Falls sich WINE in einem anderen Verzeichnis als
/usr/local/bin befindet, ist der Befehl nat<61>rlich
entsprechend anzupassen.
Der DGA-Modus funktioniert nicht, obwohl X in der richtigen
Farbtiefe ausgef<65>hrt wird; Spiele sind immer noch langsam
Die Verwendung von DGA ist normalerweise nur dem
Systemadministrator gestattet, das betreffende Programm muss
also mit dessen Rechten ausgef<65>hrt werden. Alternativ dazu
reicht es auch aus, Benutzern Schreib- und Leserechte auf
die Ger<65>tedatei /dev/kmem zu erteilen.
Es ist kein Sound zu h<>ren
Zun<75>chst sollte <20>berpr<70>ft werden, ob die Soundunterst<73>tzung
des Linux-Kernels richtig funktioniert, also ob es m<>glich
ist, mit anderen Linux-Programmen die Soundkarte zu
verwenden. Im n<>chsten Schritt kann <20>berpr<70>ft werden, ob die
Sound-Hardware von einem anderen Programm benutzt wird und
WINE deswegen nicht darauf zugreifen kann.
Weiterf<EFBFBD>hrende Informationen
Die zentrale Web-Adresse f<>r Informationen zu WINE ist
http://www.winehq.com. Dort befinden sich Links zu vielen weiteren
Dokumenten, wie einem WINE-FAQ, einem WINE-HOWTO, einer Anleitung zum
Erstellen von Fehlerberichten und vieles mehr.