Operación de cargador del conjunto de API

Importante

La información de este tema se aplica a todas las versiones de Windows 10 y versiones posteriores. Aquí se hace referencia a esas versiones como "Windows", llamando a las excepciones cuando sea necesario.

Los conjuntos de API se basan en la compatibilidad con el sistema operativo en el cargador de biblioteca para introducir eficazmente una redirección del espacio de nombres de módulo en el proceso de enlace de biblioteca. El cargador de biblioteca usa el nombre del contrato del conjunto de API para realizar una redirección en tiempo de ejecución de la referencia a un binario host de destino que hospeda la implementación adecuada del conjunto de API.

Cuando el cargador encuentra una dependencia en un conjunto de API en tiempo de ejecución, el cargador consulta los datos de configuración de la imagen para identificar el binario del host de un conjunto de API. Estos datos de configuración se denominan esquema del conjunto de API. El esquema se ensambla como una propiedad del sistema operativo y la asignación entre conjuntos de API y archivos binarios puede diferir en función de los archivos binarios que se incluyan en un dispositivo determinado. El esquema permite que una función importada en un único binario se enrute correctamente en diferentes dispositivos, incluso si los nombres de módulo del host binario se han cambiado o se han refactorizado completamente en diferentes dispositivos Windows.

Windows admite dos técnicas estándar para consumir e interactuar con conjuntos de API: reenvío directo y reenvío inverso.

Reenvío directo

En esta configuración, el código de consumo importa directamente un nombre de módulo del conjunto de API. Esta importación se resuelve en una sola operación y es el método más eficaz con la menor sobrecarga. Conceptualmente, esta resolución puede apuntar a archivos binarios diferentes en diferentes dispositivos Windows, como se muestra en el ejemplo siguiente:

Conjunto de API importado: api-feature1-l1-1-0.dll

• Pc Windows:>feature1.dll
• HoloLens:>feature1_holo.dll
• IoT:>feature1_iot.dll

Dado que las asignaciones se mantienen en un repositorio de datos de esquema personalizado, significa que un nombre de conjunto de API que termina con .dll no hace referencia directamente a un archivo en el disco. La parte.dll del nombre del conjunto de API solo es una convención requerida por el cargador. El nombre del conjunto de API es más parecido a un alias o un nombre virtual para un archivo DLL físico. Esto hace que el nombre sea portátil en toda la gama de dispositivos Windows.

Reenvío inverso

Aunque los nombres de conjuntos de API proporcionan un espacio de nombres estable para los módulos entre dispositivos, no siempre es práctico convertir todos los binarios en este nuevo sistema. Por ejemplo, una aplicación puede haber estado en uso común durante muchos años y puede que la recompilación de los archivos binarios de la aplicación no sea factible. Además, es posible que algunas aplicaciones deban seguir ejecutándose en sistemas creados antes de que se introdujeran conjuntos de API específicos.

Para dar cabida a este nivel de compatibilidad, se proporciona un sistema de reenviadores en todos los dispositivos Windows que cubren un subconjunto de la superficie de la API de Win32. Estos reenviadores usan los nombres de módulo que se introdujeron en equipos Windows y aprovechan el sistema conjunto de API para proporcionar compatibilidad en todos los dispositivos Windows.

La operación del cargador se comporta de la siguiente manera:

1. En un dispositivo distinto de un equipo Windows, el cargador presenta una dependencia de nombre de módulo de PC Windows heredada que no está presente en el dispositivo.
2. El cargador busca un reenviador de conjuntos de API para este módulo y lo carga en memoria.
3. El reenviador tiene una asignación para el conjunto de API para la función especificada a la que se llama.
4. El cargador busca el binario host adecuado para el dispositivo determinado.

Conceptualmente, la asignación tiene el siguiente aspecto:

DLL importada: feature1.dll

• Pc Windows:>feature1.dll
• HoloLens:> reenviador defeature1.dll,>api-feature1-l1-1-0.dllfeature1_holo.dll>
• IoT:> reenviador defeature1.dllapi-feature1-l1-1-0.dll>feature1_iot.dll>

El resultado final es funcionalmente el mismo que el reenvío directo, pero lo logra de una manera que maximiza la compatibilidad de las aplicaciones.

Nota

El reenvío inverso proporciona cobertura solo para un subconjunto de la superficie de la API de Win32. No permite que las aplicaciones destinadas a versiones de escritorio de Windows se ejecuten en todos los dispositivos Windows.