El extraño amor de un desarrollador, o: cómo aprendí a dejar de preocuparme y amar Windows

1. La conclusión, primero

Cuando se desarrollan aplicaciones para Windows, hay mucho de qué preocuparse.

¿Arrancará en este PC? ¿Funcionará también en un entorno sin privilegios de administrador? ¿Se romperá por la diferencia entre 32 y 64 bits? Rutas en japonés, rutas largas, unidades de red, DLL antiguas, componentes COM, ActiveX, impresoras, comunicación serie, antivirus, Windows Update.

En cuanto uno empieza a pensarlo, las preocupaciones no se acaban.

Pero en algún momento empecé a verlo de otra manera.

Quizá esto no sea un defecto, sino la prueba de que Windows ha cargado sobre sus espaldas el trabajo real.

Windows no es una utopía impecable. Pero lleva consigo el software, los equipos, los flujos de trabajo y los hábitos humanos que llevan décadas funcionando sobre el terreno.

Ese caos es precisamente lo que hace interesante a Windows, y lo que, para un desarrollador, hace que merezca la pena enfrentarse a él.

2. El desarrollo de aplicaciones Windows trae consigo muchas preocupaciones

En el desarrollo de aplicaciones Windows, no basta con que “el código sea correcto”.

Funciona en el entorno local. Funciona en el PC del desarrollador. Funciona incluso en la VM de pruebas.

Aun así, no hay ninguna garantía de que funcione en el PC del cliente.

Por ejemplo, pasan cosas como estas:

• No se encuentra una DLL
• El runtime de Visual C++ no está instalado
• La versión de .NET Framework no coincide
• Falla la carga de una DLL de 32 bits desde un proceso de 64 bits
• El registro COM está dañado
• Se confunden las versiones de 32 y 64 bits de regsvr32.exe
• Código que asume un directorio actual fijo se rompe bajo el Programador de tareas
• Un intento de escritura bajo Program Files provoca un error de permisos
• Se confunde el uso de AppData\Roaming y AppData\Local
• Se bloquea con nombres de usuario o de carpeta en japonés
• No se pueden abrir archivos con rutas largas
• Funciona en una unidad de red asignada pero no mediante una ruta UNC
• La interfaz se rompe en entornos de alto DPI
• Los cálculos de coordenadas se desajustan con varios monitores
• El resultado de impresión cambia según el controlador de la impresora
• Dispositivos USB, cámaras, instrumentos de medición y comunicación serie no se reconocen según el entorno
• El antivirus bloquea parte del procesamiento
• El comportamiento cambia después de una actualización de Windows

Enumerado así, casi da vértigo.

Los problemas que en una aplicación web quedan confinados entre el navegador y el servidor, en una aplicación Windows se extienden por todo el PC. Sistema de archivos, registro, perfiles de usuario, impresoras, dispositivos, red, políticas de seguridad, instaladores, runtimes.

La aplicación no se limita a “ejecutarse sobre el sistema operativo”: se instala en medio de un entorno de trabajo real.

Por eso el desarrollo de aplicaciones Windows es difícil. Pero descartarlo simplemente con un “Windows es malo” me parece que no da en el blanco.

Lo que se apoya ahí encima es la complejidad del mundo real.

3. Windows es el sistema operativo del terreno

Windows no es un sistema operativo que exista solo para la tecnología más reciente.

Fábricas, hospitales, oficinas públicas, escuelas, laboratorios, emisoras, equipos de inspección, terminales de recepción, terminales de impresión de formularios, almacenes, tiendas, contabilidad, nóminas, gestión de inventario. En lugares así, todavía hoy funcionan innumerables PC con Windows.

Y allí no hay solo los últimos servicios web.

Hay macros de Excel. Hay Access. Hay aplicaciones VB antiguas. Hay aplicaciones de negocio sobre .NET Framework. Hay aplicaciones residentes escritas en C++. Hay componentes COM. Hay ActiveX. Hay conexiones ODBC. Hay controladores de impresora. Hay lectores de códigos de barras. Hay instrumentos de medición por comunicación serie. Hay SDK proporcionados por fabricantes.

Y, además, nada de esto existe de forma aislada.

Las personas los manejan, imprimen formularios, cambian dispositivos USB, dejan archivos CSV en carpetas compartidas; por la noche se ejecutan procesos por lotes, y a la mañana siguiente vuelve a comenzar el trabajo. Todo esto funciona dentro de esa cadena continua.

Windows no es simplemente una base sobre la que lanzar aplicaciones. Es una plataforma que acoge el trabajo diario del terreno, los activos existentes, los periféricos e incluso los hábitos de las personas.

Por eso a veces parece anticuado. A veces es complicado. A veces uno se pregunta por qué sigue existiendo tal o cual cosa.

Pero eso también significa que nunca se ha desechado lo viejo con descuido.

