Dela via


Api set loader-åtgärd

Viktig

Informationen i det här avsnittet gäller för alla versioner av Windows 10 och senare. Vi refererar till dessa versioner här som "Windows", och kallar eventuella undantag där det behövs.

API-uppsättningar förlitar sig på operativsystemstöd i biblioteksinläsaren för att effektivt introducera en modulnamnområdesomdirigering i biblioteksbindningsprocessen. Kontraktnamnet API-uppsättningen används av biblioteksinläsaren för att utföra en runtime-omdirigering av referensen till en målvärdbinär som rymmer lämplig implementering av API-uppsättningen.

När inläsaren påträffar ett beroende av en API-uppsättning vid körningen läser inläsaren konfigurationsdata i avbildningen för att identifiera värdbinärfilen för en API-uppsättning. Dessa konfigurationsdata kallas API-uppsättningsschemat. Schemat monteras som en egenskap för operativsystemet och mappningen mellan API-uppsättningar och binärfiler kan variera beroende på vilka binärfiler som ingår i en viss enhet. Schemat gör att en importerad funktion i en enda binär fil kan dirigeras korrekt på olika enheter, även om modulnamnen för den binära värden har bytt namn eller helt omstrukturerats på olika Windows-enheter.

Windows har stöd för två standardtekniker för användning och gränssnitt med API-uppsättningar: direkt vidarebefordran och omvänd vidarebefordran.

Direkt vidarebefordran

I den här konfigurationen importerar den förbrukande koden ett API-modulnamn direkt. Den här importen löses i en enda åtgärd och är den mest effektiva metoden med minst omkostnader. Konceptuellt kan den här lösningen peka på olika binärfiler på olika Windows-enheter, vilket visas i följande exempel:

Importerad API-uppsättning: api-feature1-l1-1-0.dll

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

Eftersom mappningarna sparas i en anpassad schemadatalagringsplats innebär det att ett API-uppsättningsnamn som slutar med .dll inte direkt refererar till en fil på disken. Den .dll delen av API-uppsättningens namn är bara en konvention som krävs av inläsaren. API-uppsättningens namn är mer som ett alias eller ett virtuellt namn för en fysisk DLL-fil. Detta gör namnet portabelt för hela windows-enheter.

Omvänd vidarebefordran

Namn på API-uppsättningar ger ett stabilt namnområde för moduler mellan enheter, men det är inte alltid praktiskt att konvertera varje binärfil till det nya systemet. Ett program kan till exempel ha använts gemensamt i många år, och det kanske inte är möjligt att kompilera om programmets binärfiler. Dessutom kan vissa program behöva fortsätta att köras på system som skapats innan specifika API-uppsättningar introducerades.

För att hantera den här kompatibilitetsnivån tillhandahålls ett system med vidarebefordrare på alla Windows-enheter som täcker en delmängd av Win32 API-ytan. Dessa vidarebefordrare använder de modulnamn som introducerades på Windows-datorer och använder API Set-systemet för att ge kompatibilitet på alla Windows-enheter.

Inläsningsåtgärden fungerar så här:

  1. På en annan enhet än en Windows-dator visas inläsaren ett äldre namnberoende för Windows PC-modulen som inte finns på enheten.
  2. Inläsaren letar upp en API-vidarebefordrare för den här modulen och läser in den i minnet.
  3. Vidarebefordraren har en mappning för API-uppsättningen för den angivna funktionen som anropas.
  4. Inläsaren hittar rätt värdbinär för den angivna enheten.

Konceptuellt ser mappningen ut så här:

Importerad DLL: feature1.dll

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

Slutresultatet är funktionellt detsamma som direkt vidarebefordran, men det åstadkommer det på ett sätt som maximerar programkompatibiliteten.

Not

Omvänd vidarebefordran ger endast täckning för en delmängd av Win32 API-ytan. Det tillåter inte att program som riktar sig till skrivbordsversioner av Windows körs på alla Windows-enheter.