API-Setladevorgang

API-Sätze die Betriebssystemunterstützung im Bibliotheksladeprogramm verwenden, um eine Modulnamespaceumleitung effektiv in den Bibliotheksbindungsprozess einzuführen. Der API-Set-Vertragsname 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 das Ladeprogramm zur Laufzeit auf eine Abhängigkeit eines API-Satzes stößt, konsultiert das Ladeprogramm Konfigurationsdaten im Image, um die Host-Binärdatei für einen API-Satz zu identifizieren. Diese Konfigurationsdaten werden als API-Set-Schemabezeichnet. Das Schema wird als Eigenschaft des Betriebssystems zusammengestellt, und die Zuordnung zwischen API-Sätzen und Binärdateien kann je nachdem, welche Binärdateien in einem bestimmten Gerät enthalten sind. Mit dem Schema kann eine importierte Funktion in einer einzelnen Binärdatei auf verschiedenen Geräten ordnungsgemäß weitergeleitet werden, auch wenn die Modulnamen des Binärhosts umbenannt oder vollständig auf verschiedenen Windows-Geräten umgestaltet wurden.

Windows unterstützt zwei Standardtechniken für die Nutzung und Schnittstelle mit API-Sätzen: direct forwarding und reverse forwarding.

Direkte Weiterleitung

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

Importierter API-Satz: api-feature1-l1-1-0.dll

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

Da die Zuordnungen in einem benutzerdefinierten Schemadaten-Repository gespeichert 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-Setnamens ist nur eine Konvention, die vom Ladeprogramm benötigt wird. Der NAME des API-Satzes ähnelt 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 bereitstellen, ist es nicht immer praktisch, jede Binärdatei in dieses neue System zu konvertieren. Eine Anwendung kann z. B. seit vielen Jahren häufig verwendet werden, und die Neukompilierung der Binärdateien der Anwendung ist möglicherweise nicht machbar. Darüber hinaus müssen einige Anwendungen möglicherweise weiterhin auf Systemen ausgeführt werden, die erstellt wurden, bevor bestimmte API-Sätze eingeführt wurden.

Um diese Kompatibilitätsstufe zu berücksichtigen, werden 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 auf allen Windows-Geräten 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 nicht auf dem Gerät vorhanden ist.
2. Das Ladeprogramm sucht einen API-Satzweiterleitung für dieses Modul und lädt ihn in den Arbeitsspeicher.
3. Die Weiterleitung verfügt über eine Zuordnung für den API-Satz für die angegebene Funktion, die aufgerufen wird.
4. Das Ladeprogramm findet die richtige Host-Binä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 Forwarder ->api-feature1-l1-1-0.dll ->feature1_holo.dll
• IoT ->feature1.dll Forwarder ->api-feature1-l1-1-0.dll ->feature1_iot.dll

Das Endergebnis ist funktionell identisch mit direct forwarding, aber es erreicht es auf eine Weise, die anwendungskompatibilität maximiert.