Windows-paraplybibliotek

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.

Ett paraplybibliotek är ett enda bibliotek som du länkar och som omfattar en vald delmängd av Win32-API:er. Ett paraplybibliotek med namnet OneCore.lib omfattar till exempel den delmängd av Win32-API:er som är gemensamma för alla Windows enheter.

API:erna i ett paraplybibliotek kan implementeras i flera moduler (där en modul antingen är en API-uppsättning eller en DLL). Men paraplybiblioteket abstraherar den informationen bort från dig, vilket gör din app mer portabel mellan operativsystemversioner. I din skrivbordsapp eller drivrutin länkar du paraplybiblioteket som täcker den uppsättning API:er som du är intresserad av, och det är allt du behöver göra.

Vad ett paraplybibliotek omfattar

Ett paraplybibliotek omfattar en vald delmängd av API:er. Det är inte ett fullständigt index för varje API i varje modul som det bygger på, och ett visst API finns inte nödvändigtvis i varje paraplybibliotek.

Uppsättningen API:er som ett bibliotek omfattar är också specifik för den Windows SDK-version som du skapar mot. Ett senare SDK kan lägga till täckning som en tidigare inte har.

Av båda dessa skäl behandlar du referenssidan för ett enskilt API som den utfärdare som biblioteket ska länka till. I tabellen Krav på den sidan namnges biblioteket för api:et.

Tillgängliga bibliotek

Bibliotek Beskrivning
OneCore.lib Omfattar delmängden av Win32-API:er som är gemensamma för alla Windows enheter. Länka till OneCore.lib (och inget annat Win32-paraplybibliotek) för att få åtkomst till dessa API:er. Om du länkar till OneCore.lib och endast anropar Win32-API:er som ingår i den, läser skrivbordsappen eller drivrutinen in utan problem på alla Windows-enheter.
OneCore_apiset.lib API-uppsättningsvarianten av OneCore.lib. När ett API-uppsättningsnamn är tillgängligt för ett API löses det via en direkt API-uppsättningsimport, så ingen mellanliggande vidarebefordrarmodul ingår vid inläsningen. En binär fil som länkar den är inte garanterad att köra as-is på versioner av Windows som släpptes innan API:et anger importen.
OneCoreUAP.lib Omfattar delmängden av Win32-API:er som är gemensamma för alla Windows enheter som stöder Windows Runtime (WinRT). Länka OneCoreUAP.lib (och inget annat Win32-paraplybibliotek) för att nå dessa API:er. Om du länkar OneCoreUAP.lib och bara anropar Win32-API:er som omfattas av den, läses din skrivbordsapp eller drivrutin in utan problem på alla Windows-enheter som stöder WinRT.
OneCoreUAP_apiset.lib API-uppsättningsvarianten av OneCoreUAP.lib. När ett API-uppsättningsnamn är tillgängligt för ett API löses det via en direkt API-uppsättningsimport, så ingen mellanliggande vidarebefordrarmodul ingår vid inläsningen. En binär fil som länkar den är inte garanterad att köra as-is på versioner av Windows som släpptes innan API:et anger importen.

Kombinera inte två av dessa bibliotek i en binär fil. Var och en finns för att begränsa binärfilen till en viss API-yta, och länkning av ett andra bibliotek kan binda dig till API:er utanför den ytan.

Välja mellan ett bibliotek och dess API-uppsättningsvariant

För ett API som båda varianterna omfattar leder båda till samma implementering under körning. Det som skiljer sig är namnet som hamnar i binärfilens importtabell och därför intervallet för Windows versioner som binärfilen kan köras på.

  • Länka det vanliga biblioteket (OneCore.lib, OneCoreUAP.lib) när du behöver en enda binär fil som också körs på versioner av Windows som släpptes innan relevanta API-uppsättningar fanns. Den importerar äldre Windows modulnamn och omvänd vidarebefordran omdirigerar importen till utgåvor som inte längre har de ursprungliga modulerna.
  • Länka API-uppsättningsvarianten (OneCore_apiset.lib, OneCoreUAP_apiset.lib) när din binärfil riktar sig mot nuvarande versioner av Windows. Det föredrar ett API-uppsättningsnamn varhelst ett är tillgängligt för API:et, så att importen matchas direkt till den binärfil som är värd för implementeringen, utan någon vidarebefordrare däremellan. Det är den effektivare formen. Om inget API-uppsättningsnamn gäller använder den modulnamnet, samma som det vanliga biblioteket gör.

Inget av alternativen ändrar vilka API:er du kan anropa. Det ändrar hur dina importer namnges och hur långt tillbaka binärfilen kan köras.

Se även