WikiDer > Windows-API

Windows API
Übersetzungshilfe angefordert. Dieser Artikel kann (Sprach-)Fehler enthalten.
Sie können diesen Artikel verbessern. Weitere Informationen finden Sie auf der Diskussionsseite oder der Übersetzungsseite.

Das Windows-API, mit anderen Worten Programmierschnittstelle, ist eine Reihe von APIs, die BetriebssystemFenster zur Verfügung hat. Früher hieß es Win32-API. Der Name Windows API ist jedoch eine bessere Beschreibung angesichts der Unterstützung für aktuelle 64-Bit-Windows-Versionen. Fast alle Windows-Programme sind in die Windows-API integriert.

Ein Softwareentwickler kann die Microsoft Windows-SDK (Software Development Kit), das Dokumentation und Tools zur Verwendung der Windows-API und anderer Windows-Technologien bereitstellt.

Überblick

Die Bedienung der Windows API lässt sich in 8 Kategorien einteilen:

Grundversorgung
Sie bieten Zugriff auf die grundlegenden Ressourcen, die einem Windows-System zur Verfügung stehen. Einige Beispiele sind Dateisysteme, Hardware-, Prozesse, Faden oder Fehlerbehandlung. Diese Funktionen sind in den Dateien Kernel.exe, krnl286.exe oder krnl386.exe für ein 16-Bit-Windows und die Datei kernel32.dll auf 32-Bit-Windows-Versionen.
Erweiterte Dienste
Diese bieten Zugriff auf die Operation, die eine Ergänzung zu den Kernel. Einige Beispiele sind die Windows-Registrierung, das Starten oder Neustarten des Systems, das Starten/Beenden/Erstellen eines Windows-Dienstes und das Verwalten von Benutzerkonten. Diese Funktionen sind in der Datei advapi32.dll auf einem 32-Bit-Windows.
Schnittstelle für Grafikgeräte
Ermöglicht die Anzeige von grafischen Inhalten auf Monitoren, Druckern und anderen Ausgabegeräten. Diese Schnittstelle befindet sich in gdi.exe auf einem 16-Bit-Windows und in gdi32.dll auf einem 32-Bit-Windows im Benutzermodus. Kernel-Mode-GDI-Unterstützung wird bereitgestellt von win32k.sys, die direkt mit dem Grafiktreiber kommuniziert.
Grafische Benutzeroberfläche
Bietet die Funktionalität zum Erstellen und Verwalten von Fenstern und die meisten grundlegenden Operationen wie Schaltflächen, Bildlaufleisten, Empfangen von Maus- und Tastatureingaben und andere Operationen im Zusammenhang mit dem GUI-Teil von Windows. Diese Funktion befindet sich in user.exe auf einer 16-Bit-Windows-Version und in user32.dll auf einem 32-Bit-Windows. Schon seit Windows XP die Grundoperationen sind in comctl32.dll, zusammen mit den allgemeinen Steuerelementen (Common Control Library).
Bibliothek für allgemeine Dialogfelder
Bietet die Standarddialogfelder zum Speichern von Dateien, Auswählen von Farbe und Schriftart usw. Die Bibliothek steht in der Datei commdlg.dll auf einem 16-Bit-Windows und comdlg32.dll auf einem 32-Bit-Windows. Die Bibliothek fällt unter die Kategorie Benutzeroberfläche der API.
Common Control Library
Ermöglicht Anwendungen den Zugriff auf einige erweiterte Funktionen des Betriebssystems. Zum Beispiel Statusleisten, Menüleisten und Registerkarten. Diese Bibliothek befindet sich in a DLL-Datei das comctrl.dll heiß in einer 16-Bit-Windows-Version, oder comctl32.dll auf einer 32-Bit-Windows-Version. Die Bibliothek fällt unter die Kategorie Benutzeroberfläche der API.
Windows-Shell
Eine Komponente der Windows-API, die es Anwendungen ermöglicht, die Funktionen zu verwenden, die die Schale des Betriebssystems ansprechen, wenn sie sich ändern und verbessern. Dieser Teil befindet sich in shell.dll auf einer 16-Bit-Windows-Version und in shell32.dll auf einem 32-Bit-Windows. Die Shell Lightweight Utility-Funktionen befinden sich in der Datei shlwapi.dll. Diese Komponente ist auch unter der Kategorie Benutzeroberfläche der API gruppiert.
Netzwerkdienste
Bieten Sie Zugriff auf die verschiedenen Netzwerkfunktionen des Betriebssystems. Seine Unterkomponenten umfassen NetBIOS, Winsock, NetDDE, RPC.

