Opération du chargeur de l’ensemble d’API

Important

Les informations contenues dans cette rubrique s’appliquent à toutes les versions de Windows 10 et versions ultérieures. Nous ferons référence à ces versions ici en tant que « Windows », en appelant toutes les exceptions si nécessaire.

Les ensembles d’API s’appuient sur la prise en charge du système d’exploitation dans le chargeur de bibliothèque pour introduire efficacement une redirection d’espace de noms de module dans le processus de liaison de bibliothèque. Le nom du contrat du jeu d’API est utilisé par le chargeur de bibliothèque pour effectuer une redirection du runtime de la référence vers un fichier binaire hôte cible qui héberge l’implémentation appropriée du jeu d’API.

Lorsque le chargeur rencontre une dépendance vis-à-vis d’un ensemble d’API au moment de l’exécution, le chargeur consulte les données de configuration dans l’image pour identifier le fichier binaire hôte d’un jeu d’API. Ces données de configuration sont appelées schéma d’ensemble d’API. Le schéma est assemblé en tant que propriété du système d’exploitation, et le mappage entre les jeux d’API et les fichiers binaires peut différer selon les fichiers binaires inclus dans un appareil donné. Le schéma permet à une fonction importée dans un seul fichier binaire d’être routée correctement sur différents appareils, même si les noms de module de l’hôte binaire ont été renommés ou complètement refactoris sur différents appareils Windows.

Windows prend en charge deux techniques standard pour consommer et interagir avec les ensembles d’API : le transfert direct et le transfert inverse.

Transfert direct

Dans cette configuration, le code consommateur importe directement le nom d’un module d’ensemble d’API. Cette importation est résolue en une seule opération et constitue la méthode la plus efficace avec le moins de surcharge. D’un point de vue conceptuel, cette résolution peut pointer vers différents fichiers binaires sur différents appareils Windows, comme illustré dans l’exemple suivant :

Ensemble d’API importé : api-feature1-l1-1-0.dll

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

Étant donné que les mappages sont conservés dans un référentiel de données de schéma personnalisé, cela signifie qu’un nom d’ensemble d’API qui se termine par .dll ne fait pas directement référence à un fichier sur disque. La partie.dll du nom de l’ensemble d’API n’est qu’une convention requise par le chargeur. Le nom de l’ensemble d’API ressemble davantage à un alias ou à un nom virtuel pour un fichier DLL physique. Cela rend le nom portable sur toute la gamme d’appareils Windows.

Transfert inverse

Bien que les noms des ensembles d’API fournissent un espace de noms stable pour les modules sur les appareils, il n’est pas toujours pratique de convertir tous les binaires vers ce nouveau système. Par exemple, une application peut avoir été utilisée depuis de nombreuses années et la recompilation des fichiers binaires de l’application peut ne pas être possible. En outre, certaines applications devront peut-être continuer à s’exécuter sur des systèmes créés avant l’introduction de jeux d’API spécifiques.

Pour prendre en charge ce niveau de compatibilité, un système de redirecteurs est fourni sur tous les appareils Windows qui couvrent un sous-ensemble de la surface de l’API Win32. Ces redirecteurs utilisent les noms de module qui ont été introduits sur les PC Windows et tirent parti du système d’ensemble d’API pour assurer la compatibilité entre tous les appareils Windows.

L’opération de chargeur se comporte comme suit :

1. Sur un appareil autre qu’un PC Windows, le chargeur se voit présenter une dépendance de nom de module de PC Windows héritée qui n’est pas présente sur l’appareil.
2. Le chargeur localise un redirecteur de jeu d’API pour ce module et le charge en mémoire.
3. Le redirecteur a un mappage pour l’ensemble d’API pour la fonction donnée appelée.
4. Le chargeur trouve le fichier binaire hôte approprié pour l’appareil donné.

D’un point de vue conceptuel, le mappage se présente comme suit :

DLL importée : feature1.dll

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

Le résultat final est fonctionnellement identique au transfert direct, mais il l’accomplit d’une manière qui optimise la compatibilité des applications.

Notes

Le transfert inverse fournit une couverture uniquement pour un sous-ensemble de la surface de l’API Win32. Il n’autorise pas les applications qui ciblent les versions de bureau de Windows à s’exécuter sur tous les appareils Windows.