From 5bd96a2d3fbe3c80443810bcc8896375167c2592 Mon Sep 17 00:00:00 2001 From: Maik Schulz Date: Sun, 21 Dec 2008 23:57:38 +0100 Subject: german translations for winehq.org --- templates/de/developer-cheatsheet.template | 642 ++++++++++++++++++++++++++++ templates/de/download.template | 2 +- 2 files changed, 643 insertions(+), 1 deletions(-) create mode 100644 templates/de/developer-cheatsheet.template diff --git a/templates/de/developer-cheatsheet.template b/templates/de/developer-cheatsheet.template new file mode 100644 index 0000000..347cb2e --- /dev/null +++ b/templates/de/developer-cheatsheet.template @@ -0,0 +1,642 @@ + + + +

Fünf-Minuten Einführung in die Wine-Entwicklung

+ +

+ Dies ist eine flüchtige Zusammenstellung von Tipps und Tricks, + die für Wine-Entwickler nützlich sein können. Sie + orientiert sich grob an dem OpenOffice.org Entwicklerleitfaden. +

+ +

+ Das Wine Entwicklerhandbuch ist eine hervorragende Referenz, die + viel weiter als dieses Dokument ins Detail geht, insbesondere + was Wines Architektur und die einzelnen Komponenten betrifft. + Solltest Du jedoch eine Übersicht dafür suchen, wie Du + am besten anfängst, bist Du hier richtig. +

+ +

Debug Logging

+ +

+ Das mächtigste Werkzeug, das Dir zur Verfügung steht um + herauszufinden, warum eine Anwendung nicht unter Wine läuft, + ist das Logging System. Die Verwendung ist denkbar einfach. Jeder + Teil des Quellcodes (abgesehen vom Server) loggt in einen + "Debug-Kanal" und jeder Kanal hat vier Klassen: trace, warn, err + und fixme. Per Voreinstellung werden ERR und FIXME Nachrichten + angezeigt, wogegen TRACE und WARN Nachrichten ausgeblendet bleiben. + Um sie einzublenden: +

+ + WINEDEBUG=+channel1,+channel2 wine myprogram.exe + +

+ Es gibt einige Kanäle, die besonders nützlich sind: +

+ +