Netz

Das WebbrowserInternet Explorer kann auch als Teil der Windows-API angesehen werden, da sie mehrere APIs bereitstellt, die häufig von anderen Anwendungen verwendet werden. Internet Explorer seit der zweiten Auflage von . im Betriebssystem enthalten Windows 98 und bietet webbezogene Dienste für Anwendungen seit Windows 98. Genauer gesagt wird es verwendet:

  • als einbettbares Webbrowser-Control (in shdocvw.dll und mshtml.dll)
  • als URL-Überwachungsdienst (in urlmon.dll), die COM-Objekte für Anwendungen bereitstellt, die URL's Verarbeitung
  • Bereitstellung von Bibliotheken, die mehrsprachige und internationale Texte unterstützen (mlang.dll)
  • vor dem DirectXTransformationen, eine Reihe von Bildfilterkomponenten
  • vor dem XMLUnterstützung (die MSXML-Komponenten sind in der Datei msxml*.dll)

Multimedia

Microsoft bietet seit Windows 95 OSR2 jede Windows-Installation des DirectXAPIs. DirectX bietet eine lose verwandte Reihe von Multimedia- und Spielediensten, wie zum Beispiel:

  • Direct3D für hardwarebeschleunigte Grafik
  • Direkt zeichnen für hardwarebeschleunigten Zugriff auf den 2D-Framebuffer. Schon seit DirectX 9 dieser Komponente musste weichen Direct3D, die allgemeinere Hochleistungsgrafiken bietet (da 2D-Rendering Teil des 3D-Renderings ist)
  • DirectSound um auf ein hardwarebeschleunigtes Low-Level zuzugreifen Soundkarte
  • Direkteingabe zur Kommunikation mit Eingabegeräten wie Joysticks und Spielpads
  • DirectPlay wenn MehrspielerGaming-Infrastruktur. Diese Komponente ist seit DirectX 9 veraltet und Microsoft empfiehlt ihre Verwendung nicht mehr für die Spieleentwicklung
  • Direkt zeigen die generische Multimedia-Pipelines erstellt und ausführt. Es ähnelt dem Gstreamer-Framework und wurde oft verwendet, um In-Game-Videos zu rendern und Mediaplayer zu erstellen (Windows Media Player basiert darauf). DirectShow wird nicht mehr für die Spieleentwicklung empfohlen
  • DirectMusic von MIDIAbspielen von Dateien, aber das ist veraltet

Programminteraktion

Die Windows-API beschäftigt sich hauptsächlich mit der Interaktion zwischen den Betriebssystem und eine Bewerbung. Für die Kommunikation zwischen den verschiedenen Windows-Anwendungen hat unter sich Microsoft eine Reihe von Technologien, die zusätzlich zur Haupt-Windows-API entwickelt wurden. Dies begann mit Dynamic Data Exchange (DDE), das durch Object Linking and Embedding (OLE) und später durch das Component Object Model (COM), Automation Objects, ersetzt wurde. ActiveX Kontrollen und die .GERADERahmen. Es gibt nicht immer eine klare Unterscheidung zwischen diesen Technologien und sie überschneiden sich oft.

Die Begriffsvielfalt ergibt sich vor allem aus der Gruppierung von Softwaremechanismen, die sich mit einem bestimmten Aspekt der Softwareentwicklung befassen. Automatisierung insbesondere damit zu tun hat, den Betrieb einer Anwendung oder Komponente (als API) zu exportieren, damit sie von einer anderen Anwendung oder einem menschlichen Benutzer verwendet werden kann.