4. La retrocompatibilidad como forma de amor

Si el único objetivo fuera hacer que un sistema operativo se viera bonito, sería más fácil cortar de raíz los mecanismos antiguos.

Eliminar las API antiguas. Eliminar los runtimes antiguos. Eliminar las pantallas de configuración antiguas. Tratar las aplicaciones antiguas como algo que simplemente ya no funciona.

Si se hiciera eso, quizá el diseño quedaría más limpio. Quizá la documentación se acortaría. Quizá los desarrolladores se sentirían un poco más aliviados.

Pero detrás de todo eso habría aplicaciones de negocio que dejarían de funcionar. Habría equipos que se detendrían. Habría lugares de trabajo en apuros.

La retrocompatibilidad de Windows es, técnicamente, un verdadero engorro. Está WOW64, para que las aplicaciones de 32 bits funcionen en Windows de 64 bits. El registro y las DLL pueden verse de forma distinta desde código de 32 y de 64 bits. Existe esa estructura, confusa a primera vista, en la que C:\Windows\System32 es el lado de 64 bits y C:\Windows\SysWOW64 es el lado de 32 bits.

COM también es un engorro. No basta con colocar la DLL: a veces hace falta registrarla. ¿El registro es por usuario o por máquina? ¿Es COM de 32 o de 64 bits? ¿Hacen falta privilegios de administrador?

Con .NET Framework pasa lo mismo. Hoy existe la opción de usar un .NET moderno como .NET 8 o .NET 9. Pero en el terreno todavía hay aplicaciones basadas en .NET Framework 4.x. Eso no es simplemente antigüedad: significa que esa versión ha sostenido un trabajo real durante muchos años.

La retrocompatibilidad no es un concepto meramente bonito. Es, más bien, una responsabilidad pesada.

Mantener en marcha cosas antiguas significa cargar con deuda técnica. Pero, al mismo tiempo, es también una forma de honestidad: la de no detener el trabajo de quienes usan el sistema.

Creo que es ahí donde reside lo entrañable de Windows.

5. Windows es un sistema operativo hecho de estratos geológicos

En Windows, las tecnologías de cada época se han ido acumulando como estratos geológicos.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

Cada una tuvo su época de aparición, sus puntos fuertes y los lugares de trabajo donde se usó.

Si solo se mira lo nuevo, lo viejo puede parecer un estorbo. Pero en el desarrollo de aplicaciones Windows hay a menudo situaciones en las que no se pueden ignorar los estratos más antiguos.

Por ejemplo, incluso al construir una aplicación WPF, la impresión puede llevarnos a problemas de GDI y de controladores de impresora. Incluso escribiendo en C#, si el SDK de un proveedor es una DLL nativa, se termina lidiando con P/Invoke y problemas de bitness. Incluso al construir pantallas nuevas, a veces hay que conservar componentes COM existentes o la integración con Excel.

Windows no es un jardín perfectamente ordenado. Se parece más a una ciudad enorme, ampliada y reconstruida una y otra vez.

Hay grandes avenidas. Hay pasos subterráneos. Hay callejones antiguos. Hay rascacielos nuevos.

Es fácil perderse. Pero al fondo de esos callejones, todavía hoy funciona trabajo importante.

Lo que necesita un desarrollador no es el juicio de que “lo viejo es innecesario”. Es la capacidad de discernir qué estrato tecnológico sostiene qué trabajo.

6. Convertir la incomodidad en diseño

El título dice “dejar de preocuparme”.

Pero dejar de preocuparse no significa volverse descuidado. Tampoco significa fingir que no se ven los problemas.

Dejar de preocuparse es convertir la preocupación en diseño.

Por ejemplo, si genera inquietud saber si la aplicación arrancará, se convierte la comprobación de arranque en una prueba de humo (smoke test).

Start-Process .\MyApp.exe

Y no basta con comprobar el arranque: también se prueba sin archivo de configuración, sin carpeta de logs, con privilegios de usuario estándar, sin conexión de red, sin impresora configurada, con DPI alto, con rutas largas y con rutas en japonés.

Si las DLL preocupan, se verifican las dependencias. Si hace falta el runtime de Visual C++, se decide si se incluye en el instalador o se documenta explícitamente como requisito previo. Si se usan DLL nativas, no se deja en la ambigüedad la relación entre x86, x64 y AnyCPU.

Si COM preocupa, se documenta el procedimiento de registro en un manual y se reproduce desde cero en un PC de pruebas.

# Ejemplo: registro de una DLL COM de 64 bits
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# Ejemplo: registro de una DLL COM de 32 bits
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

Si los permisos preocupan, se evitan diseños que solo funcionan con privilegios de administrador. Los ajustes por usuario se colocan en AppData, y los ajustes de toda la máquina en ProgramData. Se evitan diseños que escriben logs bajo Program Files.