+seh : Structured Exception Handling wird verwendet, + wenn eine Anwendung eine unzulässige Operation ausführt + (also abstürzt) oder wenn hin und wieder ein Programm seine + eigene Exception auslöst. UNIX-Signale werden von Wine in + SEH Exceptions umgewandelt und Du kannst ihre Ausbreitung durch + diesen Kanal verfolgen. Das ist deswegen nützlich, weil + Anwendungen häufig ihre eigenen Abstürze abfangen, um + zum Beispiel eine Notfallspeicherung vorzunehmen. Die + häufigste Exception, nach der man Ausschau halten sollte, + ist die STATUS_ACCESS_VIOLATION oder 0xC0000005, die + einem Win32-Segfault am nächsten kommt. Du könntest + auch auf Codes treffen, die nicht in den Headern vorkommen. + Dies sind normalerweise programmiersprachenspezifische Exceptions, + die von dem Compiler, der benutzt wurde, um das jeweilge .EXE + zu erstellen, verwendet werden. 0xEEDFADE ist der Code + für eine interne Delphi Exeception. 0xE06D7363 ist + eine Microsoft Visual C++ Exception. Sie hat den Wert + 0x19930520 in info[0] stehen, den man sich leicht merken + kann, weil er wie ein Datum aussieht (und wahrscheinlich eins + ist). Falls Du diese antriffst, hat wahrscheinlich ein Win32 + API-Aufruf einen Fehlercode ungleich Null irgendwo + zurückgegeben.
+
+ +tid : Dieser Kanal stellt jeder Debugzeile die ID des + Threads voran, der sie erzeugt hat. Zum Debuggen von Anwendungen + mit mehreren Threads ist das unverzichtbar, da jederzeit ein + Kontextwechsel stattfinden kann. Ohne diese Ausgabe gibt es + häufig keine Möglichkeit herauszufinden, was in + dem Programm vor sich geht. Falls Du Dir nicht sicher bist, + ob ein Programm mehrere Threads nutzt, verwende die Option + einfach (sie ist billig aber nicht kostenlos).
+
+ +relay : Dieser Kanal ist meistens Dein erster Anlaufpunkt, + wenn Dir nicht klar ist, was schiefläuft. Er zeigt Dir + jeden Aufruf in und aus Wine-Modulen an den DLL-Grenzen. Das + beinhaltet Aufrufe zwischen Wine-DLLs, z.B. von GDI32 in + KERNEL32. Guck Dir die RelayInclude und RelayExclude String-Werte + in [HKCU\Software\Wine\Debug] an, falls Du von einigen Funktionen + überwältigt wirst. Ein brauchbarer Startwert für + RelayExclude ist:
+ + RtlEnterCriticalSection;RtlLeaveCriticalSection;_EnterSysLevel;_LeaveSysLevel; + _CheckNotSysLevel;RtlAllocateHeap;RtlFreeHeap;LOCAL_Lock;LOCAL_Unlock +
+ + Die Mehrzahl dieser Funktionen wird häufig aufgerufen, gibt + aber normalerweise keinen Hinweis, warum ein Programm nicht + funktioniert.
+
+ +snoop : Dieser Kanal macht das Gleiche wie relay, arbeitet + allerdings zwischen nativen DLLs. Seine Informationen + sind nicht so gut wie die relay-Daten, da es keine Angaben zu + den verwendeten Parametern gibt. Snoop inspiziert den Stack und + disassembliert Funktionsprologe um erraten zu können, was + die Parameter sind und kann so die Anwendung destabilisieren.
+
+ +heap : Dieser Kanal stellt eine Verfolgung sämtlicher + Heap-Aktivitäten des Programms zur Verfügung. Er schaltet + außerdem kontinuierliche Integritätsprüfungen ein: + Falls Du eine Anwendung hast, die die Heap-Bereiche zerstört, + kann Dir ein +relay,+heap Trace dabei helfen, + einzugrenzen, wo das Problem auftritt. Wenn eine Inkonsistenz + entdeckt wird, wird der Inhalt des Bereichs ausgegeben und das + Programm abgebrochen. Eine Zerstörung des Heap-Bereichs kann + unterschiedliche Ursachen haben; die häufigste ist, dass Wine + die Grenzen eines internen Puffers überschreibt. Neuer Wine-Code + nutzt intern meistens die HeapAlloc/HeapFree APIs, und einer der + Gründe dafür ist, dass das eingebaute Heap Debugging von + Wine nicht sehr hilfreich ist.
+
+ +olerelay : Dieser Kanal gibt jeden Aufruf aus, der durch + den typelibrary Marshaller ging. Er ist ähnlich zu +relay, + funktioniert aber besser für eine bestimmte Kategorie von + DCOM-Aufrufen, die sonst nicht sichtbar wären. Leider ist + das jedoch kein allgemeiner COM-Weiterleitungsmechanismus. Er + kann beim Debuggen von InstallShield-Problemen weiterhelfen. + Allerdings sind InstallShield/DCOM-Probleme eher etwas für + Fortgeschrittene; wir empfehlen daher, dass du Unterstützung + anfragst, wenn Du diese debuggen willst.
+
+ +server : Dieser Kanal zeigt jeden wineserver RPC. + Normalerweise ist das nicht nötig, kann sich aber als + nützlich erweisen, wenn Du Probleme in der Interaktion mit + dem wineserver verfolgst. Weiter unten findest Du Informationen + zum wineserver.
+
+ +loaddll : Gibt Dir eine Benachrichtigung jeder DLL, wenn + sie geladen wird. Eine leichtgewichtige Alternative zum Dependency + Walker (depends.exe), falls dieser nicht verfügbar ist.
+

+ +

Grundlegende Debugging Tipps

+ +