Wrapper-Bibliotheken

Microsoft hat mehrere Wrapper entwickelt, die einige der Low-Level-Funktionen der Windows-API übernahmen und es so Anwendungen ermöglichten, auf abstraktere Weise mit der API zu interagieren. Die Microsoft Foundation Class-Bibliothek (MFC) kapselt den Windows-API-Vorgang in C Klassen, die eine objektorientiertere Art der Kommunikation mit der API ermöglichen. Die Active Template Library (ATL) ist ein vorlagenorientierter Wrapper für COM. Die Windows Template Library (WTL) wurde als Erweiterung für ATL entwickelt und war als leichtere Alternative zu MFC gedacht.

Bemerkenswert sind auch einige Angebote von Borland. Die Object Windows Library (OWL) wurde als Konkurrenzprodukt von MFC veröffentlicht und bot einen ähnlichen objektorientierten Wrapper. Borland musste später der Visual Component Library (VCL) weichen, die in Objekt Pascal und beide im Delphi wenn C Baumeister ist vorhanden.

Die meisten Anwendungsframeworks für Windows kapseln (zumindest teilweise) die Windows-API. Daher sind sowohl die .GERADE-Rahmen, Java wenn alle anderen Programmiersprachen in Windows eine Wrapper-Bibliothek haben oder sind.Windows API Code Pack für Microsoft .GERADE Framework ist eine .NET-Wrapper-Bibliothek für die Windows-API.

In den 64-Bit-Windows-Versionen wird der gleiche Name für die DLLDateien.

Geschichte

Die Windows-API war schon immer ein großer Teil der zugrunde liegenden Struktur der Windows-Systeme dem Programmierer ausgesetzt. Dies gibt den Programmierern große Flexibilität und Macht über ihre Anwendungen. Es überträgt den Windows-Anwendungen jedoch auch eine große Verantwortung für die Verarbeitung verschiedener Low-Level-Operationen, die mit einer GUI verbunden sind.

Charles Petzold, Autor der viel gelesenen Windows-API-Bücher, sagte: "Das ursprüngliche "Hallo Welt"-Programm in der Windows 1.0-SDK war ein kleiner Skandal. HELLO.C war etwa 150 Zeilen lang und das Quellskript HELLO.RC hatte etwa 20 Zeilen. (...) Ältere C-Programmierer wanden sich oft vor Ekel oder Gelächter, wenn sie auf das Windows-Hello-World-Programm stießen."

Im Laufe der Jahre wurden mehrere Änderungen und Ergänzungen an Windows vorgenommenBetriebssystem, und die Windows-API hat dies geändert und widergespiegelt. Die Windows-API für Windows 1.0 unterstützte weniger als 450 Funktionsaufrufe, während moderne Versionen der Windows-API Tausende unterstützen. Insgesamt blieb die Benutzeroberfläche jedoch ziemlich konsistent; eine alte Windows 1.0-Anwendung wird für einen Programmierer, der an die moderne Windows-API gewöhnt ist, noch erkennbar sein.