Si las rutas preocupan, se incluyen en las pruebas caracteres japoneses, espacios, nombres de carpetas largos y rutas UNC.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

Si el DPI preocupa, se comprueba al 100 %, 125 %, 150 % y 200 %. Con varios monitores, se comprueba que nada se rompa al pasar entre pantallas con distinta escala. Como WinForms, WPF y WinUI abordan el DPI de forma diferente entre sí, se comprueba por separado según la tecnología de interfaz.

Si la memoria y los handles preocupan, se usan Application Verifier, WinDbg, ProcDump, Process Explorer y herramientas similares. Si los cierres inesperados preocupan, se conservan registros de eventos, volcados y logs de aplicación.

Get-EventLog -LogName Application -Newest 20

O, en entornos más recientes, se consulta el registro de eventos así:

Get-WinEvent -LogName Application -MaxEvents 20

Si preocupan los fallos que no se reproducen en el terreno, se aumenta la granularidad de los logs. Con “se produjo un error” no basta. ¿Qué archivo se intentaba abrir? ¿Qué dispositivo se estaba buscando? ¿Con qué usuario se ejecutaba? ¿En qué ruta se intentaba escribir? ¿Qué DLL no se pudo cargar?

Convertir la preocupación en algo observable.

En el desarrollo de aplicaciones Windows, esto es sumamente importante.

7. “Funciona en el PC del cliente” es el objetivo final

Que funcione en el entorno de desarrollo es importante. Que las pruebas pasen en CI es importante. Que funcione en una VM limpia es importante.

Pero en el caso de una aplicación Windows, el obstáculo final siempre es: “¿funciona en el PC del cliente?”.

En ese PC ya hay algo instalado. Puede que haya un controlador de impresora antiguo. Puede que haya un software de seguridad propio de la empresa. Puede que haya unidades de red asignadas. Puede que el usuario no tenga privilegios de administrador. Puede que haya razones por las que Windows Update no se pueda aplicar de inmediato. Puede que sea un entorno sin acceso a internet.

Por eso también importa el método de distribución.

¿Basta con entregar un simple exe? ¿Debería ser un MSI? ¿ClickOnce? ¿MSIX? ¿Se puede distribuir mediante winget? ¿Pasará por un sistema de distribución interno? ¿Hace falta un instalador sin conexión? ¿Se requiere firma de código? ¿SmartScreen o el antivirus bloquearán la aplicación?

Solo incluyendo, más allá de la propia aplicación, la instalación, la actualización, la desinstalación, la recopilación de logs y los procedimientos de recuperación, se llega realmente cerca de un estado “utilizable en el terreno”.

En el desarrollo de aplicaciones Windows, el software no termina con la entrega. Tiene que arrancar en el entorno del cliente, hoy y mañana.

8. Por qué amo Windows a pesar de todo

Windows tiene sus lados incómodos. Eso es un hecho.

Las DLL. COM. El registro. El UAC. El DPI. Las impresoras. Los runtimes. 32 bits / 64 bits. Las unidades de red. Las rutas largas. Los entornos en japonés. Los programas de seguridad. Windows Update.

Si se enumeran los inconvenientes, no se acaban nunca.

Pero gran parte de esa incomodidad viene de que Windows lleva muchísimo tiempo cargando sobre sus espaldas un trabajo real.

No desecha los activos antiguos y a la vez incorpora nuevas tecnologías; tiene GUI y también CLI; acoge tanto las aplicaciones locales como la web, los periféricos como los terminales de negocio, los PC personales como los corporativos.

No es una filosofía única y hermosa.

Pero es sólida.

Y, como desarrollador, merece la pena enfrentarse a ella.

Construir software que funcione de forma fiable sobre Windows no es simplemente llamar a unas API. Es leer las restricciones del terreno, comprender los activos existentes, encontrar los puntos frágiles, probar, observar y corregir lo que haga falta.

Es un trabajo poco vistoso. Pero tiene valor.

9. Conclusión

En el desarrollo de aplicaciones Windows, las preocupaciones nunca se agotan.

Pero gran parte de esas preocupaciones son también el resultado de que Windows, como sistema operativo, ha absorbido durante muchísimo tiempo trabajo real, lugares reales, equipos reales y actuaciones humanas reales.

Por eso no considero a Windows simplemente un sistema operativo antiguo.

Es una plataforma enorme, compleja y un poco torpe, que ha seguido funcionando mientras se reconciliaba con la realidad.

Y construir software que funcione de forma fiable sobre ella todavía hoy tiene un gran valor.

Dejar de preocuparse.

Pero eso no significa bajar la guardia.

Convertir la preocupación en diseño, pruebas y observación.

Así fue como, poco a poco, llegué a amar Windows.

Enlaces de referencia

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

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.

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.