+ Falls ein Programm beim Absturz eine Message Box darstellt + und Du den Grund des Problems nicht kennst, versuche es mit + einem +relay,+msgbox Trace. Guck Dir dann das Log in Deinem + Lieblingseditor oder -textbetrachter (less ist recht gut) an + und suche nach trace:msgbox. Guck Dir jetzt die Weiterleitungsdaten + direkt vor dem MessageBox API-Aufruf an. Suche insbesondere + nach fehlgeschlagenen API-Aufrufen. Der Fehler wird nicht + notwendigerweise durch einen Aufruf verursacht, der direkt + vor dem Fehler stattfindet! Denke auch daran, dass die + Bedeutung von Rückgabewerten innerhalb der Windows APIs + nur selten konsistent ist; Du musst Dich an das, was + verwendet wird, gewöhnen. Viele APIs verwenden Werte + ungleich Null für Erfolgsmeldungen und Null für + Fehler, aber manchmal ist es andersherum.
+
+ Falls ein Programm schon beim Start abstürzt und Du + nicht weißt warum, kannst Du den +all Trace verwenden. + Falls es weit von einem API-Aufruf entfernt abstürzt, + kannst du es disassemblieren und überprüfen, ob + es auf Parameter, die an WinMain übergeben werden, + zugreift (Dungeon Keeper z.B. stürzt ab, wenn man + für argv[0] keinen absoluten Pfad verwendet).
+
+ Falls Dir die Logs zu groß sind, um damit arbeiten zu + können, kannst Du es mit dem debug-delay Patch + versuchen, der in den wine-patches Archiven verfügbar ist. + Mit diesem kannst Du das Logging über die F12-Taste ein- + und ausschalten. Du kannst außerdem die Debug-Kanäle + direkt aus dem Quellcode heraus mit den libwine APIs + kontrollieren.
+
+ Das Debuggen von Darstellungsfehlern geht am besten, indem man + sich die Stilvorgaben der Anwendung an das fehlerhafte Control + anguckt und dann den Quellcode des Widgets durchsieht. Es + gibt keine tollen Tricks, die Du hier anwenden kannst, Du + musst einfach mit dem Darstellungs-Code experimentieren und + so versuchen herauszufinden, wo das Problem steckt. + Glücklicherweise funktioniert das native Windows 98 + comctl32 gut, so dass Du dieses immer als Referenz nehmen + kannst.
+
+ Schrecke nicht davor zurück, einen Testfall für ein + bestimmtes API zu schreiben, wenn Du Zweifel bezüglich + dessen Implementierung hast. Und wenn Du selbst nicht über + die Werkzeuge verfügst, eine Test-EXE zu kompilieren, wird + sich jemand anderes finden, der diese hat. Häufig ist ein + Test die zuverlässigste Möglichkeit herauszufinden, + ob tatsächlich ein Bug vorliegt (und nicht nur ein Symptom + eines Fehlers, der woanders steckt) und gegenüber Alexandre + zu beweisen, dass Deine Änderung korrekt ist.
+
+ Die Quellcode-Struktur wird aufgeräumt, aber jeglicher Code + außerhalb von loader/, tools/, libs/ und programs/ wird + über Makefiles innerhalb des dlls/ Verzeichnis gebaut.
+
+ Falls sich ein Programm darüber beschwert, dass ein + Debugger läuft, musst Du herausfinden warum es das + denkt und die Ursache beheben. Wine meldet in der Grundeinstellung + keinen Debugger, da aber IsDebuggerPresent() leider so leicht + zu umgehen ist, nutzen viele Programme, insbesondere Spiele, + ausgefeiltere Techniken. Einige beinhalten Anti-Disassmblierungscode. + Gängige Anti-Debugger Techniken findest Du, in dem Du + Blackhat/Warez Cracker Websites liest: Tu es nur nicht auf der + Arbeit. Falls Du Versuche findest, SICE.VXD oder NTICE.VXD zu laden, + dann siehst Du eine Überprüfung auf den populären + SoftIce Debugger und kannst dies ignorieren.
+
+ Falls Du eine Windows-Lizenz hast (also jemals einen PC von der + Stange gekauft hast), kannst Du native DLLs von + dll-files.com + herunterladen. Das ist auch recht hilfreich falls Dir diverse + Runtime DLLs fehlen, deren Vorhandensein kleinere Anwendungen + häufig voraussetzen. Durch die Verwendung nativer DLLs kann + man gut herausfinden, wie sich ein API verhält, ohne + cross-kompilieren zu müssen. +

