Vorheriges Kapitel () | Nächstes Kapitel () |
Die umfassendste Ressource für die Win32-Programmierung ist das Internet.
Und im Vergleich der Dokumente zu verschiedenen Assemblern schneidet der MASM
weit besser ab als der TASM. Deshalb habe ich mich entschlossen, im Laufe dieses
Tutorials den MASM zu behandeln. Im MASM-Modus von TASM sind die vorgestellten
Programme nicht kompilierbar.
Bei den einschneidensten Unterschieden zwischen TASM und MASM werde ich ein paar kurze
Erläuterungen geben. Aber da die Unterschiede zwischen den beiden Assemblern nicht so
groß sind, wird das Verständnis der Quelltexte für den TASM-Programmierer kein
Problem darstellen.
Voraussetzung für dieses Tutorial ist natürlich die Kenntnis der Sprache Assembler für
Prozessoren der x86-Familie.
Bei allen weiteren Ausführungen beziehe ich mich auf das Programmpaket MASM32, das Sie unter anderem unter der URL http://win32asm.cjb.net kostenlos mit einer Reihe von Beispielprogrammen und Tutorials downloaden können.
Der Windows-Kern kennt drei Darstellungsformen: Win16, Win32 und Win32s.
Win16 ist der Kern von 16-Bit-Windows wie Windows 3.1, Windows 3.11 etc.
Win32 ist entsprechend der Kern von 32-Bit-Windows. Dazu zählen alle Windows-Varianten
seit Windows 95 einschließlich Win NT, Windows CE und Win 2000.
Dabei unterstützen diese verschiedenen Versionen den Win32-Kern in unterschiedlicher
Konsequenz. In Win95 und Win98 ist zum Beispiel die Unicode-Unterstützung nicht so
ausgeprägt wie unter Windows NT. Bei Windows CE, einem Betriebssystem für Pocket Computer
sind eine ganze Reihe von Funktionen abgeschaltet, da hier ein besonders schlanker
Kern benötigt wird.
Win32 läuft nur auf Prozessoren ab dem 80386.
Win32s stellte den Versuch dar, einen Teil der 32-Bit-Welt in die 16-Bit-Windowsversionen
einfließen zu lassen. Hier wurde durch eine zusätzliche DLL die Umwandlung der
Adressierung von 32 Bit auf 16 Bit vorgenommen.
In diesem Tutorial wird ausschließlich die Win32-Programmierung behandelt.
Alle Windows-Versionen, die auf dem 32-Bit-Kern basieren, laufen im Protected Mode.
Win32 kennt nur noch ein einziges Speichermodell: FLAT.
Jedem Programm wird die virtuelle Speichermenge von 4 GB zur Verfügung gestellt.
In diesem einen Segment befinden sich sowohl Code als auch Daten des Programms.
Die Adressierung erfolgt über die 32-Bit-Register des Prozessors. Da damit bereits
4 GB Speicher adressiert werden können, entfällt das Jonglieren mit Segmenten.
Die Kommunikation mit dem Betriebssystem erfolgt nicht wie unter DOS über Interrupts,
sondern über Funktionen, die vom Windows-API (Application Programming Interface) zur
Verfügung gestellt werden.
Abgesehen von einer Funktion gibt es für die Funktionen nur noch eine verbindliche
Aufrufkonvention: STDCALL. Dies ist eine Mischform der Aufrufkonventionen C und Pascal.
Bei der C-Aufrufkonvention werden die Parameter von rechts nach links auf den Stack
gelegt und der Aufrufer muss den Stack bereinigen. Bei Pascal ist es genau umgekehrt:
die Parameter von links nach rechts auf den Stack und die Prozedur bereinigt den Stack.
Bei STDCALL werden die Parameter von rechts nach links auf den Stack gelegt, aber die
aufgerufene Funktion ist für die Stackbereinigung verantwortlich. Die einzige Funktion,
bei der die C-Aufrufkonvention verwendet werden muss, heißt wsprintf (wsprintf() kann
erhält eine variable Parameteranzahl verarbeiten, weiß aber nicht im Voraus wieviele
es sein werden und kann daher auch nicht die Stackbereinigung vornehmen).
Bei der Programmierung in Windows ist zu beachten, dass Windows intern die Register
EBX, EDI, ESI und EBP verwendet. Sie können diese Register in Ihren Prozeduren verwenden,
sollten aber darauf achten, dass die Inhalte dieser Register nach dem Funktionsaufruf
die gleichen wie vor dem Funktionsaufruf sind.
Ein mögliches Rahmenprogramm könnte so aussehen:
.386 .MODEL FLAT, STDCALL .DATA .DATA? .CONST .CODE label END label |
msg db 10000 dup (?)
sorgt dann dafür, dass zur Laufzeit diese
Speichermenge zur Verfügung gestellt wird, macht die EXE-Datei aber nicht um 10000 Byte
größer.
Anders als unter DOS läuft die Kommunikation mit dem Betriebssystem nicht über Interrupts sondern über Funktionsaufrufe. Die wichtigsten dieser Funktionen befinden sich in den Dateien user32.dll, kernel32.dll und gdi32.dll. Diese Dateien stellen die grundsätzliche Schnittstelle zu Windows zur Verfügung. Durch weitere DLLs kann dieses API (Application Programming Interface) erweitert werden.
Bei der Verwendung der API-Funktionen kommen jede Menge Strukturen und Konstanten zum Einsatz. Bei MASM32 werden diese Angaben hauptsächlich in der Datei windows.inc hinterlegt. Diese Datei unterliegt einer ständigen Pflege und Erweiterung durch die beiden Hauptautoren von MASM32.
Desweiteren sollte eingestellt werden, dass der Quelltext case-sensitiv kompiliert wird. In der Normaleinstellung sind die beiden Bezeichner hwnd und HWND identisch. Unter Windows ist HWND ein Datentyp (Handle eines Fensters). Oftmals wird die Variable dieses Typs hwnd genannt, was bei nicht case-sensitiver Interpretation zwangsweise zu Problemen führt. Dieses Vorgehen ist an vielen anderen Stellen identisch.
Im Gegensatz zu DOS kommuniziert auch das Betriebssystem mit dem Programm. Dabei sendet Windows an das Programm zu jedem auftauchenden Ereignis (Mausbewegung, Tastendruck, Menüpunktauswahl etc) in einer Endlosschleife eine Nachricht. Es gibt eine ganze Reihe von Nachrichten, die in windows.inc als Konstanten verfügbar sind.
In MASM32 wird sehr viel mit Funktionsprototypen gearbeitet. Gleichzeitig bietet MASM32 mit der Anweisung invoke
das notwendige Mittel, um einen Funktionsaufruf gegen seinen Prototypen abzugleichen. Die Prototypendefinitionen für die einzelnen DLL-Funktionen liegen in Include-Dateien, die vom Dateinamen die Beziehung zur DLL erkennen lassen (kernel32.inc, gdi32.inc etc). Diese Dateien müssen selbstverständlich vor Verwendung der entsprechenden Funktion ins Programm eingebunden sein.
Vorheriges Kapitel () | Nach oben | Nächstes Kapitel () |
Zum Inhaltsverzeichnis | ||
Zur Startseite |