Caso práctico de puente COM: cómo llamar a una DLL de 64 bits desde una app de 32 bits

El requisito de llamar a una DLL de 64 bits desde una aplicación de 32 bits es bastante habitual en Windows. Sobre todo cuando se quiere conservar los activos existentes y usar únicamente las funciones del lado de 64 bits, la configuración de un puente COM suele ser la solución más realista.

Público al que va dirigido: personas que mantienen una aplicación de Windows de 32 bits existente y quieren usar una DLL o biblioteca del lado de 64 bits. Está escrito para poder leerse partiendo de un nivel de «he oído hablar de COM, pero nunca lo he programado yo mismo».

Entorno previo: Windows de 64 bits (x64) y un entorno de desarrollo donde pueda escribir en C# (Visual Studio, por ejemplo). Registrar un servidor COM para toda la máquina (bajo HKEY_LOCAL_MACHINE) requiere permisos de administrador. Las ideas básicas de COM están explicadas en «Qué es COM: por qué el diseño de COM en Windows sigue siendo hermoso».

Índice

1. Situación planteada
2. Solución
3. Flujo de procesamiento (diagrama de secuencia)
4. Código de ejemplo (idea general)
5. Código de ejemplo completo
6. Resumen
7. Referencias

1. Situación planteada

Se trata de casos en los que se quiere usar el procesamiento de una DLL de 64 bits dejando intacta la aplicación de 32 bits existente. Sin embargo, un proceso de 32 bits no puede cargar una DLL de 64 bits. Se trata de una restricción a nivel de sistema operativo, no de algo que se pueda resolver con algún truco.

Las situaciones más frecuentes son estas:

• La aplicación de 32 bits existente es un activo grande y no se puede migrar de inmediato
• El lado de la DLL de 64 bits tiene funciones nuevas, o las bibliotecas de las que depende solo existen en 64 bits
• Se quiere llamar desde el lado de 32 bits «con tipado»

Con esta combinación, la vía de llamar dentro del mismo proceso está cerrada desde el principio.

2. Solución

A partir de este apartado aparecen varios términos técnicos, así que antes vamos a repasar el vocabulario mínimo necesario.

La base de la solución es separar los procesos mediante Out-of-proc COM (servidor EXE). La DLL de 64 bits se llama desde un servidor COM de 64 bits (EXE), y la aplicación de 32 bits la utiliza a través de COM.

El flujo es el siguiente.

1. Preparar un COM LocalServer de 64 bits (EXE) que internamente llame a la DLL de 64 bits
2. Compartir la interfaz COM (IDL/TypeLib) para exponer los tipos
3. La aplicación de 32 bits llama a COM «con tipado» (comunicándose mediante Proxy/Marshal)

Sin embargo, también hay puntos a tener en cuenta.

• El registro de 32 bits y de 64 bits es independiente (incluido WOW6432Node)
• Las estructuras propias requieren un diseño de marshaling
• Existe sobrecarga de IPC, así que hay que tener cuidado con las llamadas de alta frecuencia

En resumen, la vía más segura es «sacar el procesamiento de 64 bits a otro proceso y tender un puente con COM».

3. Flujo de procesamiento (diagrama de secuencia)

A continuación se muestra el flujo cuando una aplicación de 32 bits llama al procesamiento de una DLL de 64 bits.

sequenceDiagram
    accTitle: Diagrama de secuencia del puente COM de 32 y 64 bits
    accDescr: Muestra cómo la aplicación cliente de 32 bits llama a la DLL de 64 bits a través de un servidor COM local, con el marshaling y el Proxy o Stub cruzando el límite de proceso
    participant App as Aplicación cliente de 32 bits
    box rgba(100,100,255,0.1) Infraestructura de marshaling COM ya registrada
        participant Proxy as COM Proxy<br/>(lado de 32 bits)
        participant RPC as RPC/IPC<br/>(comunicación entre procesos)
        participant Stub as COM Stub<br/>(lado de 64 bits)
    end
    participant Server as Servidor COM de 64 bits<br/>(EXE)
    participant DLL as DLL de 64 bits

    App->>Proxy: ICalcService.Add(1, 2)
    rect rgba(100,100,255,0.1)
        Note over Proxy: Serializar los parámetros (marshaling)
        Proxy->>RPC: Datos serializados
        RPC->>Stub: Transferencia a través del límite de proceso
        Note over Stub: Deserializar los parámetros (unmarshaling)
    end
    Stub->>Server: Add(1, 2)
    Server->>DLL: Llamada a función nativa
    DLL-->>Server: Resultado: 3
    Server-->>Stub: Resultado: 3
    rect rgba(100,100,255,0.1)
        Note over Stub: Serializar el valor de retorno (marshaling)
        Stub-->>RPC: Resultado serializado
        RPC-->>Proxy: Transferencia a través del límite de proceso
        Note over Proxy: Deserializar el valor de retorno (unmarshaling)
    end
    Proxy-->>App: Resultado: 3

