Windows-API - Windows API

Die Windows-API , informell WinAPI , ist der Kernsatz von Anwendungsprogrammierschnittstellen (APIs) von Microsoft, die in den Microsoft Windows- Betriebssystemen verfügbar sind. Der Name Windows-API bezieht sich zusammenfassend auf mehrere verschiedene Plattformimplementierungen, auf die oft mit ihren eigenen Namen verwiesen wird (z. B. Win32 API ); siehe Abschnitt Versionen . Fast alle Windows-Programme interagieren mit der Windows-API. Auf der Windows NT-Reihe von Betriebssystemen verwenden einige wenige (z. B. Programme, die zu Beginn des Windows-Startvorgangs gestartet wurden ) die native API .

Entwicklersupport ist in Form eines Software Development Kits , Microsoft Windows SDK , verfügbar , das Dokumentation und Tools bereitstellt, die zum Erstellen von Software basierend auf der Windows-API und den zugehörigen Windows-Schnittstellen erforderlich sind.

Die Windows-API (Win32) konzentriert sich hauptsächlich auf die Programmiersprache C , da ihre exponierten Funktionen und Datenstrukturen in dieser Sprache in neueren Versionen ihrer Dokumentation beschrieben werden. Die API kann jedoch von jedem Programmiersprachen- Compiler oder -Assembler verwendet werden , der die (gut definierten) Low-Level-Datenstrukturen zusammen mit den vorgeschriebenen Aufrufkonventionen für Aufrufe und Rückrufe handhaben kann . Ebenso wurde die interne Implementierung der API-Funktion in der Vergangenheit in mehreren Sprachen entwickelt. Obwohl C keine objektorientierte Programmiersprache ist, wurden sowohl die Windows-API als auch Windows historisch als objektorientiert beschrieben. Es gab auch viele Wrapperklassen und Erweiterungen (von Microsoft und anderen) für objektorientierte Sprachen, die diese objektorientierte Struktur expliziter machen ( Microsoft Foundation Class Library (MFC), Visual Component Library (VCL), GDI+ usw.) . Zum Beispiel Windows 8 bietet den Windows - API und die WinRT API, die implementiert ist in C ++ und ist objektorientiert beabsichtigt.

Überblick

Die von der Windows-API bereitgestellten Funktionen lassen sich in acht Kategorien einteilen:

Basisdienste
Gewähren Sie Zugriff auf die grundlegenden Ressourcen, die einem Windows-System zur Verfügung stehen. Dazu gehören Dinge wie Dateisysteme , Geräte , Prozesse , Threads und Fehlerbehandlung . Diese Funktionen liegen inKernel.exe, krnl286.exe oder krnl386.exe Dateien auf 16-Bit-Windows und kernel32.dll und KernelBase.dllauf 32- und 64-Bit-Windows. Diese Dateien befinden sich im Ordner\Windows\System32 auf allen Windows-Versionen.
Erweiterte Dienste
Bieten Sie Zugriff auf Funktionen außerhalb des Kernels. Enthalten sind Dinge wie die Windows-Registrierung , das System herunterfahren/neu starten (oder abbrechen), einen Windows-Dienst starten/stoppen/erstellen , Benutzerkonten verwalten. Diese Funktionen liegen inadvapi32.dll und advapires32.dll auf 32-Bit-Windows.
Schnittstelle für Grafikgeräte
Bietet Funktionen zur Ausgabe von Grafikinhalten auf Monitoren , Druckern und anderen Ausgabegeräten . Es liegt ingdi.exe auf 16-Bit-Windows und gdi32.dllauf 32-Bit-Windows im Benutzermodus. GDI-Unterstützung im Kernel-Modus wird bereitgestellt, win32k.sysdie direkt mit dem Grafiktreiber kommuniziert.
Benutzeroberfläche
Bietet die Funktionen Bildschirm erstellen und zu verwalten Fenster und grundlegendsten Kontrollen, wie Tasten und Scrollbalken , erhält Maus- und Tastatureingaben und andere mit dem zugehörigen Funktionen grafischer Benutzeroberfläche (GUI) Teil von Windows. Diese Funktionseinheit befindet sich inuser.exe auf 16-Bit-Windows und user32.dllauf 32-Bit-Windows. Seit Windows XP- Versionen befinden sich die grundlegenden Steuerelemente incomctl32.dll, zusammen mit den allgemeinen Steuerelementen (Common Control Library).
Bibliothek für allgemeine Dialogfelder
Bietet Anwendungen die Standarddialogfelder zum Öffnen und Speichern von Dateien, wählen Sie Farbe und Schriftart, etc. Die Bibliothek befindet sich in einer Datei mit dem Namencommdlg.dll auf 16-Bit-Windows und comdlg32.dllauf 32-Bit-Windows. Es ist unter der Kategorie Benutzeroberfläche der API gruppiert .
Common Control Library
Gewährt Anwendungen Zugriff auf einige erweiterte Steuerelemente des Betriebssystems. Dazu gehören Dinge wie Statusleisten , Fortschrittsbalken , Symbolleisten und Registerkarten . Die Bibliothek befindet sich in einer Dynamic Link Library (DLL)-Datei namenscommctrl.dll auf 16-Bit-Windows und comctl32.dllauf 32-Bit-Windows. Es ist unter der Kategorie Benutzeroberfläche der API gruppiert .
Windows-Shell
Eine Komponente der Windows-API ermöglicht es Anwendungen, auf Funktionen zuzugreifen, die von der Betriebssystem-Shell bereitgestellt werden , und diese zu ändern und zu erweitern. Die Komponente befindet sich inshell.dll auf 16-Bit-Windows und shell32.dllauf 32-Bit-Windows. Die Shell Lightweight Utility-Funktionen sind inshlwapi.dll. Es ist unter der Kategorie Benutzeroberfläche der API gruppiert .
Netzwerkdienste
Gewähren Sie Zugriff auf die verschiedenen Netzwerkfähigkeiten des Betriebssystems. Zu seinen Unterkomponenten gehören NetBIOS , Winsock , NetDDE , Remote Procedure Call (RPC) und viele mehr. Diese Komponente befindet sich innetapi32.dll auf 32-Bit-Windows.