+ +

Implementierung von Win32

+ +

+
Versuche, dem Code-Stil im Rest der Datei treu zu bleiben, + wenn Du Patches schreibst. Die Wine-Entwickler sind sehr + entspannt was Code-Stil angeht, du wirst viel Abwechselung + sehen. Mach es nicht noch weniger konsistent, als es jetzt + schon ist. Im Fall von größeren Mengen neuen + Codes kannst Du aber gerne so arbeiten, wie es Dir am + besten gefällt. +
+
Microsoft hat Unicode-Unterstützung implementiert, + indem sie jeden API-Aufruf, der Strings entweder direkt als + Parameter oder in einer Datenstruktur akzeptiert, dupliziert + und zusätzlich Konvertierungsfunktionen geschrieben + haben. Da Windows UCS-2 (16 Bits per Zeichen) für + Unicode-Strings nutzt, enden die Funktionen, die Unicode + akzeptieren, mit W (für wide) und die, die kein Unicode + akzeptieren, mit A für ANSI. Unter Windows kann der + Compiler Unicode-Stringkonstanten erzeugen, aber unter Linux + können wir uns leider nicht auf äquivalente + Unterstützung seitens gcc verlassen, da er Strings nicht + im richtigen Format erzeugt. Mit anderen Worten kannst Du + Folgendes nicht schreiben:
+ + SomeRandomFunctionW( "Hello" );
+ + ebensowenig das hier:
+ + SomeRandomFunctionW( L"Hello" );
+ + +
+ Stattdessen musst Du Folgendes schreiben: +
+ + + static const WCHAR helloW[] = {'H','e','l','l','o',0}; + SomeRandomFunctionW( helloW ); + + +
+ Ja, es nervt. Emacs-Anwender können sich ein Makro + definieren, das Long Strings automatisch in Character Arrays + umwandelt. +
+ +
+ Desweiteren müssen String-Längen bei der + Unicode-Unterstützung beachtet werden: Wenn Du einen + Puffer für Unicode-Strings allozierst, musst Du + sizeof(string)*sizeof(WCHAR) verwenden. + Technisch gesehen ist auch das wegen der Möglichkeit + von Bonded Pairs nicht korrekt, allerdings ignoriert + Wines Code dies meistens, da man vorher weiß, dass + keine Zeichen außerhalb des Basic Multilingual Plane + genutzt werden. +
+ +
+ Da nun jedes Zeichen statt 1 Byte 2 braucht, musst Du also + auch die Wide-Versionen jeder String-Funktion verwenden, + z.B. strlenW statt strlen. Jede Funktion, die einen + Null-terminierten String erwartet, benötigt eine + Äquivalent in Wide, da angenommen wird, dass Wide-Strings + Null-Bytes beinhalten. +
+ +
+ Nachrichten, die mit Strings zu tun haben, gibt es auch in + A/W-Versionen und sowohl in Windows als auch in Wine + existiert umfangreiche Infrastruktur, um zwischen diesen + zu konvertieren, falls notwendig. Stell sicher, dass wir + die richtige Message-Variante abhängig vom String-Encoding + des Zielfensters schicken. Der Unterscheidungsmechanismus + ist nicht immer gleich, einige Widgets nutzen IsWindowUnicode + und andere schicken eine Message an das Ziel mit der Frage, + welches Format es braucht. +
+ +
+ Abschließende Bemerkung zu Unicode: Da Wide-Strings + Null-Bytes beinhalten, kannst Du sie nicht mit printf + ausgeben, was wiederum von Wines Debugging-Infrastruktur + verwendet wird. Falls Du einen Wide-String für ein + Debug Log (TRACE, ERR, WARN etc.) beibehalten willst, mach es so: +
+ + TRACE("das ist ein Wide-String: %s\n", debugstr_w(widestr));
+
+ Es gibt mehrere Sets von Fehler-Codes, die in Windows verwendet + werden. Die "nativen" NT APIs nutzen die Werte aus ntstatus.h, + wie z.B. STATUS_ACCESS_DENIED. Wenn man diese Ergebnisse an + normale Windows-Funktionen übergibt, müssen sie + in Fehler-Codes aus winerror.h konvertiert werden. Diese + Konvertierung wird mit RtlNtStatusToDosError() durchgeführt. + Andere können HRESULTs zurückgeben, was in den COM + APIs durchgängig genutzt wird. HRESULTs kannst Du mit den + SUCCEEDED/FAILED Makros auswerten.
+
+ Wo wir gerade davon reden, der Inhalt der ntdll ist nicht + dokumentiert. Erspare es dir also zu versuchen, auf MSDN + herauszufinden, was er tut. Unser Code ist eine gute + Abschätzung, allerdings solltest Du diese APIs nutzen, + wenn Du an Code innerhalb von kernel32 oder ntdll arbeitest. + Frage nach Unterstützung wenn du hängenbleibst. Die + meisten sind selbsterklärend, einige sind es nicht.
+
+ Sei vorsichtig mit Fehler-Codes: obwohl MSDN die Fehler-Codes, + die eine Funktion zurückliefern kann, dokumentiert, ist + diese Dokumentation leider häufig falsch. Und selbst dann, + wenn sie korrekt ist, ist nicht immer klar, welcher Zustand zu + welchem Fehler-Code führt. Viele Anwendungen verlassen + sich darauf, dass bestimmte Codes in bestimmten Szenarien + zurückgegeben werden: um sicherzugehen, schreibt man + am besten einen Testfall.
+
+ Begehe nicht den Fehler, Dich zu sehr auf MSDN zu verlassen. + Es enthält fehlerhafte Informationen - häufig ist es + nicht von den gleichen Leuten geschrieben worden, die den + Code geschrieben haben.
+
+ Win32 Code verwendet HeapAlloc(GetProcessHeap(), 0, allocsize) + anstelle von malloc(allocsize) und deshalb arbeitet Wine genauso. + In der Praxis wird diese Regel nicht streng befolgt, deshalb + kannst Du beides finden.
+