Puntos clave:

• La aplicación de 32 bits puede llamar de forma segura en cuanto a tipos a través de la interfaz ICalcService
• El runtime de COM cruza el límite de proceso usando la DLL de Proxy/Stub registrada, el marshaler de TypeLib, el marshaler estándar, etc.
• Como existe sobrecarga en la comunicación entre procesos, es preferible el procesamiento por lotes frente a las llamadas finas

4. Código de ejemplo (idea general)

4.1. Interfaz compartida, servidor y cliente

Lo siguiente es una idea conceptual. Para que funcione, hace falta además el registro descrito en 4.2.

// Interfaz compartida (equivalente a IDL)
[ComVisible(true)]
[Guid("7A4B5B23-0A2F-4D2B-9D4D-8A2A92B8B001")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface ICalcService
{
    int Add(int a, int b);
}

// COM LocalServer de 64 bits (lado EXE)
[ComVisible(true)]
[Guid("1C9B6F4D-1E9A-4E61-9A4F-6A0F1D2D9A11")]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("KomuraSoft.CalcService")]
public class CalcService : ICalcService
{
    public int Add(int a, int b)
    {
        // Aquí se llama a la DLL de 64 bits
        return a + b;
    }
}

// Lado de la aplicación de 32 bits (cliente)
Type t = Type.GetTypeFromProgID("KomuraSoft.CalcService");
var calc = (ICalcService)Activator.CreateInstance(t);
int result = calc.Add(1, 2);

Con esta forma, el lado de 32 bits puede tratarlo «con tipado». COM utiliza internamente el proxy/stub y realiza la llamada a través de IPC.

El atributo [ProgId("KomuraSoft.CalcService")] está para que el cliente pueda encontrarlo con Type.GetTypeFromProgID("KomuraSoft.CalcService"). El ProgID no es más que un «alias legible para humanos»; lo que realmente localiza el servidor es el registro del CLSID, que se explica a continuación.

4.2. Pasos mínimos de registro

COM funciona bajo el principio de que «el runtime de COM busca el CLSID registrado en el registro de Windows y lo inicia», así que el código que no está registrado nunca funcionará (Type.GetTypeFromProgID devuelve null, o CreateInstance produce REGDB_E_CLASSNOTREG). En el fondo, el registro necesario para un servidor EXE (LocalServer) se reduce a estas tres claves.

Aquí aparece la trampa que constituye el propio tema de este artículo. La documentación de Microsoft indica explícitamente que HKEY_LOCAL_MACHINE\SOFTWARE\Classes se comparte entre las aplicaciones de 32 y 64 bits, mientras que la subclave CLSID que cuelga de ahí (junto con Interface, entre otras) es distinta para el lado de 32 bits y el de 64 bits (el contenido real del lado de 32 bits está en WOW6432Node). Es decir, la clave del ProgID, una vez escrita, es visible desde ambos lados, pero el registro del CLSID debe escribirse tanto en la vista de 32 bits como en la de 64 bits, o el cliente de 32 bits no encontrará el servidor.

Lo más seguro es usar las opciones /reg:32 y /reg:64 del comando reg desde un símbolo del sistema con permisos de administrador (Microsoft desaconseja escribir Wow6432Node manualmente en la ruta).

:: Ejecutar desde un símbolo del sistema con permisos de administrador
set CLSID={1C9B6F4D-1E9A-4E61-9A4F-6A0F1D2D9A11}
set PROGID=KomuraSoft.CalcService
set SERVER=C:\Program Files\KomuraSoft\CalcServer.exe

