Opération du chargeur du jeu d’API

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 de contrat du jeu d’API est utilisé par le chargeur de bibliothèque pour effectuer une redirection d’exécution de la référence vers un binaire hôte cible qui héberge l’implémentation appropriée du jeu d’API.

Lorsque le chargeur rencontre une dépendance sur un ensemble d’API au moment de l’exécution, le chargeur consulte les données de configuration dans l’image pour identifier le binaire hôte d’un ensemble d’API. Ces données de configuration sont appelées schéma du jeu d’API. Le schéma est assemblé en tant que propriété du système d’exploitation, et le mappage entre les ensembles 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 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 interfacer avec des ensembles d’API : transfert direct et transfert inverse.

Transfert direct

Dans cette configuration, le code consommateur importe directement un nom de module de jeu d’API. Cette importation est résolue dans une seule opération et est la méthode la plus efficace avec la surcharge minimale. Conceptuellement, cette résolution peut pointer vers des fichiers binaires différents 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 le disque. La partie .dll du nom du jeu d’API n’est qu’une convention requise par le chargeur. Le nom de l’ensemble d’API est plus semblable à 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 chaque binaire en ce nouveau système. Par exemple, une application peut avoir été utilisée pendant de nombreuses années et la recompilation des fichiers binaires de l’application peut ne pas être réalisable. En outre, certaines applications peuvent avoir besoin de 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 sont fournis sur tous les appareils Windows qui couvrent un sous-ensemble de la surface de l’API Win32. Ces redirecteurs utilisent les noms de module introduits sur les PC Windows et tirent parti du système d’ensemble d’API pour assurer la compatibilité sur tous les appareils Windows.

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

1. Sur un appareil autre qu’un PC Windows, le chargeur présente une dépendance de nom de module Windows PC héritée qui n’est pas présente sur l’appareil.
2. Le chargeur localise un redirecteur d’ensemble 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 recherche le fichier binaire hôte approprié pour l’appareil donné.

Conceptuellement, le mappage ressemble à ceci :

DLL importée : feature1.dll

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

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