+ +

Verwendung des Debuggers

+ +

Winedbg hat mehrere nützliche Fähigkeiten. Die + wichtigsten sind die Möglichkeiten, einen Backtrace von + Threads mit Win32 und eingebaute Debugging-Informationen zu + bekommen. Normalerweise sind diese aus Windows-Programmen + entfernt, so dass das nichts bringt, es kann sich aber als + nützlich erweisen, wenn man native DLLs nutzt. Einen + Backtrace bekommst Du mit dem bt-Befehl. Einen + Backtrace eines bestimmten Threads bekommst du, indem Du die + hexadezimale Thread-ID anhängst, z.B. bt 0x9. + Anstelle einer Thread-ID kannst du auch "all" angeben.

+ +

Er unterstützt eine Untermenge der gdb-Befehle. Die + gebräuchlichsten sind vorhanden, Du kannst z.B. info + proc und info thread nutzen und den Debugger dann an + einen bestimmten Prozess dranhängen. Das ist nützlich, + um einen Backtrace von Deadlocks zu erhalten.

+ +

Er kann auch Code disassemblieren. Du solltest nicht zu + enthusiastisch werden, Disassemblierung enthüllt nur selten + brauchbare Informationen. Manchmal ist es jedoch die einzige + Möglichkeit, eine Untersuchung voranzubringen, z.B. um + herauszufinden, warum ein Programm abstürzt. Verwende den + disas-Befehl um einen Code-Abschnitt zu disassemblieren. + Versuche ausgerichtete Adressen zu verwenden wenn Du Dich von + einer bestimmten Adresse aus zurückarbeitest, sonst + riskierst Du, die Disassemblierung mitten in einer Instruktion + zu beginnen, was nur Müll produziert. Wenn Dir x86-Assembler + noch fremd ist, versuche dich erstmal an ELF-Programmen, die Du + selbst kompiliert hast, damit Du Dich an den Anblick + gewöhnst. Der Intel-Befehlssatz ist sehr umfangreich, aber + nur wenige Instruktionen werden häufig genutzt. Wenn Du + weißt, was Du zu erwarten hast, kommst Du nicht durch + schlechte Disassemblierung oder Anti-Disassemblierungstricks, + die die Ausgabe unbrauchbar machen können, ins Stolpern.