:: 1) ProgID → CLSID (justo bajo HKLM\SOFTWARE\Classes se comparte entre 32/64)
reg add "HKLM\SOFTWARE\Classes\%PROGID%\CLSID" /ve /d "%CLSID%" /f

:: 2) CLSID → LocalServer32 y ProgID (bajo CLSID es distinto para 32/64, así que hay que escribir en ambos)
::    En el valor de LocalServer32 se guarda la ruta del ejecutable junto con las comillas.
::    Si se escribe /d "%SERVER%", el análisis de argumentos de reg.exe elimina las comillas y el valor
::    queda almacenado tal cual, C:\Program Files\... . COM interpreta esto como una línea de comandos,
::    así que primero intenta buscar C:\Program.exe, cortado antes del espacio
reg add "HKLM\SOFTWARE\Classes\CLSID\%CLSID%\LocalServer32" /ve /d "\"%SERVER%\"" /f /reg:64
reg add "HKLM\SOFTWARE\Classes\CLSID\%CLSID%\ProgID"        /ve /d "%PROGID%"     /f /reg:64
reg add "HKLM\SOFTWARE\Classes\CLSID\%CLSID%\LocalServer32" /ve /d "\"%SERVER%\"" /f /reg:32
reg add "HKLM\SOFTWARE\Classes\CLSID\%CLSID%\ProgID"        /ve /d "%PROGID%"     /f /reg:32

:: Comprobar el valor almacenado. Es correcto si aparece entre comillas como "C:\Program Files\..."
reg query "HKLM\SOFTWARE\Classes\CLSID\%CLSID%\LocalServer32" /ve /reg:64

Las comillas en LocalServer32 no son solo una cuestión de buenas formas. Sin comillas, C:\Program Files\... admite la interpretación de que se está pasando Files\... como argumento a C:\Program. Como resultado, en un entorno donde alguien tenga permisos para crear C:\Program.exe, ese ejecutable podría iniciarse primero. Si la ruta contiene espacios, incluya siempre las comillas.

Para darlo de baja basta con eliminar las mismas claves.

set CLSID={1C9B6F4D-1E9A-4E61-9A4F-6A0F1D2D9A11}
set PROGID=KomuraSoft.CalcService

reg delete "HKLM\SOFTWARE\Classes\CLSID\%CLSID%" /f /reg:64
reg delete "HKLM\SOFTWARE\Classes\CLSID\%CLSID%" /f /reg:32
reg delete "HKLM\SOFTWARE\Classes\%PROGID%" /f

Además, al iniciarse, el lado EXE debe anunciarle a COM que «él es el responsable de este CLSID». En C/C++ esto corresponde a CoRegisterClassObject, y en .NET Framework a RegistrationServices.RegisterTypeForComClients. El registro en el registro de Windows solo se encarga de que COM llegue a iniciar el EXE, así que si falta este anuncio se produce un fallo confuso: el EXE se inicia, pero no se puede crear el objeto.

Por otro lado, si solo se trata de probar durante el desarrollo, se puede registrar sin permisos de administrador escribiendo la misma estructura en HKCU\SOFTWARE\Classes en lugar de HKLM (HKEY_CLASSES_ROOT es una vista combinada de HKLM y HKCU). No obstante, HKCU\SOFTWARE\Classes\CLSID también se trata de forma distinta para 32 y 64 bits, así que sigue siendo necesario escribir en ambas vistas.

4.3. La forma de construirlo difiere entre .NET Framework y .NET (5 y posteriores)

El código anterior está en C#, pero el procedimiento cambia mucho según qué versión de .NET se use. Mezclar ambas es una fuente segura de bloqueos.

La configuración de este artículo (servidor EXE) queda fuera del alcance del EnableComHosting estándar en .NET (5 y posteriores), por lo que el proceso de registro hay que escribirlo por cuenta propia. Microsoft ofrece la muestra oficial OutOfProcCOM, así que si se va a construir con .NET, ese es el punto de partida.

5. Código de ejemplo completo

En GitHub se publica un ejemplo que implementa los conceptos anteriores de forma que realmente funciona.

Call64bitDLLFrom32bitProc - GitHub

Este repositorio incluye lo siguiente:

• Call64bitDLLFrom32bitProc/ - COM LocalServer de 64 bits (EXE)
• X64DLL/ - DLL de 64 bits (procesamiento real)
• X86App/ - Cliente de 32 bits (WinForms)
• scripts/ - Scripts de registro y baja del servidor COM

Si compila y registra siguiendo los pasos descritos en el README, podrá comprobar en la práctica cómo un proceso de 32 bits llama a una DLL de 64 bits.

6. Resumen

El puente COM no es una solución universal: es una configuración en la que queda muy claro qué tareas encajan y cuáles no. Antes de decidir adoptarlo, contraste su caso con la siguiente tabla.

Como reverso de la última fila, siempre vale la pena considerar la alternativa sencilla de «convertir el procesamiento del lado de 64 bits en un simple EXE de consola e intercambiar datos mediante argumentos y archivos». El puente COM resulta útil cuando se quiere mantener llamadas con tipado y cuando se quiere invocar repetidamente un servidor con estado.

Como próximos pasos, se recomienda seguir este orden.

1. Primero, clone el repositorio de ejemplo del capítulo 5, compile y registre según el README, y cree localmente una instancia que funcione.
2. Elija una sola función de su DLL de 64 bits y añada un método correspondiente a la interfaz equivalente a ICalcService del ejemplo, haciéndolo pasar.
3. Una vez que funcione, mida el número de llamadas y la cantidad de datos por llamada. Resolver de antemano la decisión de diseño de «orientarse hacia una granularidad gruesa» (agrupar varias llamadas en una sola) reduce los retrocesos posteriores.

7. Referencias

• Introducción al Component Object Model (COM) https://learn.microsoft.com/en-us/windows/win32/com/component-object-model–com–portal
• Registro de COM LocalServer32 https://learn.microsoft.com/en-us/windows/win32/com/localserver32
• Fundamentos de las interfaces COM https://learn.microsoft.com/en-us/windows/win32/com/the-component-object-model
• COM Interop (uso desde .NET) https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop
• Redirector de registro de WOW64 (HKLM\SOFTWARE\Classes se comparte, la subclave CLSID es distinta para 32/64) https://learn.microsoft.com/en-us/windows/win32/winprog64/shared-registry-keys
• Exponer componentes de .NET (Core / 5 y posteriores) a COM https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se puede llamar directamente a una DLL de 64 bits desde una aplicación de 32 bits?

No es posible. Un proceso de 32 bits no puede cargar una DLL de 64 bits, y esta es una restricción a nivel de sistema operativo, no algo que se pueda evitar con algún truco. Como la vía de llamar dentro del mismo proceso está cerrada desde el principio, es necesario separar el procesamiento del lado de 64 bits en otro proceso.

¿Cómo se puede usar una función de una DLL de 64 bits desde una aplicación de 32 bits?

La vía más segura es separarlos mediante Out-of-proc COM (servidor EXE). La DLL de 64 bits se llama desde un COM LocalServer (EXE) de 64 bits, y la aplicación de 32 bits la utiliza con tipado a través de una interfaz COM. Se comparte la interfaz COM (IDL/TypeLib) para exponer los tipos, y el runtime de COM cruza el límite de proceso mediante el proxy/stub y la comunicación entre procesos.

¿Cuáles son los puntos a tener en cuenta en una configuración de puente COM?

Hay principalmente tres. Que el registro de 32 bits y de 64 bits es independiente (incluido WOW6432Node), que las estructuras propias requieren un diseño de marshaling, y que existe sobrecarga en la comunicación entre procesos, por lo que hay que tener cuidado con las llamadas finas y de alta frecuencia. Es preferible orientarse al procesamiento por lotes antes que emitir un gran volumen de llamadas finas.

¿Existe un código de ejemplo que funcione realmente?

Sí. En el repositorio de GitHub Call64bitDLLFrom32bitProc se publica un conjunto de ejemplo completo que incluye un COM LocalServer (EXE) de 64 bits, una DLL de 64 bits, un cliente de 32 bits (WinForms) y los scripts de registro y baja del servidor COM. Si se compila y registra siguiendo los pasos del README, se puede comprobar en la práctica cómo un proceso de 32 bits llama a una DLL de 64 bits.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.