Microsoft legt großen Wert darauf, Software abwärtskompatibel zu machen und zu halten. Um dies zu erreichen, unterstützt Microsoft manchmal sogar Software, die die API auf undokumentierte oder sogar (für den Programmierer) illegale Weise verwendet. Raymond Chen, ein Entwickler bei Microsoft, der an der Windows-API arbeitet, sagte: „Ich könnte wahrscheinlich monatelang nur über Anwendungen schreiben, die falsche Dinge tun und was wir tun mussten, um sie wieder zum Laufen zu bringen (deshalb werde ich sehr wütend, wenn Leute beschuldigen Microsoft, Anwendungen in böswilliger Absicht zu beschädigen Betriebssystem-Upgrades. Wenn auch nur eine Anwendung nicht mehr funktioniert Windows 95, ich habe das als persönliches Versagen empfunden."

Eine der größten Änderungen, die die Windows-API durchlief, war der Übergang von Win16 (zu finden in Windows 3.1 und älter) zu Win32 (Windows NT, Windows 95 und höher). Während Win32 ursprünglich mit eingeführt wurde Windows NT 3.1 und Win32s bereits die Verwendung der Win32-Teilmenge für Windows 95 erlaubte, begannen viele Anwendungen erst mit Windows 95, auf Win32 zu portieren. Um den Übergang zu erleichtern, verwendete Windows 95 ein komplexes Schema sogenannter "API-Thunks" sowohl für die Drittentwickler als auch für Microsoft, die es 32-Bit-Code ermöglichten, 16-Bit-Code aufzurufen und (in einigen Fällen) umgekehrt. So genannte „flache Thunks“ ermöglichten es 32-Bit-Code, 16-Bit-Bibliotheken aufzurufen, und das Schema wurde in Windows 95 ausgiebig verwendet, um zu vermeiden, dass das gesamte Betriebssystem auf einmal auf Win32 portiert werden muss. In Windows NT war das Betriebssystem nur 32-Bit (mit Ausnahme der Teile für die Kompatibilität mit 16-Bit-Anwendungen), und für den Thunk von Win16 bis Win32 sowie für Windows 95 waren nur "generische Thunks" verfügbar SDK enthalten einen Compiler, der den notwendigen Code für diese Thunks erzeugen könnte.

Versionen

Fast jede neue Version von Windows führte eigene Ergänzungen und Änderungen an der Windows-API ein. Der API-Name wurde jedoch zwischen den verschiedenen Windows-Versionen konsistent gehalten, und die Namensänderungen beschränkten sich auf größere strukturelle und Plattformänderungen von Windows. Microsoft änderte schließlich den Namen der damaligen 'Win32 API'-Familie in 'Windows API' und änderte damit den Namen in einen umfassenden Begriff sowohl für frühere als auch für zukünftige Versionen der API.

  • Win16 ist die API für die ersten 16-Bit-Versionen von Microsoft Windows. Sie wurde ursprünglich einfach als Windows-API bezeichnet, wurde jedoch später in Win16 umbenannt, um sie von der neueren 32-Bit-Version der Windows-API zu unterscheiden. Die Funktionen der Win16-API finden sich hauptsächlich in den Kerndateien des Betriebssystems: Kernel.exe (oder krnl286.exe oder krnl386.exe), user.exe und gdi.exe. Trotz der Ex-Datei Format dies sind tatsächlich dynamisch verbundene Bibliotheken.
  • Win32 ist die 32-Bit-API für moderne Windows-Versionen. Die API besteht aus Funktionen, die wie Win16 im System implementiert sindDLLDateien. Die Kern-DLL-Dateien von Win32 sind kernel32.dll, user32.dll und gdi32.dll. Win32 wurde eingeführt mit Windows NT. Die mitgelieferte Win32-Version Windows 95 hieß zunächst Win32c, wobei das "c" für "Kompatibilität" stand, aber Microsoft musste dem Namen "Win32" weichen.
  • Win32s ist eine Erweiterung für die Windows 3.1xFamilie von Microsoft Windows, die eine Teilmenge der Win32-API für diese Systeme implementiert hat. Das „s“ steht für „Teilmenge“.
  • Win32 für 64-Bit-Windows, früher bekannt als Win64, die Variante der API ist auf 64-Bit-Plattformen der Windows-Architektur implementiert. Es gibt keine neuen Benutzermodusfunktionen speziell für die 64-Bit-Plattform, sodass sowohl 32-Bit- als auch 64-Bit-Versionen einer Anwendung aus derselben Codebasis kompiliert werden können, obwohl einige ältere APIs zu veraltet sind. Alle SpeicherZeiger sind standardmäßig 64 Bit (das LLP64-Modell), daher sollte der Quellcode auf Kompatibilität mit 64-Bit-Zeigeroperationen überprüft und bei Bedarf neu geschrieben werden.

Andere Implementierungen

Obwohl die Implementierung der Windows-API von Microsoft patentiert ist, wird sie in der Vereinigte Staaten dass andere Anbieter Windows emulieren, indem sie eine identische API bereitstellen, ohne das Patent zu beschädigen.

Das Projekt Wein ist ein Versuch, eine Win32-API-Kompatibilitätsschicht für . zu erstellen UnixPlattformen. ReactOS geht noch einen Schritt weiter und implementiert das gesamte WindowsBetriebssystem und arbeitet eng mit dem wineproject zusammen, um Codekompatibilität und Codewiederverwendung zu fördern. DosWin32 und HX DOS-Extender sind weitere Projekte zur Emulierung der Windows-API, um einfache Windows-Programme vom DOS-Befehlszeile. Odin ist ein Projekt, das versucht, Win32 auf OS/2 zu emulieren.

Compiler-Unterstützung

Um Software zu entwickeln, die die Windows-API verwendet, muss ein Compiler in der Lage sein, die Microsoft-spezifische DLLDateien und COM-Objekte verarbeiten und importieren. Entweder muss der Compiler in der Lage sein, die Header-Dateien zu verarbeiten, die das Innere der API-Funktionsnamen offenbaren, oder er muss in der Lage sein, solche Dateien selbst bereitzustellen. Für bestimmte Anwendungsklassen muss das Compilersystem auch in der Lage sein, die Interface Definition Language (IDL)-Dateien zu handhaben. Zusammen werden diese Anforderungen (Compiler, Tools, Bibliotheken und Header) als die Microsoft-Plattform bezeichnet SDK. Lange Zeit die Microsoft Visual StudioFamilie von Compilern und Tools und die BorlandCompiler waren die einzigen Tools, die dies bieten konnten (doch im Fall von Windows war die SDK selbst kann separat vom gesamten heruntergeladen werden IDESuite aus dem Microsoft Platform SDK Update). Heute bietet es MinGW- und der CygwinProjekt auch eine solche Umgebung, basierend auf dem GNU-Compiler-Sammlung, die eine eigenständige Headerdateisammlung verwendet, um die Verknüpfung zwischen Microsoft-DLLs zu ermöglichen. LCC-Win32 ist ein CCompiler unter der Lizenz "Frei für nicht-kommerzielle Nutzung". Es wird von Jacob Navia gepflegt. Pelles C ist ein kostenloses C- Compiler gepflegt von Pelle Orinius. Frei Pascal ist eine GPL Objekt PascalCompiler, der Software schreiben kann, die auf der Windows-API basiert. MASM32 ist ein Projekt, das die Windows-API unterstützt, die den 32-Bit-Microsoft-Assembler mit benutzerdefinierten oder konvertierten Headern und Bibliotheken von der Plattform verwendet SDK.

Für die Anwendung Structured Exception Handling (SEH) ist auch eine Windows-spezifische Compilerunterstützung erforderlich. Dieses System dient zwei Zwecken: Es bietet ein Substrat, auf dem die sprachspezifische Ausnahmebehandlung implementiert werden kann Kernel-Anwendungen warnt, wenn außergewöhnliche Bedingungen auftreten, wie z. B. die Dereferenzierung eines ungültigen Zeiger oder Stapel-Überlauf. Die Microsoft/Borland-C Compiler hatten die Möglichkeit, dieses System von dem Moment an zu verwenden, in dem es eingeführt wurde Windows 95 und NT. Die Implementierung wurde jedoch nicht dokumentiert und musste daher für das wineproject und freie Compiler über Reverse Engineering obsolet werden. SEH basiert auf dem Pushen von Ausnahmehandler-Frames auf a Stapel, und fügen Sie es dann zu einer verknüpften Liste hinzu, die im thread-local-storage (dem ersten Feld des Thread-Umgebungsblocks) gespeichert ist. Wenn eine Ausnahme auftritt, durchsuchen der Kernel und die Basisbibliotheken den Stack nach Handlern und Filtern und führen sie dort aus, wo sie auftreten. Letztendlich wird jede Ausnahme, die nicht von der Anwendung selbst behandelt wird, vom Standard-Backstop abgefangen, der den allgemeinen Absturzdialog der Anwendung anzeigt.

Siehe auch

Externe Links