Umstieg auf PB Win für Dossies Teil (6) Was hat sich eigentlich verändert

Zum einen der Aufbau.
Jetzt heißt es halt PBMain oder WinMain (evtl. mit Funktionsparametern). Dieser Kopf wird für Windows als Einsprung genutzt, d.h. hier wird mit der Abarbeitung des PB Win Programms begonnen. Die Parameter werden von Windows an das PB Win Programm geliefert. So u.a.

hInstance
Handle bzw. Index für das Programm (unter Windows als Multitasking laufen halt mehrere Programme, diese müssen über Ihre Indizes unterschieden werden)

hPrevInst
Da unter Windows im Gegensatz zu DOS das gleiche Program mehrmals aufgerufen werden kann, wird unter hPrevInst das Handle der zuletzt aufgerufenen Sitzung angegeben. Das bedeutet: ist der Wert von hPrevInst 0 so handelt es sich um den ersten Aufruf des Programms. Ist es ungleich 0 so kann man die Meldung „Programm läuft bereits“ ausgeben (falls gewünscht) und das Programm (also das was nochmal also zuviel aufgerufen wurde) wieder beenden. Oder aber man läßt es zu, daß das Programm mehrmals läuft.

lpszCmdLine
Ein Pointer (Zeiger) auf einen ASCIIZ String wo alles steht, was hinter dem *.exe Dateinamen bei Aufruf aus einer Commandzeile noch steht. Beispiel: „test.exe Hallo“; Dadurch wird das Programm test.exe gestartet und in lpszCmdLine steht die Adresse der Speicherstelle, wo der Zusatz, in diesem Fall Hallo der hinter test.exe eingegeben wurde zu finden ist. Dieses erhält man aber auch über den in PB eingebauten Befehl command$.

nCmdShow
ein LONG Zahlenwert der eine Aussage darüber macht, wie der Benutzer, welcher die *.exe Datei aufgerufen hat, das Programm angezeigt haben will. Als normales Fenster, als maximiertes Fenster, als Ikone usw.
Hier wird also bspw. bei Windows Programmen, welche über ein Icon z.B. vom Desktop aus gestartet werden, der Wert übergeben, den man unter Eigenschaften zu der Ikone eintragen kann (unter dem Reiter Programm – Ausführen als)

Was ist Neu ?

Eigentlich nur die sog. Callbacks.
Callbacks sind lediglich Funktionen bzw. Subs innerhalb des eigenen Programms, welche von Windows aufgerufen werden. Dies ist aber quasi gleichzusetzen mit einem extern ausgelösten IRQ unter DOS. Die Callback Routine stellt somit die IRQ Routine dar, welche durch das Auslösen des Interrupts früher aufgerufen wurde, sich jedoch nun innerhalb des eigenen Programms als Function bzw. Sub Routine befindet anstelle früher über die IRQ Tabelle an einer bestimmten separaten Speicheradresse zu befinden. Genauso ruft Windows nun die als Callback definierte Function auf (jedoch nicht ausschließlich aufgrund eines Hardware Ereignisses sondern auch zu anderen Anläßen).

Ansonsten hat sich nur die Art und Weise geändert. Als ich angefangen habe mich mit den Besonderheiten um Windows zu beschäftigen, dachte ich zunächst es sei alles ganz anders als früher. Hat man jedoch erst einmal verstanden wie Windows arbeitet, so erkennt man, daß eigentlich alles so ist wie früher.

Statt eigene Interrupt Aufrufe beim DOS bzw. BIOS durchzuführen, um die ein oder andere Funktion ausführen zu können, ruft man unter Windows die entsprechende API Funktion auf (entweder als Function mit Rückgabewert oder auch als Sub falls der Rückgabewert nicht erforderlich ist).

Direkte Zugriffe auf Hardware mittels in/Out oder eben Int sind jedoch nicht mehr so ohne weiteres möglich und auch nicht erwünscht. Der Grund dafür ist erneut das Multitasking. Es kann nur einen Koch geben, der alle Ereignisse überwacht und steuert und das ist halt Windows. Würde ein Programm direkt auf Hardware zugreifen, von dem Windows keine Kenntnis hat oder umgekehrt, mein Programm mit direktem Hardwarezugriff hat wiederrum keine Kenntnis darüber wann Windows die gleiche Hardware plötzlich neu initialisiert oder abfragt, dann kann das nur zum Chaos führen. Deshalb sind hier spezielle Treiberprogramme nötig. Nur die können direkt diese Hardware ansprechen. Diese Treiberprogramme stellen wiederrum Funktionen (API) als Schnittstelle zur Verfügung anstelle der In/Out und Int Befehle von früher.

Message Pump
Auch dieses ist nichts wirklich neues. Es ist eigentlich gleichzusetzen mit der ehemaligen Inkey$ Abfrage. Auch hier hat man unter DOS eine Schleife geschrieben, die solange wiederholt wurde, bis der Benutzer eine Taste gedrückt hat oder eine Mausbewegung auslöste (oder eben alternativ hat man ab und zu mal abgefragt ob eine Taste gedrückt wurde und zwischendurch andere Aufgaben durch das Programm erledigen lassen). So wird auch unter Windows über GetMessage (früher inkey unter DOS) die nächste anliegende Botschaft (früher Tastenereignis bei DOS) abgerufen. Der Inhalt der Botschaft wird jedoch bei GetMessage zunächst übersetzt (TranslateMessage) und zu der entsprechenden WindowProcedure (die entsprechende Bearbeitungsfunktion) mittels DispatchMessage gesendet. Durch den Befehl DispatchMessage wird Windows veranlaßt, den Inhalt der nächsten anliegenden Mitteilung bzw. Ereignisses aus der Warteschlange (früher Tastaturpuffer unter DOS) an diese Funktion zu übermitteln und zwar mittels Callback. Das heißt die WindowProcedure Funktion befindet sich in dem eigenen Programm wird aber von Windows aus aufgerufen. Bei diesem Aufruf wird der Funktion entsprechend die Parameter von Windows übergeben, die den Inhalt des Ereignisses entsprechen. Dieser Inhalt ist natürlich umfangreicher als früher der bloße Code der gedrückten Taste. Denn es werden nun auch mehr Ereignisse erfaßt als früher u.a. Tasten, Mauspositionen, das Verhalten der Fenster von anderen Programmen, Timer Ereignisse, usw.

Was sich für den Programmierer unter Windows verschlechtert hat ist zum einen die dürftige API Dokumentation (alles muß man sich teilweise recht mühsam zusammensuchen) und die enorme API Vielfältigkeit. Geradezu erschlagen wird man von den vielen zur Verfügung stehenden Funktionen und den dafür erforderlichen Datentypen und Strukturen in denen die Daten für die Funktionen oder die Ergebnisse der Funktionen zur Verfügung gestellt werden.

--------------------
KPA

Extras: