No puedo cambiar el modo Hi-DPI en Explorer

Si al abrir el Explorador de archivos todo se ve borroso y no encuentras la pestaña de compatibilidad en el ejecutable del sistema, no estás solo. El escalado Hi‑DPI (PPP) en Windows mezcla piezas modernas y heredadas, y eso provoca resultados raros: textos difuminados, controles desproporcionados y comportamientos inconsistentes entre apps.

La situación empeora cuando cambias de monitor o modificas el factor de escala. Las aplicaciones UWP suelen salir airosas, pero las Win32 requieren mimo. Aquí unimos la teoría oficial de Microsoft con casos reales (Explorer, Office, SSMS, Chrome, Adobe) y código para que entiendas qué pasa y cómo actuar.

¿Por qué no hay pestaña de compatibilidad para explorer.exe?

Es normal que en C:/Windows/explorer.exe no aparezca la pestaña de compatibilidad. Explorer es parte del shell de Windows y está protegido, por lo que sus ajustes no se gestionan como los de una app cualquiera. De ahí que no puedas forzar, por ejemplo, una anulación de PPP desde sus propiedades.

Si el Explorador y el Panel de control se ven borrosos, el origen no es un único interruptor oculto. El problema reside en cómo Windows escala la interfaz heredada cuando hay cambios de PPP o se usa un monitor de alta densidad. Controlar esto pasa por comprender los modos de reconocimiento de PPP y las opciones del sistema para corregir apps borrosas.

PPP y factor de escala: lo básico que hay que entender

A medida que sube la densidad de píxeles, los paneles modernos han pasado de 96 PPP a cifras cercanas a 300 PPP o más. Para que todo sea legible, Windows aplica un factor de escala y las apps deben reaccionar a él.

Muchas bases de código Win32 partían de una suposición que ya no se cumple: el PPP era fijo durante toda la vida del proceso. Hoy, con portátiles que se acoplan y mueven entre monitores 1080p y 4K, el PPP cambia sobre la marcha, a veces varias veces en una misma sesión.

Escenarios típicos donde cambia el PPP o el factor de escala: mover ventanas entre monitores con escalas distintas, acoplar/desacoplar el portátil, iniciar Escritorio remoto desde/ hacia equipos con PPP diferente o tocar el control de escala en Configuración mientras las apps están abiertas.

Modos de reconocimiento de PPP (DPI awareness) en Windows

Las apps de escritorio deben decirle a Windows si saben manejar el escalado. Si no lo hacen, el sistema asume 96 PPP y estira el mapa de bits, que se ve borroso. Estos son los modos clave:

PPP no consciente (Unaware): la app renderiza a 96 PPP (100%). En pantallas con escala mayor, Windows hace un zoom de mapa de bits al tamaño físico esperado y la interfaz queda borrosa.

Consciente del sistema (System aware): la app toma el PPP del monitor principal al iniciar sesión y dimensiona su UI con ese dato. Si la mueves a otro monitor con otro PPP, Windows la estira y se emborrona. Solo se ve nítida en el PPP para el que se inicializó.

Consciente por monitor (Per‑monitor, V1): introducido en Windows 8.1. Las ventanas de nivel superior reciben notificación de cambio de PPP, Windows no escala el mapa de bits y la app ve píxeles físicos de cada pantalla. Es funcional, pero limitado.

Consciente por monitor V2 (Per‑monitor v2): recomendado desde Windows 10 1703. Aporta mejoras clave: notificaciones a HWND de nivel superior y secundarios, Windows escala automáticamente el área no cliente (título, barras de desplazamiento), diálogos de CreateDialog y recursos dibujados por temas (comctl32 V6) al PPP adecuado. La app ve píxeles sin procesar y Windows nunca la reescala.

UWP vs Win32: por qué unas cosas se ven bien y otras no

Si construyes una app desde cero y optas por UWP, el marco redibuja automáticamente según el PPP del monitor. No hay nada más que hacer. En cambio, las tecnologías previas (Win32 puro, Windows Forms, WPF, GDI, MFC…) no escalan por sí solas; hay que programarlo o parecerán borrosas, demasiado pequeñas o desproporcionadas.

Esto se nota en detalles cotidianos de la UI clásica: al poner el sistema al 200% la barra de desplazamiento puede engordar y algunos botones encoger, con curvas y bordes que resultan raros. Ese tipo de deficiencia afecta al Explorador y a otras partes de la shell Win32, no a las UWP.

Qué marcos escalan mejor (y cuáles no)

Según Microsoft, el soporte por monitor varía por tecnología. UWP tiene soporte completo y el propio marco controla el escalado. Win32 con controles comunes V6 (comctl32.dll) en 1703 incluye notificaciones a todos los HWND, recursos con temas que se redibujan al PPP correcto y diálogos que se escalan solos.

Windows Forms dispone de un escalado automático por monitor limitado para ciertos controles, mientras que WPF nativo escala bien si se queda en WPF, pero la convivencia con otros marcos hospedados no escala automáticamente. GDI, GDI+ y MFC no aportan soporte por sí mismos: la lógica debe implementarla la aplicación.

Actualizar tu app de escritorio a Per‑Monitor (V2)

El objetivo mínimo es que, ante cada cambio de PPP, se redimensionen las partes importantes de la UI. Si hoy tu app es System aware, cuando cambie la escala Windows la estirará y se verá borrosa. Para evitarlo, conviértela en Per‑Monitor V2 y redibuja al vuelo.

Pautas prácticas para migrar: pasos clave para evitar el estirado

• Declara Per‑Monitor V2 en el manifiesto o usa la API adecuada, según tu marco.
• Extrae la lógica de layout del arranque y conviértela en rutinas reutilizables que invoques también en WM_DPICHANGED.
• Reevalúa datos sensibles al PPP (fuentes, tamaños, métricas) en cada cambio de PPP; no los caches de manera rígida.
• Recarga o rerasteriza bitmaps a la nueva escala o, si no es viable, acepta el escalado de mapa de bits para esos recursos.
• Sustituye APIs no conscientes por variantes para PPP: por ejemplo, GetSystemMetrics → GetSystemMetricsForDpi.
• Prueba en entornos multinivel de PPP (varios monitores, RDP, cambios en caliente de escala).
• Para ventanas que no puedas actualizar aún, usa escalado mixto con reconocimiento por subproceso.

Ejemplo simplificado de Win32. Caso ingenuo (asume 96 PPP) que crea un botón y queda mal en PPP altos:

case WM_CREATE: { // Add a button
 HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,
 50, 50, 100, 50, hWnd, (HMENU)NULL, NULL, NULL);
}

Versión adaptada: escala la posición y el tamaño con GetDpiForWindow y responde a WM_DPICHANGED:

#define INITIALX_96DPI 50
#define INITIALY_96DPI 50
#define INITIALWIDTH_96DPI 100
#define INITIALHEIGHT_96DPI 50

void UpdateButtonLayoutForDpi(HWND hWnd) {
 int iDpi = GetDpiForWindow(hWnd);
 int dpiScaledX = MulDiv(INITIALX_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
 int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
 int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
 int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI);
 SetWindowPos(hWnd, hWnd, dpiScaledX, dpiScaledY, dpiScaledWidth, dpiScaledHeight,
 SWP_NOZORDER | SWP_NOACTIVATE);
}
...
case WM_CREATE: {
 HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,
 0, 0, 0, 0, hWnd, (HMENU)NULL, NULL, NULL);
 if (hWndChild != NULL) { UpdateButtonLayoutForDpi(hWndChild); }
} break;
case WM_DPICHANGED: {
 HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL);
 if (hWndButton != NULL) { UpdateButtonLayoutForDpi(hWndButton); }
} break;

Escalado mixto y reconocimiento por subproceso

Actualizar toda una UI grande de una vez puede ser poco realista. Aquí entra el modo mixto (DPI por subproceso): puedes dejar algunas ventanas de nivel superior en su modo original, mientras modernizas el resto.

A partir de Windows 10 1607, el reconocimiento de PPP puede establecerse por ventana de nivel superior. Las ventanas hijas deben heredar el modo de su padre. Usa SetThreadDpiAwarenessContext antes de crear la ventana para asociarla al modo deseado y restaura después.

Patrón C++ para bloquear contexto DPI de subproceso durante la creación:

class DpiAwarenessContextBlock {
public:
 DpiAwarenessContextBlock(DPI_AWARENESS_CONTEXT dpiContext) noexcept {
  m_contextReversalType = SetThreadDpiAwarenessContext(dpiContext);
 }
 ~DpiAwarenessContextBlock() {
  SetThreadDpiAwarenessContext(m_contextReversalType);
 }
private:
 DPI_AWARENESS_CONTEXT m_contextReversalType;
};

Patrón administrado (C#) equivalente para cambiar y restaurar el contexto en bloques: útil en soluciones con varias ventanas.

class DPIContextBlock : IDisposable {
 private DPI_AWARENESS_CONTEXT resetContext;
 public DPIContextBlock(DPI_AWARENESS_CONTEXT contextSwitchTo) {
  resetContext = SetThreadDpiAwarenessContext(contextSwitchTo);
 }
 public void Dispose() { SetThreadDpiAwarenessContext(resetContext); }
}

Pruebas que no debes saltarte y errores típicos

Para validar que tu app responde bien, muévela entre pantallas con diferentes escalas, iníciala directamente en una u otra, cambia el factor de escala con la app ejecutándose y cambia la pantalla principal, cierra sesión y prueba otra vez.

Errores habituales:

• Ignorar el rectángulo sugerido en WM_DPICHANGED: úsalo para redimensionar y evitar bucles de cambio de PPP y saltos del cursor.
• Virtualización poco documentada: si llamas a APIs desde un subproceso no consciente, Windows puede virtualizar valores. Cambia el contexto con SetThreadDpiAwarenessContext y recuerda restaurarlo.
• APIs sin contexto de PPP: para iconos, tamaños, métricas… usa variantes como LoadImage en lugar de LoadIcon o GetSystemMetricsForDpi en lugar de GetSystemMetrics.
• Reseteo forzado del reconocimiento del proceso: no puede haber padre e hijo con modos DPI diferentes en el mismo árbol HWND. Operaciones como CreateWindow/SetParent con modos incompatibles pueden forzar un reseteo o fallar.

Office: qué hace y cómo integrarte sin desenfoques

Office 2016 y posteriores se actualizan al cambiar la escala, pero las soluciones de extensibilidad deben alinearse para dibujar bien. Si el ajuste de PPP te afecta, verás ventanas mal posicionadas, controles fuera de sitio y fuentes o imágenes con tamaños incorrectos.

Modos relevantes en Office:

• Unaware: siempre 96 PPP; todo se estira.
• System aware: se toma el PPP del monitor principal al inicio; en cambios posteriores, Windows estira.
• Per‑monitor: top‑level recibe notificaciones y se redibuja. En v2 también las reciben las hijas, pero Office no usa PMv2.

Contexto de subprocesos: el principal de Office va en Per‑Monitor. Si creas hilos extra, Office los fuerza a Per‑Monitor. Si esperas otro contexto, cámbialo con SetThreadDpiAwarenessContext. En callbacks de Office, el contexto entra como System aware; ajústalo al de tu ventana.

Top‑level vs hijas: tus ventanas de nivel superior pueden ir en el modo que elijas y recibir notificaciones; las secundarias deben respetar el reconocimiento de la principal. En Windows 1709, las hijas iban Per‑Monitor; desde 1803, Office puede usar modo mixto para mejorar compatibilidad (aunque puede verse borroso por el estirado).

Configuración útil para usuarios: en Office, activar el modo de compatibilidad de pantalla fuerza System aware (todo estirado, posible borrosidad, pero consistente). En Windows 10 1803+, la opción del sistema para Corregir aplicaciones borrosas también ayuda si tu solución no se representa bien.

Tipos de extensibilidad y matices:

• VSTO: las ventanas hijas deben igualar el reconocimiento de la principal (usa GetWindowDpiAwarenessContext). Las top‑level pueden ir en el modo deseado. Puedes implementar una Form que reaccione a WM_DPICHANGED y escale controles y fuentes en OnDpiChangedEvent.
• Complementos COM: para ventanas top‑level, crea un bloque de contexto DPI antes de crear la ventana y maneja WM_DPICHANGED.
• ActiveX con ventana: reaccionan a WM_SIZE; pueden consultar GetDpiForWindow y recalcular posiciones y fuentes.
• ActiveX sin ventana: en modo diseño, el contenedor puede devolver 0 en hDC y no hay PPP fiable; en runtime, usa el HWND que te devuelva Office para consultar el PPP y escalar.
• OLE: hay restricciones en escenarios mixtos; versiones recientes de Office permiten activación local con condiciones según el contexto DPI y la opción de apariencia/compatibilidad elegida por el usuario.
• Web add‑ins: se ejecutan en un control de navegador; aplican las mismas técnicas responsive de la web.

SSMS en pantallas 4K: manifiesto externo y alternativas

En equipos UHD es habitual que SQL Server Management Studio se vea borroso en versiones antiguas. Una vía clásica fue habilitar manifiestos externos con la clave de registro PreferExternalManifest y colocar un archivo ssms.exe.manifest en la carpeta de instalación para forzar reconocimiento de PPP.

Guía abreviada de ese enfoque: crea la clave en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide con nombre PreferExternalManifest (DWORD=1), guarda el manifiesto en la ruta del ssms.exe con codificación UTF‑8 y reinicia. En SSMS 16.3 se introdujo soporte beta Hi‑DPI y en SSMS 17 se mejoraron iconos, pero los resultados variaban según versión y configuración.

Otra herramienta útil es Process Explorer (Sysinternals) para añadir la columna Reconocimiento de DPI y comprobar si un proceso es Unaware, System aware o Per‑Monitor. Así puedes verificar si tu ajuste surtió efecto.

Alternativa rápida sin manifiestos: en las Propiedades del ejecutable, pestaña Compatibilidad, marca la opción «Sobrescribir el comportamiento de escalamiento del HIGH DPI» y pon «El escalado realizado por» en «Aplicación». Esto fuerza el modo Per‑Monitor y evita el estirado de Windows en cambios de PPP. En muchos casos corrige la borrosidad de SSMS sin tocar el registro.

Referencias de la columna de Process Explorer: Unaware (todo a 96 PPP, estirado por sistema), System aware (usa PPP inicial, luego se estira en cambios) y Per‑Monitor (se redibuja al cambiar). Cada una explica por qué una app se ve nítida o borrosa según el escenario.

Chrome y Adobe en Hi‑DPI: lo que te puedes encontrar

El renderizado de tipografías de Chrome en Windows dio guerra durante años. En versiones para desarrolladores se introdujeron correcciones (como en su día Canary con DirectWrite) que mejoraron mucho la nitidez en pantallas Hi‑DPI, aunque a costa de posibles fallos puntuales o mayor consumo de CPU en builds tempranas.

En la suite de Adobe de generaciones anteriores, Photoshop podía mostrar la interfaz minúscula. Adobe añadió una opción de UI al 200% que solventa parte del problema en versiones recientes; con las antiguas, tocaría convivir con menús diminutos o usar atajos.

En InDesign e Illustrator ocurría lo contrario: tamaño correcto, pero borroso. La solución pasaba por desactivar el escalado automático en Compatibilidad (propiedades del acceso directo) con «Deshabilitar el ajuste de escala de pantalla si se usa la configuración elevada de ppp», asumiendo una UI más pequeña pero nítida.

Otra rareza con Photoshop: herramientas desfasadas o triplicadas. Ajustar el tamaño de los elementos a un valor personalizado (por ejemplo, 149% o 151% en lugar de 150%) en «Aumentar o reducir el tamaño del texto y de otros elementos» puede devolver la puntería al sitio.

Si buscas alternativas, GIMP ofrece una opción libre y potente que se comporta dignamente en entornos de alta densidad con la configuración adecuada.

Volviendo al Explorador: qué sí puedes hacer desde el sistema

Aunque no puedas tocar compatibilidad en explorer.exe, Windows 10 y posteriores traen dos salvavidas para la experiencia general:

• Configuración > Sistema > Pantalla: ajusta el factor de escala recomendado y evita valores raros salvo que atiendan a casos concretos. Para equipos con cambios frecuentes de monitor, es mejor cerrar y abrir sesión tras grandes cambios.
• Configuración > Sistema > Pantalla > Configuración de escala avanzada: activa «Permitir que Windows intente arreglar las apps para que no estén borrosas». Esto ayuda con apps heredadas cuando cambias de pantalla o de escala.

Además, por app (excepto Explorer) puedes abrir sus propiedades y usar «Sobrescribir el comportamiento de escalamiento del HIGH DPI» para elegir «Aplicación», «Sistema» o «Sistema (mejorado)» según convenga. Es un recurso eficaz cuando una app concreta se resiste y no puedes cambiar su código.

Con todo lo anterior en mente, la foto grande es clara: las UWP se adaptan solas, las Win32 bien cuidadas también, y el resto necesita ajustes. Explorer y otras piezas de la shell arrastran decisiones históricas, pero el ecosistema ofrece atajos y APIs para salir del paso.