Windows stellte in früheren Versionen nur einen Betriebssystem-Aufsatz dar, der dem Anwender IBM-kompatibler Personal-Computer eine graphische Benutzeroberfläche zur Verfügung stellte. Entwickelt von der Firma Microsoft, wies Windows schon damals entscheidende Merkmale wie standardisierte, konsistente Programmoberfläche, die Möglichkeit zur gleichzeitigen Ausführung mehrerer Anwendungen und die Bereitstellung geräteunabhängiger Schnittstellen auf. Eine für Programmierer frei zugängliche Schnittstelle, das Windows-API (Application Program Interface), stellt sich aus der Sicht eines Entwicklers als eine sehr umfangreiche Funktions-Bibliothek dar. Erst die Möglichkeit des Zugriffs auf eine derartige Bibliothek schafft die Voraussetzung dafür, daß Windows-Programme ein einheitliches Aussehen und prinzipiell gleichartiges Verhalten aufweisen.
Das ursprünglich auf 16-bit-Technologie beruhende API wurde von Microsoft weiterentwickelt und unter der Kurzbezeichnung "Win32" in verschiedenen Windows-Versionen integriert. In einem von dieser Firma neu entwickelten Betriebssystem, "Windows NT" genannt, wurde es am überzeugendsten implementiert.
Jedes Win32-Programm läuft in einem separaten 32-bit Adreßraum ab. Die Adreßräume einzelner Programme sind vollständig voneinander getrennt, so daß gewollte oder ungewollte Zugriffe auf Adreßbereiche fremder Programme strikt unterbunden werden. Das Win32-API trifft auf große Akzeptanz in der Industrie; selbst zu Windows NT konkurrierende Betriebssysteme, wie etwa IBMs OS/2, integrieren mittlerweile das Win32-API bei sich (bei OS/2 unter dem Namen "Open32").
Das Win32-API setzt sich aus verschiedenen Funktionsgruppen zusammen:
Die Fensterverwaltung ist für die Erzeugung und Verwaltung von Fenstern zuständig und weist eine ereignisgesteuerte Architektur auf. Eingaben eines Benutzers lösen Ereignisse aus. Das System sendet einer Anwendung die sie betreffenden Ereignisse in Nachrichten-Form. Jede 32-bit Anwendung besitzt eine private Warteschlange (Message-Queue), in der das System alle Nachrichten ablegt (asynchronous input model). Anwendungen lesen diese Warteschlange kontinuierlich aus und können selbst entscheiden, wie sie, bzw. ob sie überhaupt, auf die so zugestellten Nachrichten reagieren wollen.
Windows identifiziert alle im System vorhandenen Fenster durch sogenannte Window-Handles (Typ Hwnd). Generell stellen Handles nur Kennungen dar (32-bit Zahlen), die das System bei der Erzeugung von Windows-Objekten zurückliefert. Handles repräsentieren die ihnen zugrunde liegenden Windows-Objekte.
Aussehen und Verhalten von Standardfenstern kann vom Programmierer verändert werden. Generell veränderte Fenster können im System als neue Fensterklasse angemeldet werden. Das Win32-API stellt bereits standardmäßig eine ganze Anzahl registrierter Fensterklassen zur Verfügung: Schalter (Buttons), Eingabe-Felder (Edit-Fields), ComboBoxen, ListBoxen, ScrollBars, Static-Fenster (zum Anzeigen von Text und Graphik).
Durch das GDI (Graphics Device Interface) werden Funktionen zur Verfügung gestellt, die der Grafikausgabe auf Bildschirm, Drucker oder Metadatei dienen. Grafikausgaben erfolgen stets auf einem Geräte-Kontext (Device Context = DC). Ausgaben in Geräte-Kontexte von Fenstern sollten im allgemeinen nur als Reaktion auf das Auftreten ganz bestimmter Nachrichten (wie WM_PAINT oder WM_NCPAINT) erfolgen.
Die System-Funktionen gestatten Anwendungen den Zugriff auf Ressourcen, die in engem Zusammenhang mit dem Betriebssystem stehen. Dazu zählen der Zugriff auf Speicher, Dateisystem und Prozesse. Jedes laufende Programm stellt einen Prozeß dar. Beim Starten eines Prozesses wird vom System ein Primär-Thread erzeugt, der seinerseits eigene Threads erzeugen kann. Windows NT teilt die zur Verfügung stehende Rechenzeit zwischen allen im System angemeldeten Threads auf. Im Multiprozessor-Betrieb ist echte Parallelverarbeitung möglich; im Einprozessor-Betrieb findet eine Quasi-Parallelabarbeitung statt. Jeder Prozeß besitzt einen 4 GByte großen, virtuellen Adreßraum. Alle Threads eines Prozesses besitzen einen eigenen Stack innerhalb dieses Adreßraums. Die Threads eines Prozesses können gemeinsam und gleichzeitig auf globale und static-Variable des Programms zugreifen. Damit der Zugriff auf nur begrenzt vorhandene Ressourcen (wie z.B. globale Variablen) aus den Threads heraus kontrolliert erfolgt, bietet das Win32-API mehrere Möglichkeiten zur Synchronisation an: Kritische Bereiche, Mutex-Objekte, Semaphoren und Ereignisse.
Thread-lokale Variable werden im lokalen Thread-Stack angelegt und sind dadurch vor unerwünschten Zugriffen geschützt.
Es ist in Windows möglich, dynamisch ladbare Bibliotheken (DLL = Dynamic Link Libraries) zu entwickeln. Mit ihrer Hilfe lassen sich eigene APIs erstellen, die anderen Programmen zur Verfügung gestellt werden können. DLLs beinhalten hauptsächlich Funktionen und Windows-Ressourcen (Strings, Menüs, Dialoge, Bitmaps, Icons usw.) und können von beliebig vielen Prozessen gleichzeitig benutzt werden. Sobald eine DLL in den Adreßraum eines Prozesses eingeblendet ist, stehen die Funktionen und Ressourcen sämtlichen Threads dieses Prozesses zur Verfügung.
Das Entwickeln graphisch orientierter Windows-Programme ist bei der Verwendung herkömmlicher Sprachen (z.B. von C) sehr aufwendig. Bereits beim Schreiben weniger komplexer Anwendungen entstehen relativ lange Quelltexte. Durch die langen Code-Sequenzen wird der Programmtext schnell unübersichtlich, so daß sich leicht Fehler einschleichen können. Der Einsatz objektorientierter Sprachen und geeigneter Klassenbibliotheken soll dabei helfen, die Komplexität des Window-APIs zu verbergen, ohne daß man jedoch auf dessen große Funktionalität verzichten müßte. Man hofft, durch den Einsatz von Klassenbibliotheken, Entwickler von immer wiederkehrenden Routine-Aufgaben (wie z.B. dem Subclassing einzelner Fenster-Elemente) befreien zu können. Übersichtlicherer, klar strukturierter Code soll zur Senkung der Fehlerrate beitragen.
Anmerkung: Das Win32-API beruht intern auf ANSI-C und ist nicht objektorientiert realisiert worden. Vererbungsmechanismen und virtuelle Funktionen werden von ihm nicht unterstützt. Die in dem Zusammenhang auftretenden Begriffe Klasse (z.B. bei Fenster-Klasse) und Objekt (z.B. bei Zeichenobjekt) haben nichts mit den bei der objektorientierten Programmierung verwendeten Begriffen zu tun.
|
|
|
|
|