+ +

Erstens ist es wichtig, dass Du weißt was Du tust, wenn Du + Dich entscheidest, ein Programm zu disassemblieren. Es ist klar, + dass Du nicht einfach beliebigen Code in Deinen eigenen Programmen + wiederverwenden kannst. Versuch erst gar nicht, dekompilierten Code + als Serie von Patches beizutragen, das haben schon Andere probiert + und wir wissen, wie sowas aussieht. Alexandre wird jeden Patch, der + so aussieht als wäre er dekompiliert oder das Resultat einer + Disassemblierung, zurückweisen.

+ +

Zweitens, verstehe was Du siehst. Hier sind ein paar Tipps:

+ +

Code, der Werte in 0x0(%fs) schreibt, setzt wahrscheinlich + einen SEH Handler Frame auf.
Der Rückgabewert einer Funktion wird in allen + Aufrufkonventionen unter Windows in %eax gespeichert. Wenn Du + also einen Funktionsaufruf siehst, dem eine Überprüfung + dieses Registers folgt, hast du aller Wahrscheinlichkeit nach eine + Überprüfung auf einen Fehlercode vor Dir.
Aufrufinstruktionen, die einen Wert wie folgt dereferenzieren: + "call *0x12345678" sind normalerweise Funktionsaufrufe in andere + DLLs (häufig API-Aufrufe). Winedbg sollte in der Lage sein, + Dir zu zeigen, welches API die Instruktion aufruft. + Befehlssequenzen, die erst einen Wert in ein Register schreiben + und diesen dann in einer Aufrufinstruktion dereferenzieren + können gut Aufrufe von COM-Methoden sein.
Mit Microsoft Visual C++ (unter Windows der populärste + C++ Compiler) kompilierte C++ Anwendungen nutzen die thiscall + Aufrufkonvention, in der der Instanzzeiger in %ecx gespeichert + wird. Wenn du auf einen Absturz stößt, in dem der + Wert von %ecx in einem C++ Programm dereferenziert wird, + könntest Du eine Nullpointer-Dereferenz einer Objektinstanz + sehen. Das ist besonders wahrscheinlich wenn der Offset recht + groß ist, d.h. ein Absturz, der auf 0x36 zugreift, ist ein + recht guter Hinweis, dass es sich um ein C++ Objekt und nicht + nur um eine sehr große C-Struktur handelt.
Optimierende Compiler stellen eine Menge interessanter Dinge + an, wie z.B. Instruktionen umordnen, um sie besser an interne + Scheduling-Algorithmen von superskalaren Prozessoren anzupassen. + Das kann die Assembler-Instruktionenfolge stark verschleiern, sei + also nicht erstaunt, wenn es Dir schwer lesbar vorkommt. Ein + gebräuchlicher Trick ist es, "xorl %eax, %eax" anstelle des + intuitiveren "movl $0, %eax" zu verwenden, um das %eax Register + zu löschen. Warum? Weil die Instruktion kleiner ist und so + weniger Speicher verwendet und deshalb den icache der CPU + effektiver nutzt.
Die Disassemblierung nativer Windows DLLs ist in fast allen + Fällen nutzlos. Disassemblierung wird normalerweise als + Technik genutzt um herauszufinden, warum die Anwendung in einem + sonst nicht erklärbaren Fall abstürzt.

+ +

Der wineserver

+ +

Was ist der wineserver? Einfach ausgedrückt ist er das + Äquivalent des Kernels in einem echten Windows-System. Er + ist der zentrale Nexus eines emulierten Windows-Systems: alle + Win32-Prozesse, die unter dem gleichen User laufen, verbinden + sich mit der diesem User zugeordneten Kopie des wineservers. + Ein Beispiel für einen Zustand, den mehrere Win32 Programme + teilen sollten, ist der Zustand der Registry. Das Erstellen oder + Ändern eines Keys in der Registry wird sofort in der Sicht + der Registry jedes anderen Prozesses wiedergespiegelt. Unter + Windows passiert das, weil die Registry eine große + Datenbank ist, die im Kernel-Speicherbereich gehalten wird. + Unter Wine werden Zugriffe auf die Registry in Remote Procedure + Calls auf den Server konvertiert, der die Stammkopie der + Datenbank hält. +

+ +

+ Die Kommunikation mit dem Server läuft über ein + einfaches selbstentwickeltes RPC-Protokoll. Die Definiton des + Protokolls kann in server/protocol.def gefunden + werden. Diese Datei wird genutzt, um andere zu generieren; + jedes Mal, wenn die Generierung neu ausgeführt wird, wird + die Protokollversion erhöht. Wine weigert sich zu starten, + wenn die Server- und Client-Protokollversionen nicht + übereinstimmen. Wenn Du das Protokoll veränderst, + musst Du das komplette Projekt neubauen. Einen wineserver-Aufruf + kannst Du sehen, wenn Du mit grep nach SERVER_START_REQ suchst. +

+ +

+ Hier ist ein kurzer Abriss einiger der Aufgaben des wineservers: + Nachrichtenzustellung, die Registry, Debugging API, Synchronisation, + ein Teil des Fenstermanagements, Thread-Verfolgung, Manipulation von + Regionen. In der Zukunft wird er noch viel mehr Aufgaben + übernehmen (der Windows-Kernel hat sehr viele Aufgaben). +

+ +

DLL-Einteilung

+ +

Wine war ursprünglich nach Themengebieten organisiert, + so dass jeder zusammengehörige Bereich von APIs sein + eigenes Verzeichnis hatte. Leider hat sich das nicht gerade + gut bewährt, da Windows selbst eher schlecht organisiert + ist, insbesondere in den älteren Bereichen. Hier ist nun + eine Übersicht darüber, wo der wichtigste Quellcode + zu finden ist. In der Datei DEVELOPER-HINTS findest Du einen + Einzeiler als Beschreibung für jede DLL. + +

NTDLL - Der Kern des Windows-Systems. Diese DLL existiert + unter Windows 9x nicht, sie existiert nur unter Windows + NT/2000/XP. Im echten Windows-System ist sie nur wenig mehr + als eine Unterlegscheibe zwischen dem User- und dem Kernel-Bereich, + aber unter Wine dient sie hauptsächlich als Schnittstelle + entweder zum wineserver oder zum darunterliegenden Unix-Kernel. + Sie enthält außerdem Dinge wie den PE (EXE/DLL-Format) + dynamischen Linker.
KERNEL32 - Unter NT leiten viele dieser Aufrufe einfach + an NTDLL weiter. Unter Windows 9x ist der Hauptteil des Codes + aus der NTDLL hier zu finden. Der Gedanke hinter dieser + Aufteilung war der, dass NT in der Lage sein sollte, mehrere + Module für verschiedene Betriebssystem-APIs + unterstützen zu können, d.h. es hätte ein + POSIX-Modul und ein OS/2-Modul geben können und kernel32 + wäre das Win32-Modul gewesen. In der Praxis hat + Microsoft die Konkurrenz so effektiv ausgelöscht, dass + diese Abstraktion niemals wirklich gebraucht oder benutzt + wurde. Deshalb ist die NT kernel32 DLL heutzutage + hauptsächlich eine Ansammlung von Weiterleitungen. In + Wine ist die Migration des Codes von kernel32 zur ntdll noch + nicht abgeschlossen, deshalb haben wir eine relativ + gleichmäßige Aufteilung.
USER32 - Der "User"-Code ist für den Hauptteil des + Kerns des Window-Managements / der Nachrichtenzustellung + zuständig, sowie verschiedenste andere Dinge wie die + Zwischenablage, Netzwerkunterstützung und eine + Implementierung von wsprintf. Ursprünglich war + user32 die Windows API, bis sie genug gewachsen war, dass + es Sinn machte, mehrere DLLs zu haben. Daher die eher + seltsame und unzusammenhängende Sammlung von Code in + dieser DLL. Grundlegend kann man sagen, dass die sehr alten + Mechanismen, die zur Windows 3.1 Ära zurückdatieren, + eher hier oder in kernel32 zu finden sind.
OLE32, OLEAUT32, RPCRT4 - Hier sind COM und DCOM + implementiert.