Netz

Der Internet Explorer (IE)-Webbrowser stellt auch viele APIs bereit, die häufig von Anwendungen verwendet werden, und könnten daher als Teil der Windows-API betrachtet werden. IE ist seit Windows 95 OSR2 im Betriebssystem enthalten und bietet seit Windows 98 webbezogene Dienste für Anwendungen . Im Einzelnen wird es verwendet, um Folgendes bereitzustellen:

  • Ein einbettbares Webbrowser-Steuerelement, enthalten in shdocvw.dll und mshtml.dll.
  • Der URL-Moniker-Dienst, gehalten in urlmon.dll, die COM- Objekte für Anwendungen zum Auflösen von URLs bereitstellt . Anwendungen können auch ihre eigenen URL-Handler zur Verwendung durch andere bereitstellen.
  • Eine HTTP-Client-Bibliothek, die auch systemweite Proxy-Einstellungen berücksichtigt (wininet.dll); Microsoft hat jedoch eine weitere HTTP-Clientbibliothek namens winhttp.dll hinzugefügt, die kleiner und für einige Anwendungen besser geeignet ist.
  • Eine Bibliothek zur Unterstützung mehrsprachiger und internationaler Textunterstützung (mlang.dll).
  • DirectX-Transformationen, eine Reihe von Bildfilterkomponenten.
  • XML-Unterstützung (die MSXML-Komponenten, die in msxml*.dll).
  • Zugriff auf die Windows-Adressbücher.

Multimedia

Die klassische Windows Multimedia API befindet sich in winmm.dll und enthält Funktionen zum Abspielen von Sounddateien, zum Senden und Empfangen von MIDI-Nachrichten, zum Zugriff auf Joysticks und zur Erleichterung aller anderen Funktionen des sogenannten MCI- Subsystems von Windows, das aus der Multimedia Extensions für Windows 3.0 separat und als integraler Bestandteil des Betriebssystems seit Windows 3.1 erhältlich, damals befanden sie sich in mmsystem.dll.

Abgesehen davon hat Microsoft als Teil jeder Windows-Version seit Windows 95 OSR2 die DirectX- APIs bereitgestellt – eine lose verwandte Reihe von Grafik- und Spielediensten, die Folgendes umfasst:

  • Direct2D für hardwarebeschleunigte 2D-Vektorgrafiken.
  • Direct3D für hardwarebeschleunigte 3D-Grafik.
  • DirectSound für hardwarebeschleunigten Soundkartenzugriff auf niedriger Ebene.
  • DirectInput zur Kommunikation mit Eingabegeräten wie Joysticks und Gamepads.
  • DirectPlay als Multiplayer-Gaming-Infrastruktur. Diese Komponente ist seit DirectX 9 veraltet und Microsoft empfiehlt ihre Verwendung für die Spieleentwicklung nicht mehr.
  • DirectDraw für 2D-Grafiken in früheren DirectX-Versionen, jetzt veraltet und durch Direct2D ersetzt.
  • WinG für 2D-Grafiken in 16-Bit-Spielen, die für Windows 3.x-Versionen geschrieben wurden. Mit Windows 95-Version veraltet.

Microsoft bietet auch mehrere APIs für die Mediencodierung und -wiedergabe:

  • DirectShow , das generische Multimedia-Pipelines erstellt und ausführt. Es ist mit dem GStreamer- Framework vergleichbar und wird häufig zum Rendern von In-Game-Videos und zum Erstellen von Mediaplayern verwendet ( Windows Media Player basiert darauf). DirectShow wird nicht mehr für die Spieleentwicklung empfohlen.
  • Media Foundation , eine neuere API für digitale Medien, die DirectShow ersetzen soll.

Programminteraktion

Die Windows-API ist hauptsächlich für die Interaktion zwischen dem Betriebssystem und einer Anwendung konzipiert. Für die Kommunikation zwischen verschiedenen Windows-Anwendungen hat Microsoft neben der Haupt-Windows-API eine Reihe von Technologien entwickelt. 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 , ActiveX- Steuerelemente und das .NET Framework abgelöst wurde . Es gibt nicht immer eine klare Unterscheidung zwischen diesen Technologien, und es gibt viele Überschneidungen.

Die Begriffsvielfalt ergibt sich im Wesentlichen aus der Gruppierung von Softwaremechanismen, die sich auf einen bestimmten Aspekt der Softwareentwicklung beziehen. Automatisierung bezieht sich speziell auf den Export der Funktion einer Anwendung oder Komponente (als Anwendungsprogrammierschnittstelle (API)), sodass sie von anderen Anwendungen anstatt nur von menschlichen Benutzern gesteuert werden kann. .NET ist eine in sich geschlossene allgemeine Methodik und Technologie, um Entwicklung von Desktop- und Webanwendungen, die in einer Vielzahl von just-in-time (JIT) kompilierten Sprachen geschrieben sind.

Windows.pas ist eine Pascal / Delphi- Unit, die die Windows- spezifischen API-Deklarationen enthält. Es ist das Pascal-Äquivalent zu windows.h , das in C verwendet wird.

Wrapper-Bibliotheken

Von Microsoft wurden verschiedene Wrapper entwickelt, die einige der untergeordneten Funktionen der Windows-API übernahmen und es Anwendungen ermöglichten, auf abstraktere Weise mit der API zu interagieren. Die Microsoft Foundation Class Library (MFC) umschloss die Windows-API-Funktionalität in C++- Klassen und ermöglicht somit eine objektorientiertere Möglichkeit, mit der API zu interagieren. Die Active Template Library (ATL) ist ein vorlagenorientierter Wrapper für COM. Die Windows Template Library (WTL) wurde als Erweiterung von ATL entwickelt und ist als kleinere Alternative zu MFC gedacht.

Die meisten Anwendungsframeworks für Windows (zumindest teilweise) umschließen die Windows-API. Somit sind (oder enthalten) das .NET Framework und Java sowie alle anderen Programmiersprachen unter Windows Wrapper-Bibliotheken.

Geschichte

Die Windows-API hat Programmierern immer einen großen Teil der zugrunde liegenden Struktur der Windows-Systeme enthüllt. Dies hatte den Vorteil, dass sie viel Flexibilität und Kontrolle über ihre Anwendungen erhielten, aber auch eine große Verantwortung bei der Handhabung verschiedener, manchmal mühsamer Operationen auf niedriger Ebene, die mit einer grafischen Benutzeroberfläche verbunden sind, mit sich brachten .

Zum Beispiel schreibt ein angehender C-Programmierer oft das einfache "Hallo Welt" als seine erste Aufgabe. Der Arbeitsteil des Programms ist nur eine einzelne printf-Zeile innerhalb des Hauptunterprogramms. Der Overhead für die Anbindung an die Standard-I/O-Library beträgt ebenfalls nur eine Zeile: 

#include <stdio.h>

int main(void) {
    printf("Hello, World!\n");
}

Die Windows-Version war immer noch nur eine funktionierende Codezeile, erforderte jedoch viele, viele weitere Zeilen Overhead. Charles Petzold , der mehrere Bücher über die Programmierung für die Windows-API geschrieben hat, sagte: "Das ursprüngliche Hello-World-Programm im Windows 1.0 SDK war ein kleiner Skandal. HELLO.C war etwa 150 Zeilen lang und das Ressourcenskript HELLO.RC hatte noch etwa 20 Zeilen mehr. (...) Erfahrene Programmierer rollten sich oft vor Entsetzen oder Gelächter zusammen, wenn sie auf das Windows-Hello-World-Programm stießen."

Im Laufe der Jahre wurden verschiedene Änderungen und Ergänzungen an Windows-Systemen vorgenommen, und die Windows-API änderte und wuchs, um dies widerzuspiegeln. Die Windows-API für Windows 1.0 unterstützt weniger als 450 Funktionsaufrufe , während moderne Versionen der Windows-API Tausende unterstützen. Im Allgemeinen blieb die Schnittstelle jedoch ziemlich konsistent, und eine alte Windows 1.0-Anwendung wird einem Programmierer, der an die moderne Windows-API gewöhnt ist, immer noch bekannt vorkommen.

Microsoft hat sich bemüht, die Abwärtskompatibilität aufrechtzuerhalten . Um dies zu erreichen, hat Microsoft bei der Entwicklung neuer Windows-Versionen manchmal Workarounds implementiert, um die Kompatibilität mit Software von Drittanbietern zu ermöglichen, die die vorherige Version auf undokumentierte oder sogar nicht ratsame Weise verwendet. Raymond Chen , ein Microsoft-Entwickler, der an der Windows-API arbeitet, sagte: „Ich könnte wahrscheinlich monatelang ausschließlich über schlechte Dinge schreiben, die Apps tun und was wir tun mussten, um sie wieder zum Laufen zu bringen (oft trotz ihrer selbst). Deshalb werde ich besonders wütend, wenn Leute Microsoft beschuldigen, Anwendungen bei Betriebssystem-Upgrades böswillig zu beschädigen. Wenn eine Anwendung unter Windows 95 nicht ausgeführt werden konnte, habe ich dies als persönliches Versagen angesehen."

Eine der größten Änderungen an der Windows-API war der Übergang von Win16 (im Lieferumfang von Windows 3.1 und älter) zu Win32 (Windows NT und Windows 95 und höher). Obwohl Win32 ursprünglich mit Windows NT 3.1 eingeführt wurde und Win32s die Verwendung einer Win32-Untergruppe vor Windows 95 erlaubte, begann die weit verbreitete Portierung von Anwendungen auf Win32 erst mit Windows 95. Um den Übergang zu erleichtern, wurde in Windows 95 für Entwickler außerhalb und innerhalb von Microsoft ein komplexes Schema von API- Thunks verwendet, das es ermöglichen konnte, 32- Bitcode in 16- Bitcode (für die meisten Win16-APIs) aufzurufen und umgekehrt. Flat-Thunks ermöglichten den Aufruf von 32-Bit-Code in 16-Bit-Bibliotheken, und das Schema wurde ausgiebig in den Bibliotheken von Windows 95 verwendet, um zu vermeiden, das gesamte Betriebssystem in einem Stapel auf Win32 zu portieren. In Windows NT war das Betriebssystem reines 32-Bit-Betriebssystem, mit Ausnahme von Teilen aus Gründen der Kompatibilität mit 16-Bit-Anwendungen, und es standen nur generische Thunks für das Thunk von Win16 auf Win32 zur Verfügung, wie für Windows 95. Das Platform SDK wurde mit einem Compiler geliefert, der der Code, der für diese Thunks benötigt wird. Versionen von 64-Bit- Windows können auch 32-Bit-Anwendungen über WoW64 ausführen . Der Ordner SysWOW64 im Windows-Ordner auf dem Betriebssystemlaufwerk enthält mehrere Tools zur Unterstützung von 32-Bit-Anwendungen.

Versionen

Fast jede neue Version von Microsoft Windows hat eigene Ergänzungen und Änderungen an der Windows-API eingeführt. Der Name der API blieb jedoch zwischen verschiedenen Windows-Versionen konsistent, und Namensänderungen wurden auf größere Architektur- und Plattformänderungen für Windows beschränkt. Microsoft änderte schließlich den Namen der damals aktuellen Win32-API-Familie in Windows-API und machte daraus einen Sammelbegriff für vergangene und zukünftige API-Versionen.

  • Win16 ist die API für die ersten 16-Bit- Versionen von Microsoft Windows . Diese wurden zunächst einfach als Windows-API bezeichnet , wurden jedoch später in Win16 umbenannt, um sie von der neueren 32-Bit-Version der Windows-API zu unterscheiden. Die Funktionen der Win16-API liegen hauptsächlich in den Kerndateien des Betriebssystems: kernel.exe (oder krnl286.exe oder krnl386.exe ), user.exe und gdi.exe . Trotz der Dateierweiterung vonexe, dies sind eigentlich Dynamic-Link-Bibliotheken .
  • Win32 ist die 32-Bit- Anwendungsprogrammierschnittstelle (API) für Windows-Versionen ab 95. Die API besteht aus Funktionen, die wie bei Win16 in System-DLLs implementiert sind. Die Kern-DLLs von Win32 sind kernel32.dll , user32.dll und gdi32.dll . Win32 wurde mit Windows NT eingeführt . Die mit Windows 95 ausgelieferte Version von Win32 wurde ursprünglich als Win32c bezeichnet, wobei c Kompatibilität bedeutet . Dieser Begriff wurde später von Microsoft zugunsten von Win32 aufgegeben.
  • Win32s ist eine Erweiterung für die Windows 3.1x- Familie von Microsoft Windows, die eine Teilmenge der Win32-API für diese Systeme implementiert hat. Das „s“ steht für „Teilmenge“.
  • Win64 ist die auf 64-Bit- Plattformen der Windows-Architektur implementierte Variante der API (ab 2021 x86-64 und AArch64 ). Sowohl 32-Bit- als auch 64-Bit-Versionen einer Anwendung können weiterhin aus einer Codebasis kompiliert werden , obwohl einige ältere APIs veraltet sind und einige der APIs, die bereits in Win32 veraltet waren, entfernt wurden. Alle Speicherzeiger sind 64-Bit standardmäßig (das LLP64 Modell), so muss der Quellcode für die Kompatibilität mit 64-Bit überprüft werden , Zeigerarithmetik und neu geschrieben wie nötig.
  • WinCE ist die Implementierung der Windows-API für das Betriebssystem Windows CE .

Andere Implementierungen

Das Wine- Projekt bietet eine Win32-API- Kompatibilitätsschicht für Unix-ähnliche Plattformen zwischen der Linux-Kernel-API und Programmen, die für die Windows-API geschrieben wurden. ReactOS geht noch einen Schritt weiter und zielt darauf ab, das vollständige Windows-Betriebssystem zu implementieren und arbeitet eng mit dem Wine-Projekt zusammen, um die Wiederverwendung und Kompatibilität von Code zu fördern. DosWin32 und HX DOS Extender sind weitere Projekte, die die Windows-API emulieren, um die Ausführung einfacher Windows-Programme über eine DOS- Befehlszeile zu ermöglichen. Odin ist ein Projekt zur Emulation von Win32 unter OS/2 , das die ursprüngliche Win-OS/2-Emulation ersetzt, die auf Microsoft-Code basierte. Andere kleinere Implementierungen umfassen die MEWEL- und Zinc- Bibliotheken, die eine Teilmenge der Win16-API unter DOS implementieren sollten (siehe Liste der plattformunabhängigen GUI-Bibliotheken ).

Windows Interface Source Environment (WISE) war ein Lizenzprogramm von Microsoft, das es Entwicklern ermöglichte, Windows-basierte Anwendungen auf Unix- und Macintosh- Plattformen neu zu kompilieren und auszuführen . WISE SDKs basierten auf einem Emulator der Windows-API, der auf diesen Plattformen ausgeführt werden konnte.

Zu den Bemühungen um eine Standardisierung gehörten Suns Public Windows Interface (PWI) für Win16 (siehe auch: Sun Windows Application Binary Interface ( Wabi )), Willows Softwares Application Programming Interface for Windows (APIW) für Win16 und Win32 (siehe auch: Willows TWIN ) und ECMA-234 , die versucht hat, die Windows-API verbindlich zu standardisieren.

Compiler-Unterstützung

Um Software zu entwickeln, die die Windows-API verwendet, muss ein Compiler in der Lage sein, die oben aufgeführten Microsoft-spezifischen DLLs zu verwenden (COM-Objekte sind außerhalb von Win32 und nehmen ein bestimmtes vtable-Layout an). Der Compiler muss entweder die Header-Dateien verarbeiten, die die inneren API-Funktionsnamen verfügbar machen, oder solche Dateien bereitstellen.

Für die Sprache C++ haben Zortech (später Symantec , dann Digital Mars ), Watcom und Borland bekannte kommerzielle Compiler entwickelt, die oft mit Win16, Win32s und Win32 verwendet wurden. Einige von ihnen lieferten Speichererweiterungen , die es Win32-Programmen ermöglichen, unter Win16 mit Microsofts weiterverteilbarer Win32s-DLL zu laufen. Der Zortech-Compiler war wahrscheinlich einer der ersten stabilen und verwendbaren C++-Compiler für die Windows-Programmierung, bevor Microsoft einen C++-Compiler hatte.

Für bestimmte Anwendungsklassen sollte das Compilersystem auch in der Lage sein, Interface Description Language (IDL)-Dateien zu handhaben . Zusammen werden diese Voraussetzungen (Compiler, Tools, Bibliotheken und Header) als Microsoft Platform SDK bezeichnet . Eine Zeit lang waren das Microsoft Visual Studio und das integrierte Entwicklungssystem von Borland die einzigen integrierten Entwicklungsumgebungen (IDEs), die dies bieten konnten (obwohl das SDK separat von der gesamten IDE-Suite kostenlos heruntergeladen werden kann, vom Microsoft Windows SDK für Windows 7 und .NET-Framework 4 ).

Ab 2016 bieten die MinGW- und Cygwin- Projekte auch eine solche Umgebung basierend auf der GNU Compiler Collection (GCC) mit einem eigenständigen Header-Dateisatz, um das Verlinken gegen die Win32-spezifischen DLLs zu vereinfachen. LCC-Win32 ist ein von Jacob Navia verwalteter C-Compiler, Freeware für den nicht-kommerziellen Gebrauch. Pelles C ist ein Freeware-C-Compiler, der von Pelle Orinius verwaltet wird. Free Pascal ist ein kostenloser Object Pascal- Compiler, der die Windows-API unterstützt. Das MASM32-Paket ist ein ausgereiftes Projekt, das Unterstützung für die Windows-API unter Microsoft Macro Assembler (MASM) bietet, indem benutzerdefinierte oder konvertierte Header und Bibliotheken aus dem Platform SDK verwendet werden. Flat-Assembler FASM ermöglicht das Erstellen von Windows-Programmen ohne Verwendung eines externen Linkers, selbst wenn es unter Linux läuft.

Für die strukturierte Ausnahmebehandlung (SEH) ist auch Windows-spezifische Compilerunterstützung erforderlich . Dieses System dient zwei Zwecken: Es stellt ein Substrat bereit, auf dem eine sprachspezifische Ausnahmebehandlung implementiert werden kann, und es ist die Art und Weise, wie der Kernel Anwendungen über außergewöhnliche Bedingungen wie die Dereferenzierung eines ungültigen Zeigers oder einen Stapelüberlauf benachrichtigt. Die Microsoft/Borland C++-Compiler hatten die Möglichkeit, dieses System zu verwenden, sobald es in Windows 95 und NT eingeführt wurde, jedoch war die tatsächliche Implementierung undokumentiert und musste für das Wine-Projekt und freie Compiler zurückentwickelt werden. SEH basiert darauf, Ausnahmebehandlungsrahmen auf den Stapel zu schieben und sie dann zu einer verknüpften Liste hinzuzufügen, die im Thread-lokalen Speicher (dem ersten Feld des Thread-Umgebungsblocks) gespeichert ist . Wenn eine Ausnahme ausgelöst wird, wickeln der Kernel und die Basisbibliotheken die Stapel ab, die Handler und Filter ausführen, sobald sie angetroffen werden. Schließlich wird jede Ausnahme, die von der Anwendung nicht behandelt wird, vom Standard-Backstop-Handler behandelt, der den allgemeinen Windows-Absturzdialog öffnet.

Siehe auch

Anmerkungen

Externe Links