API-Satz-Ladevorgang

Wichtig

Die Informationen in diesem Thema gelten für alle Versionen von Windows 10 und höher. Wir bezeichnen diese Versionen hier als "Windows" und nennen alle Ausnahmen bei Bedarf.

API-Gruppen basieren auf der Betriebssystemunterstützung im Bibliotheksladeprogramm, um effektiv eine Modulnamespaceumleitung in den Bibliotheksbindungsprozess einzuführen. Der Name des API-Satzvertrags wird vom Bibliotheksladeprogramm verwendet, um eine Laufzeitumleitung des Verweises auf eine Zielhost-Binärdatei durchzuführen, die die entsprechende Implementierung des API-Satzes enthält.

Wenn der Ladeer zur Laufzeit auf eine Abhängigkeit von einem API-Satz stößt, ruft das Ladeprogramm Konfigurationsdaten im Image ab, um die Hostbinärdatei für eine API-Gruppe zu identifizieren. Diese Konfigurationsdaten werden als API-Satzschema bezeichnet. Das Schema wird als Eigenschaft des Betriebssystems zusammengestellt, und die Zuordnung zwischen API-Sätzen und Binärdateien kann sich je nachdem unterscheiden, welche Binärdateien auf einem bestimmten Gerät enthalten sind. Das Schema ermöglicht es, dass eine importierte Funktion in einer einzelnen Binärdatei auf verschiedenen Geräten ordnungsgemäß weitergeleitet werden kann, auch wenn die Modulnamen des binären Hosts auf verschiedenen Windows-Geräten umbenannt oder vollständig umgestaltet wurden.

Windows unterstützt zwei Standardtechniken für die Nutzung und Schnittstelle mit API-Sätzen: direkte Weiterleitung und Reverseweiterleitung.

Direkte Weiterleitung

In dieser Konfiguration importiert der verbrauchende Code direkt einen API-Satzmodulnamen. Dieser Import wird in einem einzigen Vorgang aufgelöst und ist die effizienteste Methode mit dem geringsten Mehraufwand. Konzeptionell kann diese Auflösung auf unterschiedliche Binärdateien auf verschiedenen Windows-Geräten verweisen, wie im folgenden Beispiel gezeigt:

Importierte API-Gruppe: api-feature1-l1-1-0.dll

• Windows-PC –>feature1.dll
• HoloLens –>feature1_holo.dll
• IoT –>feature1_iot.dll

Da die Zuordnungen in einem benutzerdefinierten Schemadatenrepository aufbewahrt werden, bedeutet dies, dass ein API-Satzname, der mit.dll endet, nicht direkt auf eine Datei auf dem Datenträger verweist. Der .dll Teil des API-Satznamens ist nur eine Konvention, die vom Ladeprogramm erforderlich ist. Der API-Setname ähnelt eher einem Alias oder einem virtuellen Namen für eine physische DLL-Datei. Dadurch wird der Name für den gesamten Bereich von Windows-Geräten portierbar.

Umgekehrte Weiterleitung

Während API-Satznamen einen stabilen Namespace für Module auf allen Geräten bieten, ist es nicht immer sinnvoll, jede Binärdatei in dieses neue System zu konvertieren. Beispielsweise kann eine Anwendung seit vielen Jahren häufig verwendet werden, und das erneute Kompilieren der Binärdateien der Anwendung ist möglicherweise nicht möglich. Darüber hinaus müssen einige Anwendungen möglicherweise weiterhin auf Systemen ausgeführt werden, die vor der Einführung bestimmter API-Sätze erstellt wurden.

Um diesem Kompatibilitätsgrad gerecht zu werden, wird ein System von Weiterleitungen auf allen Windows-Geräten bereitgestellt, die eine Teilmenge der Win32-API-Oberfläche abdecken. Diese Weiterleitungen verwenden die Modulnamen, die auf Windows-PCs eingeführt wurden, und nutzen das API Set-System, um Kompatibilität für alle Windows-Geräte bereitzustellen.

Der Ladevorgang verhält sich wie folgt:

1. Auf einem anderen Gerät als einem Windows-PC wird dem Ladeprogramm eine Ältere Windows-PC-Modulnamenabhängigkeit angezeigt, die auf dem Gerät nicht vorhanden ist.
2. Der Ladeprogramm sucht eine API-Setweiterleitung für dieses Modul und lädt sie in den Arbeitsspeicher.
3. Die Weiterleitung verfügt über eine Zuordnung für die API, die für die angegebene Funktion festgelegt ist, die aufgerufen wird.
4. Das Ladeprogramm findet die richtige Hostbinärdatei für das angegebene Gerät.

Konzeptionell sieht die Zuordnung wie folgt aus:

Importierte DLL: feature1.dll

• Windows-PC –>feature1.dll
• HoloLens –>feature1.dll Weiterleitung –>api-feature1-l1-1-0.dll –>feature1_holo.dll
• IoT –>feature1.dll Weiterleitung –>api-feature1-l1-1-0.dll –>feature1_iot.dll

Das Endergebnis ist funktional identisch mit der direkten Weiterleitung, erreicht es jedoch auf eine Weise, die die Anwendungskompatibilität maximiert.

Hinweis

Reverse Forwarding bietet nur Abdeckung für eine Teilmenge der Win32-API-Oberfläche. Anwendungen, die Desktopversionen von Windows als Ziel verwenden, können nicht auf allen Windows-Geräten ausgeführt werden.