Cómo funciona la compatibilidad de aplicaciones en Windows — modo de compatibilidad, shims y Compatibility Administrator para prolongar aplicaciones antiguas

«Una aplicación de negocio de hace diez años, de la que ya no queda el código fuente, no arranca en un PC nuevo con Windows 11. Sin embargo, al elegir “Windows XP” en la pestaña de compatibilidad, funcionó. ¿Se puede seguir usándola así?». En los equipos que custodian aplicaciones antiguas hay consultas de este tipo.

El modo de compatibilidad no es una función que devuelva todo el SO a un Windows antiguo. Es un mecanismo que, solo para esa aplicación, complementa el comportamiento que asume un Windows antiguo. En el centro están las pequeñas correcciones de compatibilidad que se interponen entre la aplicación y la API de Windows: el shim.¹

Este artículo, dirigido a responsables de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones de Windows, se organiza en el orden qué se puede corregir → por qué funciona → cómo aplicarlo y distribuirlo → cómo decidir entre prolongar o migrar. A partir de fuentes primarias de Microsoft Learn, confirma lo que ocurre más allá de la casilla.

1. Primero la conclusión — el modo de compatibilidad se puede usar. Como prolongación, hay que gestionarlo

Seguir el negocio de momento con el modo de compatibilidad es, en sí, una elección razonable que usa un mecanismo previsto oficialmente por Windows. El propio Windows aplica correcciones de compatibilidad a aplicaciones conocidas.¹ La aplicación, sin embargo, no se ha corregido. El camino de fondo es, al final, dejarla en una forma que funcione sin shims.

Si usarlo o no se ordena mejor en este orden.

En particular, «devolver éxito a la comprobación de si es administrador» y «conceder privilegios de administrador» son cosas distintas. El shim está sujeto a las mismas restricciones de seguridad que la aplicación y no elude las protecciones del SO.¹² RunAsInvoker, igual, suprime la solicitud de elevación y arranca con los mismos privilegios que quien lo invoca; no es una función que aumente privilegios.³

Si se entiende el mecanismo, se puede pasar de una prolongación de «no se toca porque nadie sabe por qué funciona» a una en la que se puede explicar hasta dónde se puede confiar, en qué condiciones se rompe y cuándo rehacerla.

flowchart TB
    accTitle: Entender el mecanismo cambia la calidad de la prolongación
    accDescr: Usar el modo de compatibilidad sin conocer el mecanismo lleva a una prolongación inestable que nadie toca; si se entiende el mecanismo, se puede decidir con fundamento hasta dónde se puede confiar, qué lo romperá y cuándo rehacerla
    unknown["Usarlo sin conocer el mecanismo"] --> fear["Prolongación inestable que no se toca"]
    known["Usarlo entendiendo el mecanismo"] --> judge["Decisión con fundamento"]
    judge -.-> j1["Hasta dónde se puede confiar"]
    judge -.-> j2["Qué lo romperá"]
    judge -.-> j3["Cuándo rehacerla"]

Figura 1: Aunque sea la misma prolongación, la calidad cambia entre la inquietud de no conocer el mecanismo y una decisión basada en entenderlo.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (16 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. El primer aislamiento — ¿es un problema que un shim puede corregir?

2.1. Lo que se puede corregir es un problema del lado de la aplicación en modo usuario

Lo que un shim puede hacer cabe en el alcance de lo que también se puede hacer corrigiendo el código de la aplicación. Es un medio alternativo cuando no hay código fuente, el soporte del proveedor ha terminado o no se puede corregir ahora mismo, no algo más potente que corregir el código.¹

Por ejemplo, entran en el ámbito problemas como rechazar el arranque según la versión del SO, asumir un destino de escritura antiguo, o pedir privilegios de administrador que en realidad no hacen falta. Los shims concretos se confirman en el capítulo 5.

2.2. Casos que no se resuelven por más que se pruebe la configuración

Los problemas siguientes necesitan una medida distinta del modo de compatibilidad.

Los problemas de modo kernel y las restricciones de seguridad vienen del lugar en el que se ejecuta el shim.¹ ForceAdminAccess y WRPMitigation solo falsifican el éxito de una comprobación o de una escritura para que la aplicación siga adelante; no reescriben de verdad un recurso protegido.²

En el problema de 16 bits, compruebe no solo la aplicación, sino también el instalador. Aunque el cuerpo sea de 32 bits, un paquete antiguo cuyo arranque (el stub) es de 16 bits da «la aplicación funciona, pero no se puede instalar». En Windows de 64 bits, el identificador tiene bits válidos de 32 bits y no se puede recortar a 16 para pasarlo, entre otras razones por las que las aplicaciones de 16 bits no se admiten y el arranque falla con ERROR_BAD_EXE_FORMAT.⁴

flowchart TB
    accTitle: Casos en los que el shim no funciona
    accDescr: El shim se ejecuta dentro de un proceso en modo usuario, así que no funciona en un problema de controlador de modo kernel, una aplicación de 16 bits, el acceso directo al hardware ni eludir un mecanismo de seguridad
    shim["Shim (se ejecuta en modo usuario)"] -->|no funciona| drv["Controlador de kernel"]
    shim -->|no funciona| b16["Aplicación de 16 bits"]
    shim -->|no funciona| hw["Acceso directo al hardware"]
    shim -->|no funciona| sec["Eludir un mecanismo de seguridad"]
    b16 -.-> fmt["En 64 bits falla el propio arranque"]
    sec -.-> fake["Solo falsifica el éxito para seguir adelante"]

Figura 2: El shim se limita al modo usuario y no llega al kernel, a 16 bits, al acceso directo al hardware ni a eludir la seguridad.

Además, una aplicación con comprobación de integridad propia, como una protección anticopia antigua o una detección de alteración, a veces trata el propio hook de API como anomalía. Tampoco es cierto que cualquier aplicación de modo usuario se pueda salvar con un shim.

3. Separar funciones parecidas — shim, virtualización de UAC, WOW64 y virtualización de PPP

El mecanismo que está trabajando cuando «una aplicación antigua funcionó» no es solo el shim. Conviene separar las capas de compatibilidad hacia atrás que tiene Windows. En la práctica, a veces se combinan varias.

3.1. Virtualización de UAC: desviar el destino de escritura por usuario

La virtualización de UAC es una medida transitoria que actúa sobre procesos interactivos de 32 bits sin manifiesto. Microsoft misma la sitúa como técnica provisional que tiene intención de quitar de Windows en el futuro.⁵ WOW64, que ejecuta aplicaciones de 32 bits, y la virtualización de UAC, que transfiere el destino de escritura por usuario, son mecanismos distintos.

La redirección a Wow6432Node y los daños reales de VirtualStore, con su tratamiento, se cubren en Redirección y virtualización de 32/64 bits en el registro de Windows. Este artículo se queda en el alcance necesario para distinguirlos del shim.

flowchart TB
    accTitle: Situación de la virtualización de UAC
    accDescr: La virtualización de UAC es una medida transitoria que actúa sobre procesos interactivos de 32 bits sin manifiesto, transfiere la escritura al VirtualStore por usuario, y Microsoft misma declara que es una técnica provisional con intención de quitarla de Windows en el futuro
    proc["Proceso interactivo de 32 bits sin manifiesto"] --> uacv["Actúa la virtualización de UAC"]
    uacv --> vs["Transferencia al VirtualStore por usuario"]
    uacv -.-> tmp["Técnica provisional con intención de quitarla en el futuro"]

Figura 3: La virtualización de UAC es una medida transitoria para procesos de 32 bits sin manifiesto y no se puede confiar en ella de forma permanente.

3.2. Virtualización de PPP: estirar un dibujo antiguo

Una aplicación que no declara compatibilidad con PPP se trata como si se dibujara a 96 PPP (100 %). Windows estira ese mapa de bits, de modo que en un monitor de PPP alto la imagen se ve borrosa. «Invalidar la configuración de PPP alto» de la pestaña de compatibilidad es el interruptor que cambia este comportamiento de virtualización.⁶

flowchart TB
    accTitle: Mecanismo de la virtualización de PPP
    accDescr: Una aplicación que no declara compatibilidad con PPP se trata como dibujada a 96 PPP; Windows estira el mapa de bits y se ve borrosa, y la invalidación de PPP alto de la pestaña de compatibilidad cambia este comportamiento de virtualización
    app["Aplicación que no declara compatibilidad con PPP"] --> treat["Se trata como dibujada a 96 PPP"]
    treat --> stretch["Se muestra estirando el mapa de bits"]
    stretch --> blur["Se ve borrosa en un monitor de PPP alto"]
    tab["Invalidar la configuración de PPP alto"] -.->|cambia el comportamiento de virtualización| treat

Figura 4: Una aplicación no compatible con PPP se estira tratándola como 96 PPP, y la invalidación de la pestaña de compatibilidad es el interruptor de esta virtualización.

4. Por qué funciona el modo de compatibilidad — el shim y su aplicación al arrancar

4.1. Sustituir el destino de la llamada a la API

En la ruta por la que un archivo ejecutable de Windows (formato PE) llama a una API de una DLL externa está la tabla de direcciones de importación (IAT). En una llamada a GetVersionEx, por ejemplo, el control pasa a la dirección escrita en la IAT.

El shim, al cargar la aplicación, reescribe esa entrada de la IAT con la dirección del código del shim. Eso es un hook de API. Las API que se obtienen de forma dinámica con GetProcAddress se cubren enganchando el propio GetProcAddress.¹

El shim que se interpone devuelve una versión antigua del SO o cambia el destino de acceso a archivos y, si hace falta, llama a la API real. Muestra a la aplicación «el comportamiento de Windows que espera» y pasa al SO una llamada que encaja con el mecanismo actual: un intérprete, en cierto sentido.

flowchart TB
    accTitle: Ruta por la que el shim se interpone en la llamada a la API
    accDescr: La llamada a la API de la aplicación pasa por la IAT; al cargar se reescribe la entrada de la IAT hacia el shim, el shim se interpone, falsifica la misma respuesta que un Windows antiguo y, si hace falta, llama a la API real
    app["Aplicación"] -->|llamada a la API| iat["Entrada de la IAT"]
    iat -->|al cargar, se reescribe hacia el shim| shim["Shim (intérprete)"]
    shim -->|si hace falta| api["API real de Windows"]
    shim -.-> lie["Falsifica la misma respuesta que un Windows antiguo"]
    gpa["Llamada vía GetProcAddress"] -.->|se cubre con un hook| shim

Figura 5: El shim se interpone entre la aplicación y la API de Windows. Lo que se reescribe es la IAT del lado de la aplicación; el SO en sí no cambia.

Lo que cambia es la ruta de llamada del lado de la aplicación, no el SO en sí. Como el shim se ejecuta bajo las mismas restricciones de seguridad que la aplicación, tampoco hace falta relajar la configuración de seguridad del SO para usarlo.¹

4.2. El .sdb decide «qué se aplica a qué EXE»

La base de datos de shims es un archivo binario con extensión .sdb. Identifica el archivo ejecutable con atributos de coincidencia como el nombre, el tamaño, la suma de comprobación y la versión, y los coteja al arrancar el proceso. Los términos que se usan aquí se separan así.⁷

No se coteja solo la aplicación a la que el usuario ha configurado el modo de compatibilidad. En el arranque de todos los procesos se coteja con la base de datos estándar del SO. Windows incluye correcciones de miles de aplicaciones conocidas; el contenido está bajo %WINDIR%\AppPatch. Las correcciones de compatibilidad que proporciona Microsoft se envían como parte de Windows y se actualizan con Windows Update.¹

flowchart TB
    accTitle: Cotejo con la base de datos de shims al arrancar el proceso
    accDescr: En el arranque de todos los procesos se coteja con la base de datos de shims; si hay un registro que coincide por atributos, se inyecta un shim con Appfix o se muestra un mensaje de Apphelp; si no, arranca tal cual
    start["Arranque del proceso"] --> db["Cotejo con la base de datos de shims (.sdb)"]
    db -.-> attr["Cotejo por nombre de archivo, tamaño, etc."]
    db --> hit{"¿Hay registro?"}
    hit -->|sí| appfix["Appfix (inyecta el shim)"]
    hit -->|sí| apphelp["Apphelp (muestra un mensaje)"]
    hit -->|no| plain["Arranca tal cual"]
    layer["Capa de compatibilidad (modo de compatibilidad)"] -.->|conjunto de varios shims y marcas| appfix

Figura 6: El cotejo no es solo de las aplicaciones con modo de compatibilidad configurado: se hace en el arranque de todos los procesos.

La capa de compatibilidad incluye no solo hooks de API, sino también marcas de arranque. El RunAsInvoker del capítulo 7 no intercepta la API: es una corrección de compatibilidad que actúa sobre el nivel de ejecución al arrancar, como marca del cargador.³

4.3. PCA a veces encuentra el problema y lo aplica

Aunque el administrador no lo configure a mano, PCA (Program Compatibility Assistant) a veces aplica una configuración de compatibilidad. PCA vigila la ejecución de la aplicación y, si detecta indicios de un problema conocido, propone una corrección o, en algunos casos, la aplica de forma automática.⁸

Por ejemplo, a una aplicación que se bloquea al llamar código dentro de una DLL ya liberada se le usa un modo de compatibilidad como PINDLL; a una que falla al escribir en un archivo de Windows protegido, WRPMITIGATION.⁸

flowchart TB
    accTitle: Flujo por el que PCA aplica de forma automática una configuración de compatibilidad
    accDescr: PCA vigila la ejecución de la aplicación y, si detecta indicios de un problema de compatibilidad conocido, propone al usuario aplicar la corrección o, en algunos casos, aplica de forma automática la configuración de compatibilidad
    run["Ejecución de la aplicación"] --> pca["PCA vigila"]
    pca --> sign{"¿Indicios de un problema conocido?"}
    sign -->|sí| resp{"¿Qué caso?"}
    resp -->|se responde con una propuesta| suggest["Propone aplicar la corrección"]
    resp -->|algunos casos| auto["Aplica de forma automática la configuración de compatibilidad"]
    sign -->|no| none["Se ejecuta tal cual"]
    auto -.-> ex["Ejemplo: PINDLL o WRPMITIGATION"]

Figura 7: PCA vigila la ejecución de la aplicación y, si detecta indicios de un problema conocido, propone la corrección o la aplica de forma automática.

El fenómeno de «el modo de compatibilidad estaba marcado sin haberlo configurado» es, en muchos casos, esta ruta. No tiene por qué ser un fallo o un error de operación: también es el resultado de que Windows ha respondido al problema.

5. Elegir la corrección a partir del síntoma — shims representativos y la comprobación de versión

5.1. Lo que cubren los shims ya hechos

De los shims ya hechos que publica Microsoft, estos son los que se usan a menudo para prolongar una aplicación de negocio.²

Lo que hacen muchos shims es devolver la respuesta que espera una aplicación antigua. Reproducen, solo dentro de ese proceso, las premisas de la época en que se hizo la aplicación: «el disco llega hasta 2 GB», «el SO es XP», «la comprobación de administrador tiene éxito». Como se vio en el capítulo 2, falsificar la respuesta y cambiar de verdad los privilegios o los recursos son cosas distintas.

5.2. El valor de GetVersionEx cambia aunque no se elija el modo de compatibilidad

La falsificación de versión no es solo cosa de haber elegido a mano el modo de compatibilidad. A partir de Windows 8.1, el valor que devuelve GetVersionEx depende del manifiesto de la aplicación. Si en <compatibility> no hay declaración <supportedOS>, aunque esté en un Windows nuevo devuelve 6.2, equivalente a Windows 8. Si hay declaración, devuelve el valor hasta el SO más alto declarado. Por ejemplo, una aplicación que declara el GUID de Windows 8.1, incluso en Windows 11, es 6.3.⁹¹⁰

Si además se aplica un shim de la familia VersionLie, informa la versión del SO elegido en el modo de compatibilidad. Hay que mirar en orden la respuesta predeterminada por el manifiesto y la sustitución de respuesta por el shim.⁹

flowchart TB
    accTitle: Cómo se decide la versión del SO que ve la aplicación
    accDescr: El valor que devuelve GetVersionEx lo decide si hay declaración supportedOS en el manifiesto; si no hay, devuelve 6.2 equivalente a Windows 8; si hay, el valor hasta el SO más alto declarado; si se aplica un shim VersionLie, se sobrescribe con la versión del SO elegido en el modo de compatibilidad
    q["Consulta de GetVersionEx"] --> m{"¿Hay declaración supportedOS?"}
    m -->|no| v62["Devuelve el equivalente a Windows 8 (6.2)"]
    m -->|sí| decl["Valor hasta el SO más alto declarado"]
    v62 --> lie{"¿Shim de la familia VersionLie aplicado?"}
    decl --> lie
    lie -->|sí| fake["Valor del SO elegido en el modo de compatibilidad"]
    lie -->|no| asis["Se devuelve el valor tal cual"]

Figura 8: La versión de Windows que ve la aplicación se decide en varios escalones, manifiesto y shim.

Por tanto, el lugar que hay que comprobar también se divide por el síntoma. Si una aplicación propia está tratando Windows 11 como Windows 8, primero compruebe la declaración supportedOS. Si una aplicación antigua rechaza el arranque solo con la comprobación de versión, vale la pena probar VersionLie. A menudo el comportamiento real no tiene problema en un SO nuevo, y este tipo tiene alta probabilidad de que el shim elimine el rechazo del arranque.

flowchart TB
    accTitle: Dos síntomas causados por la versión y su tratamiento
    accDescr: Si una aplicación propia trata Windows 11 como 8, sospeche la declaración supportedOS del manifiesto; una aplicación antigua que rechaza el arranque por la comprobación de versión se puede superar con alta probabilidad con un shim VersionLie
    sym1["Trata Windows 11 como 8"] --> fix1["Sospechar la declaración supportedOS"]
    sym2["Rechazo de arranque por comprobación de versión"] --> fix2["Intentar superarlo con VersionLie"]
    fix2 -.-> why["A menudo el comportamiento en sí no tiene problema en un SO nuevo"]

Figura 9: Si el síntoma es que el juicio se queda antiguo, sospeche el manifiesto; si es rechazo de arranque, VersionLie.

6. Confirmar primero en un equipo — la pestaña de compatibilidad y la clave Layers

6.1. Ver dónde se guarda la casilla

La configuración que se guarda en la pestaña de compatibilidad de las propiedades se escribe en la clave del Registro AppCompatFlags\Layers. Es el destino de especificación de la capa de compatibilidad que también usa la configuración de compatibilidad de aplicaciones de DXGI.¹¹

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

En un EXE al que se ha configurado «Windows XP (Service Pack 3)», «Ejecutar este programa como administrador» e «Invalidar la configuración de PPP alto», se ve por ejemplo un valor como el siguiente.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

La correspondencia representativa entre cada elemento y el valor es la siguiente. Es un ejemplo de Windows 11; el nombre del elemento y el valor pueden cambiar según la versión del SO.

6.2. Separar el usuario al que se aplica y el momento de la aplicación

El lado HKCU es configuración solo de ese usuario. Si se guarda desde «Cambiar la configuración para todos los usuarios», se escribe en la clave del mismo nombre de HKLM y se aplica a todos los usuarios. En el kit de equipos, compruebe en cuál se está guardando.

Además, la configuración se aplica al proceso la siguiente vez que se arranca ese EXE. El cargador lee el valor guardado y aplica la capa de compatibilidad correspondiente.

flowchart TB
    accTitle: Flujo hasta que surte efecto la configuración de la pestaña de compatibilidad
    accDescr: La configuración de la pestaña de compatibilidad se guarda en la clave Layers de AppCompatFlags como ruta del EXE y valor; la siguiente vez que se arranca ese EXE, el cargador lee el valor y aplica al proceso la capa de compatibilidad correspondiente
    tab["Configurar en la pestaña de compatibilidad"] --> reg["Guardar la ruta del EXE y el valor en la clave Layers"]
    reg --> boot["Siguiente arranque del EXE"]
    boot --> loader["El cargador lee el valor"]
    loader --> apply["Aplica la capa de compatibilidad al proceso"]
    reg -.-> hkcu["HKCU es solo ese usuario"]
    reg -.-> hklm["HKLM surte efecto para todos los usuarios"]

Figura 10: La realidad de la casilla es una escritura en la clave Layers, y la aplicación ocurre en el siguiente arranque.

6.3. No confunda el modo de compatibilidad con la especificación de elevación

RUNASADMIN convive en la misma clave Layers que WINXPSP3. Si parece que «al configurar el modo de compatibilidad también se añadió o se quitó la elevación», comprobar el valor de forma directa permite separar la especificación de la capa de compatibilidad de la de elevación.

La pestaña de compatibilidad es la entrada a capas ya hechas representativas. La tarea de elegir shims individuales y combinarlos la asume Compatibility Administrator, en el capítulo 8. Antes, veamos RunAsInvoker, que tiene mucho uso en la operación cotidiana.

7. RunAsInvoker — suprimir solo la solicitud de elevación innecesaria

7.1. Separar «pide administrador» de «necesita privilegios de administrador»

Hay aplicaciones de negocio antiguas que, por requireAdministrator en el manifiesto o por una detección errónea de instalador según el nombre o el contenido del EXE, piden elevación de UAC en cada arranque. Sin embargo, muchas solo lo piden por un diseño heredado de la era de XP y en realidad no usan privilegios de administrador.

RunAsInvoker sobrescribe tanto la detección de instalador como el tratamiento del manifiesto y arranca con el token heredado del proceso padre. Si quien lo invoca tiene privilegios de usuario estándar, se queda con esos privilegios.³

flowchart TB
    accTitle: Cómo RunAsInvoker suprime la solicitud de elevación
    accDescr: La declaración requireAdministrator del manifiesto o una detección errónea de instalador son la causa de la solicitud de elevación de UAC al arrancar; si se aplica RunAsInvoker se sobrescriben ambas y arranca con el token heredado del proceso padre
    manifest["Declaración requireAdministrator"] --> shim{"¿RunAsInvoker aplicado?"}
    detect["Detección errónea como instalador"] --> shim
    shim -->|no| uac["Solicitud de elevación de UAC en cada arranque"]
    shim -->|sí| token["Arranca con el token del padre"]
    token -.-> limit["Una operación que exige administrador falla dentro de la aplicación"]

Figura 11: RunAsInvoker solo sobrescribe la causa de la solicitud de elevación; los privilegios no aumentan.

7.2. Probarlo de forma temporal con una variable de entorno

Sin crear un .sdb, se puede aplicar de forma temporal la misma capa con la variable de entorno __COMPAT_LAYER. Lo siguiente es un ejemplo que se aplica a los procesos hijo que se arrancan desde ese símbolo del sistema o PowerShell.

:: Aplicar RunAsInvoker a los procesos hijo que se arranquen desde este símbolo del sistema
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# En el caso de PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

Adóptelo después de confirmar que, con los mismos privilegios estándar que el usuario real, funcionan hasta las operaciones que el negocio necesita.² Si la aplicación no necesita privilegios de administrador, empaquetar el comando en un archivo por lotes y distribuirlo como atajo reduce la distribución de privilegios de administrador local y las llamadas a informática cada vez que UAC pide la contraseña. Es una técnica de compatibilidad en la dirección del principio de privilegio mínimo.

flowchart TB
    accTitle: Efecto de distribuir un lote de RunAsInvoker
    accDescr: Si se distribuye como atajo un archivo por lotes de 2 líneas que configura RunAsInvoker, no hace falta dar privilegios de administrador local a los usuarios estándar, informática deja de ser llamada por la contraseña de UAC, y la operación se alinea con el principio de privilegio mínimo
    bat["Distribuir un lote de 2 líneas"] --> noadmin["No hace falta dar privilegios de administrador"]
    bat --> nocall["Informática no es llamada por UAC"]
    noadmin --> lp["Operación alineada con el privilegio mínimo"]
    nocall --> lp

Figura 12: Solo con distribuir el lote se reducen tanto la distribución de privilegios de administrador como las llamadas por UAC.

7.3. Distinguir el alcance que funciona de la aplicación permanente y de la corrección

RunAsInvoker no aumenta los privilegios. Una escritura en HKLM o una actualización bajo Program Files que realmente necesita privilegios de administrador falla dentro de la aplicación. Si se cumplen las condiciones, a veces la virtualización de UAC la transfiere a VirtualStore. Si parece que «guardar la configuración ha dejado de funcionar», sospeche la virtualización.⁵

El método de la variable de entorno solo funciona en los procesos hijo que arrancan heredando ese entorno. Para una aplicación permanente, use la configuración directa en la clave Layers o la distribución de un .sdb. En la pestaña de compatibilidad no hay un elemento para elegir RUNASINVOKER.

flowchart TB
    accTitle: Aplicación temporal y permanente de RunAsInvoker
    accDescr: La aplicación mediante la variable de entorno COMPAT_LAYER solo funciona en los procesos hijo arrancados desde ahí; para aplicarlo de forma permanente se usa la configuración directa en la clave Layers o la distribución con .sdb
    env["Configurar con variable de entorno"] --> child["Solo funciona en el proceso hijo"]
    child -.-> tmp["Aplicación temporal"]
    layers["Configurar de forma directa en la clave Layers"] --> always["Aplicación permanente"]
    sdb["Distribuir con sdb"] --> always

Figura 13: El método de la variable de entorno es una aplicación temporal limitada al proceso hijo; para hacerlo permanente se usa la clave Layers o un .sdb.

Si se puede corregir la aplicación, más que añadir configuración de compatibilidad, el arreglo de fondo es mover el destino de guardado de la configuración bajo %APPDATA% y declarar asInvoker en el manifiesto.³

8. Desplegarlo en la organización — Compatibility Administrator y sdbinst

8.1. Alinear los 32/64 bits de la aplicación y de la herramienta

Compatibility Administrator está incluido en el Windows ADK (Windows Assessment and Deployment Kit).¹² Se instalan la versión de 32 bits y la de 64 bits; para corregir una aplicación de 32 bits se usa la de 32 bits, y para una de 64 bits, la de 64 bits.¹³

Otra precaución: no decida que «está corregido» tras probarlo como administrador. En estado elevado, la virtualización de UAC y la redirección no actúan como de costumbre y se puede juzgar mal el resultado. Confirme el efecto de la corrección con la misma cuenta y los mismos privilegios que el usuario real.²

flowchart TB
    accTitle: Dos precauciones al usar Compatibility Administrator
    accDescr: Para corregir una aplicación de 32 bits se usa la versión de 32 bits, y para una de 64 bits la de 64 bits; el efecto de la corrección se confirma no en estado elevado, sino con la misma cuenta y privilegios que el usuario real
    app32["Aplicación de 32 bits"] --> tool32["Corregir con la versión de 32 bits"]
    app64["Aplicación de 64 bits"] --> tool64["Corregir con la versión de 64 bits"]
    elev["Probar en estado elevado"] -.-> wrong["Riesgo de juzgar mal que está corregido"]
    user["Probar con los mismos privilegios que el usuario real"] --> ok["Confirmar el efecto correctamente"]

Figura 14: El uso diferenciado de las versiones de 32 y 64 bits y la confirmación con los mismos privilegios que el usuario real son las precauciones de entrada.

8.2. Probar primero con una capa y reducir a los shims necesarios y al EXE de destino

La creación de una base de datos de compatibilidad personalizada avanza en este orden.¹⁴

1. En el panel izquierdo, cree una base de datos nueva en «Custom Databases» y elija «Create New» → «Application Fix».
2. Introduzca el nombre de la aplicación y del proveedor y especifique el archivo EXE de destino.
3. Elija un modo de compatibilidad (capa) como «compatible con Windows XP» y pruébelo primero con el conjunto de shims.
4. Si hace falta, elija correcciones de compatibilidad individuales. Se puede reducir a una configuración mínima, solo VersionLie o solo CorrectFilePaths.
5. Confirme las condiciones de coincidencia —tamaño de archivo, suma de comprobación, versión, etc.— y guarde.

Tanto «elegir el shim que funciona» como «hacerlo funcionar solo en el EXE correcto» son necesarios. La coincidencia suele bastar con las condiciones básicas predeterminadas, pero deje una condición que identifique la versión de la aplicación. Así, cuando el proveedor saque una versión corregida, no se seguirá aplicando la corrección antigua también a esa versión nueva.¹⁴¹⁵

flowchart TB
    accTitle: Procedimiento para crear una base de datos de compatibilidad personalizada
    accDescr: Crear un Application Fix en una base de datos nueva, especificar el nombre de la aplicación y el EXE de destino, probar con el conjunto del modo de compatibilidad, reducir si hace falta a shims individuales, confirmar las condiciones de coincidencia y guardar
    new["Crear una base de datos nueva"] --> fix["Elegir Application Fix"]
    fix --> info["Especificar el nombre de la aplicación y el EXE de destino"]
    info --> layer["Probar con el conjunto del modo de compatibilidad"]
    layer --> single["Si hace falta, reducir a shims individuales"]
    single --> match["Confirmar las condiciones de coincidencia y guardar"]
    match -.-> ver["Dejar una condición que identifique la versión"]

Figura 15: Application Fix se prueba primero con el conjunto del modo de compatibilidad, se reduce a la configuración mínima y se limita el destino con las condiciones de coincidencia.

Pruebe el .sdb creado en una máquina de verificación, confirme que funciona como se pretendía y después pase a la distribución.

8.3. Aplicar y quitar con sdbinst, y gestionar las actualizaciones por GUID

La aplicación en cada PC se hace ejecutando sdbinst.exe con privilegios de administrador. Además de instalar, se puede desinstalar especificando el archivo o el GUID de la base de datos.¹⁵

:: Instalar (-q es silencioso, sin confirmación)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Desinstalar (especificación por archivo)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Desinstalar (especificación por GUID de la base de datos)
sdbinst -q -u -g {GUID de la base de datos}

En una organización donde crecen las correcciones de compatibilidad, más que un .sdb individual por cada instalador de aplicación, se recomienda un modo de gestión centralizada, reuniéndolas en una base de datos personalizada de la empresa o por departamento. Es más fácil de gestionar actualizar y redistribuir una base de datos reunida que seguir muchas bases de datos de una sola línea.¹⁵

Una base de datos personalizada tiene un GUID propio. Si se instala una versión nueva con el mismo GUID, la versión antigua se sustituye de forma automática. La distribución se carga en una vía existente que se pueda ejecutar con privilegios de administrador, como un paquete MSI o un script de inicio.¹⁵

flowchart TB
    accTitle: Flujo desde la creación del .sdb personalizado hasta la distribución
    accDescr: Crear la base de datos de compatibilidad personalizada con Compatibility Administrator, probarla en una máquina de verificación, aplicarla en cada PC con sdbinst y, al actualizar, instalar una versión nueva con el mismo GUID para que la antigua se sustituya de forma automática
    make["Crear con Compatibility Administrator"] --> test["Probar en la máquina de verificación"]
    test --> deploy["Aplicar en cada PC con sdbinst"]
    deploy --> update["Instalar una versión nueva con el mismo GUID"]
    update -.-> replace["La versión antigua se sustituye de forma automática"]
    deploy -.-> inv["Se registra en Programas y características"]

Figura 16: El .sdb personalizado se despliega en el flujo creación, verificación y distribución con sdbinst, y las actualizaciones se gestionan por GUID.

La base de datos personalizada instalada también se registra en «Programas y características (aplicaciones instaladas)» y sirve para el inventario y para confirmar la eliminación. Deje también en el inventario de activos qué .sdb se ha puesto en qué PC.

9. Decidir después de que funciona — el mantenimiento de la prolongación y el plazo de migración

9.1. Separar la corrección que proporciona el SO de la decisión de aplicación de la propia organización

Aunque funcione con un shim, no se ha corregido el problema de la aplicación en sí. El shim es un remedio provisional ajustado a un uso concreto de la API, y si cambia la implementación del SO las premisas pueden romperse.

El shim que proporciona Microsoft se mantiene, como parte de Windows, con Windows Update.¹ En cambio, gestionar qué se ha aplicado con una base de datos personalizada y si esa combinación permite seguir el negocio es de la propia organización. Incluya en el coste de la prolongación la verificación en cada actualización de características.

flowchart TB
    accTitle: El shim como remedio provisional y la responsabilidad de mantenimiento
    accDescr: El shim es una mentira ajustada a un uso concreto de la API y si cambia la implementación del SO las premisas se rompen; el shim que proporciona Microsoft se mantiene con Windows Update, pero ocuparse de la mentira aplicada con una base de datos personalizada es de la propia organización, y la verificación en cada actualización de características es el coste de la prolongación
    shim["El shim es una mentira de remedio provisional"] --> break["Si cambia la implementación del SO, las premisas se rompen"]
    ms["Shim que proporciona Microsoft"] --> wu["Se mantiene con Windows Update"]
    own["Mentira de la base de datos personalizada"] --> self["Quien se ocupa es la propia organización"]
    self --> cost["La verificación en cada actualización de características es el coste de la prolongación"]

Figura 17: La responsabilidad de mantener esa mentira que es el shim se divide entre la parte que proporciona Microsoft y la personalizada de la propia organización.

9.2. Decidir por el tiempo de uso restante, la profundidad de la dependencia y el régimen de verificación

Es importante no decidir un uso a largo plazo solo por el hecho de que «funcionó con el modo de compatibilidad». Que funcione con un shim significa que ha cabido en el recipiente que Windows ha preparado. Decida alineando los ejes siguientes.

9.3. Si se prolonga, reunir registro, verificación y plazo en un conjunto

1. Registrar. Deje qué shim o capa se aplicó a qué EXE y por qué. Incluya también en el inventario el valor de la clave Layers y el GUID del .sdb. La idea de no pasar al siguiente responsable un estado de «nadie sabe por qué funciona» es la misma conservación que se trató en Cuando hereda un sistema sin código fuente ni documentación.
2. Verificar. En cada actualización de características de Windows, confirme el arranque y las operaciones principales de las aplicaciones en prolongación. Enlácelo también con el plan de cambio de SO que se trata en La salida realista tras el fin de soporte de Windows 10.
3. Poner un plazo. Fije el final de la prolongación, por ejemplo «hasta el siguiente cambio del sistema troncal» o «hasta marzo de 2028», y haga correr en paralelo el estudio de la migración.

flowchart TB
    accTitle: Conjunto de 3 puntos de operación si se decide prolongar
    accDescr: Registrar en un inventario con qué shim funciona, verificar el funcionamiento de las aplicaciones en prolongación con shim en cada actualización de características, fijar el final de la prolongación y hacer correr en paralelo el estudio de la migración
    decide["Decidir prolongar"] --> rec["Registrar: qué shim la hace funcionar, al inventario"]
    rec --> verify["Verificar: confirmar el funcionamiento en cada actualización de características"]
    verify --> deadline["Plazo: fijar el final de la prolongación"]
    deadline --> mig["Hacer correr en paralelo el estudio de la migración"]

Figura 18: La prolongación se opera como un conjunto de registro, verificación y plazo, hasta hacer correr en paralelo el estudio de la migración.

9.4. Usar el shim para ganar el período de estudio y preparación de la migración

Las opciones de migración cambian según la técnica de la aplicación. Si es de VB6, el punto de partida son las tres opciones —reescritura completa, conversión automática y migración por etapas— organizadas en ¿Hasta cuándo seguirán funcionando las aplicaciones VB6?. Si depende de ActiveX/OCX, se puede usar la tabla de decisión «mantener, envolver o reemplazar» de ActiveX / OCX: cómo tratarlos hoy.

Lo sano es situar el shim como un medio para ganar con seguridad el período de estudio y preparación de ese proyecto de migración.

flowchart TB
    accTitle: Opciones del lado de la migración y situación del shim
    accDescr: El procedimiento habitual de migración cambia según la técnica de la aplicación; si es de VB6, las tres opciones son reescritura, conversión automática y migración por etapas; si depende de ActiveX, se usa la tabla de decisión mantener, envolver o reemplazar; el shim se sitúa como una ganancia de tiempo que gana con seguridad el período de estudio y preparación del proyecto de migración
    tech{"¿Cuál es la técnica de la aplicación?"} -->|de VB6| vb["Reescritura, conversión automática, migración por etapas"]
    tech -->|depende de ActiveX| ax["Mantener, envolver o reemplazar"]
    shim["Prolongación con shim"] -.->|ganar tiempo de estudio y preparación| tech

Figura 19: El procedimiento habitual de migración lo decide la técnica de la aplicación, y el shim se sitúa como una ganancia de tiempo de ese período de estudio.

10. Resumen

El modo de compatibilidad es un mecanismo que, solo para la aplicación, complementa el comportamiento que asume un Windows antiguo. El shim, que está en el centro, se interpone en la llamada a la API sustituyendo la IAT y complementa la comprobación de versión o el destino de acceso. El propio Windows lo usa a través de la base de datos predeterminada y de PCA.

La respuesta se piensa en este orden: primero aislar si está en el ámbito de aplicación del shim, confirmar la configuración necesaria con la pestaña de compatibilidad o RunAsInvoker y, en un despliegue organizativo, gestionarla con Compatibility Administrator y sdbinst. Los puntos prácticos son la elección de la herramienta de 32/64 bits, la verificación con los privilegios del usuario real y la gestión del destino y de la versión mediante las condiciones de coincidencia y el GUID.

Sin embargo, se limita al modo usuario y no elude un mecanismo de seguridad. Un problema de controlador de kernel, de una aplicación de 16 bits en Windows de 64 bits o de acceso directo al hardware necesita otra medida. RunAsInvoker tampoco aumenta privilegios: solo suprime una solicitud de elevación innecesaria.

Después de que funciona, registrar la configuración, verificarla en cada actualización de características y poner un plazo para hacer correr en paralelo la migración. Hasta ahí llega la decisión de confiar en el modo de compatibilidad.

La próxima vez que una casilla haga funcionar una aplicación antigua, vuelva a preguntar esto. «¿Gracias a qué mentira funciona esta aplicación? ¿Hasta cuándo valdrá esa mentira?». Si se puede responder, la prolongación es una estrategia decente.

Artículos relacionados

• Redirección y virtualización de 32/64 bits en el registro de Windows — Wow6432Node y el problema del «valor que debería estar y no está»
• ¿Hasta cuándo seguirán funcionando las aplicaciones VB6? — Estado del soporte del runtime y un camino práctico hacia la migración a .NET
• ActiveX / OCX: cómo tratarlos hoy — tabla de decisión para mantener, envolver o reemplazar
• La salida realista tras el fin de soporte de Windows 10 — la tabla de decisión entre ESU, LTSC y la renovación de equipos
• Cuando hereda un sistema sin código fuente ni documentación — Procedimiento práctico para operarlo y mantenerlo sin detenerlo
• El estado actual de la integración con el shell de Windows — el menú contextual, la asociación de archivos y los cambios de Windows 11

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de la investigación de funcionamiento y del diseño de prolongación de aplicaciones de negocio antiguas sin código fuente (selección de shims y modo de compatibilidad, creación y despliegue de un .sdb personalizado), de la verificación de compatibilidad de aplicaciones existentes con motivo de la migración a Windows 11, y de la planificación de un rehacer o una migración que corre en paralelo a la prolongación. Puede consultar ya desde la fase «funcionó con el modo de compatibilidad, ¿está bien dejarlo así?».

• Reutilización y migración de activos existentes
• Desarrollo de aplicaciones para Windows
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

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.

¿Está bien seguir usando una aplicación que empezó a funcionar al marcar el modo de compatibilidad?

Para la continuidad del negocio en lo inmediato, no hay problema en seguir usándola. La realidad del modo de compatibilidad es un hook de API en modo usuario llamado shim, un mecanismo previsto oficialmente como configuración del sistema operativo. El shim es, no obstante, un remedio provisional para hacer funcionar la aplicación sin corregirla, y si una actualización del SO cambia las premisas puede volver a dejar de funcionar. Registre en un inventario el hecho de que funciona con el modo de compatibilidad y opérelo junto con la decisión de rehacerla o de prolongar su vida de forma planificada.

¿Qué hace exactamente la casilla del modo de compatibilidad?

Al guardar la configuración en la pestaña de compatibilidad de las propiedades, se escribe en la clave HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers la ruta del EXE de destino y un valor como «WINXPSP3» o «HIGHDPIAWARE». La siguiente vez que se inicia ese EXE, el cargador de Windows lee el valor y aplica al proceso la capa de compatibilidad correspondiente (un conjunto de shims). Por ejemplo, en el modo de compatibilidad con Windows XP entra en juego, entre otras, la falsificación de versión, que devuelve un valor antiguo a la API que consulta la versión del SO. No se cambia el comportamiento del sistema operativo en sí: solo a ese proceso se le muestra «la apariencia de un Windows antiguo».

¿Se puede ejecutar con el modo de compatibilidad de Windows de 64 bits una aplicación antigua de la era de 16 bits?

No. Windows de 64 bits ejecuta aplicaciones de 32 bits mediante WOW64, pero no admite la ejecución de aplicaciones de 16 bits, y al intentar iniciarlas falla con ERROR_BAD_EXE_FORMAT. Es una limitación de arquitectura que el shim no puede eludir. Los paquetes antiguos en los que solo la parte de arranque del instalador es de 16 bits fallan por el mismo motivo. Si hace falta de verdad, hay que considerar medios distintos del modo de compatibilidad, como una máquina virtual con una versión de 32 bits de Windows.

¿Se puede ejecutar con privilegios de usuario estándar una aplicación que «no arranca si no se ejecuta como administrador»?

Vale la pena probar RunAsInvoker. Si en el símbolo del sistema se ejecuta set __COMPAT_LAYER=RunAsInvoker y después se inicia la aplicación, se suprime la solicitud de elevación provocada por requireAdministrator del manifiesto o por la detección de instalador, y arranca con los mismos privilegios (de usuario estándar) que el proceso que la invocó. Si es una aplicación que «solo pide privilegios de administrador sin usarlos realmente», esto basta para quitar la elevación de la operación cotidiana. Los privilegios no aumentan, así que cualquier operación que realmente los necesite fallará dentro de la aplicación. Adóptelo después de confirmar el funcionamiento.

¿Dónde se consigue Compatibility Administrator?

Está incluido en el Windows ADK (Windows Assessment and Deployment Kit). Descargue el ADK desde el sitio de Microsoft y, en la instalación, seleccione las funciones de la familia Application Compatibility Tools. Se instalan la versión de 32 bits y la de 64 bits; hay que usar la de 32 bits para corregir aplicaciones de 32 bits y la de 64 bits para las de 64 bits. La base de datos de compatibilidad personalizada (.sdb) que cree se aplica en cada PC con el comando sdbinst.

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.