+ +

Häufige Probleme

+ +

Einige Fehler sind einfacher zu beheben als andere. Hier ist eine + kurze Übersicht über die hartnäckigeren so dass Dir + klar ist, worauf Du Dich einlässt:

+ +

+ Alles, was mit DCOM/Marshalling zu tun hat, ist relativ verzwickt + und aller Wahrscheinlichkeit nach nichts, was schnell behoben + werden kann. Es gibt einige Hacks in unseren mitgelieferten DLLs + um InstallShield zufriedenzustellen, weil das das gebräuchlichste + Programm ist, das DCOM-Funktionalität benötigt. Falls du hier + etwas änderst, dann stelle sicher, dass du erst mit einigen + InstallShields testest.
+
+ Fenster, die den Tastaturfokus nicht annehmen (typisches + Symptom: Deine Eingaben gehen ans Terminal) sind aus + irgendeinem Grund auf unmanaged gestellt worden. Jeder + Fenstermanager kann das unterschiedlich handhaben, aber die + häufigste Variante ist, dass das Fenster ständig im + Vordergrund steht, auf jeder Arbeitsfläche erscheint und + den Fokus nicht annehmen kann. Manchmal ist das erwünscht: + bei Menüs und Tooltipps soll das so sein. Meistens ist es + das jedoch nicht. Managed versus unmanaged ist ein + eher schwieriges Problem, frag auf der wine-devel Liste nach + Unterstützung falls Du die Heuristik dafür + ändern willst.
+
+ Ein Programm stürzt mit der mitgelieferten comctl32 ab, + funktioniert jedoch mit der nativen: Das kann häufig ein + Hinweis auf eine fehlende Benachrichtigung oder einen fehlenden + Callback sein, oder auf eine gestörte Nachrichtenreihenfolge. + Die meisten GUI-Anwendungen sind sehr sensibel was ihre + Callback-Reihenfolge angeht, und wenn ein Callback gar nicht + oder außerhalb der Reihenfolge ausgeführt wird, + initialisieren einige Programme interne Strukturen nicht + ordentlich, was zu einem Absturz zu irgendeinem Zeitpunkt in der + Zukunft führt. Die Lösung? Schreibe Testfälle, die + beweisen, dass die Nachrichtenreihenfolge richtig (oder falsch) + ist - es gibt Beispiele dafür in den user32-Tests.
+
+ Ein Fehler, der von Wine auf stderr ausgegeben wird, der + RtlpWaitForCriticalSection erwähnt, deutet + auf eine Deadlock-Situation hin. Gelegentlich kann dies mal ein + Fehler in der Anwendung sein, meistens ist es jedoch ein Fehler + in Wine. Wenn ein Programm in einer kritischen Sektion in eine + Deadlock-Situation gerät, ist es eine gute Idee, sich mit + Winedbg daranzuhängen und sich einen Backtrace aller + Threads zu holen. Falls Du nicht weißt, wovon ich hier + gerade spreche, dann lies den Abschnitt über Threading + im Wine-Entwicklerhandbuch. +

diff --git a/templates/de/download.template b/templates/de/download.template index 03e939c..b59990e 100644 --- a/templates/de/download.template +++ b/templates/de/download.template @@ -214,6 +214,6 @@ für Informationen zu den Schritten, die nach der Installation auszufüh

- Benutze dieses Bild, wenn du zu unserer Download-Seite verlinken willst. + Benutze dieses Bild, wenn Du zu unserer Download-Seite verlinken willst.

-- 1.6.0.5