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

Este es un ensayo sobre cómo abordar la sensación de «miedo a que algo se rompa según el entorno» que acompaña al desarrollo de aplicaciones para Windows. No es un artículo que explique el uso de una API.

Hablaré de por qué Windows carga con preocupaciones como las DLL, COM, 32 y 64 bits, los permisos, el DPI o la distribución, y de cómo convertir esa preocupación en diseño, pruebas y observación. Si lo que busca es algo que se pueda aplicar directamente, con solo consultar la tabla de «preocupación / medida de diseño / método de verificación» del capítulo 6 le bastará.

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.

¿No será esto, más que un defecto, la prueba de que Windows ha cargado sobre sus espaldas el trabajo real?

Windows no es un paraíso ideal y pulcro. Pero acoge software, equipos, flujos de trabajo y hábitos humanos que llevan funcionando en el terreno durante décadas.

Creo que precisamente ese caos es lo que hace interesante a Windows, y lo que merece la pena afrontar como desarrollador.

2. El desarrollo de aplicaciones para Windows conlleva muchas preocupaciones

En el desarrollo de aplicaciones para 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 verificación.

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

Por ejemplo, pueden ocurrir cosas como estas:

• No se encuentra la DLL
• No está instalado el runtime de Visual C++
• La versión de .NET Framework no coincide
• Falla al intentar cargar una DLL de 32 bits desde un proceso de 64 bits
• El registro de COM está dañado
• Se confunde la versión de 32 bits de regsvr32.exe con la de 64 bits
• Un código que asume el directorio actual se rompe al ejecutarse desde el Programador de tareas
• Se produce un error de permisos al intentar escribir dentro de Program Files
• Se confunde el uso de AppData\Roaming con el de AppData\Local
• Falla con nombres de usuario o de carpeta en japonés
• No se puede abrir un archivo por tener una ruta demasiado larga
• Funciona en una unidad de red pero no con una ruta UNC
• La pantalla se descompone en un entorno de alto DPI
• El cálculo de coordenadas se desajusta en un entorno multimonitor
• El resultado de impresión cambia según el controlador de la impresora
• Dispositivos USB, cámaras, instrumentos de medición o comunicación serie no se reconocen según el entorno
• El antivirus bloquea parte del procesamiento
• El comportamiento cambia tras una actualización de Windows

Al enumerarlo así, uno se marea un poco.

En una aplicación web, los problemas quedan confinados entre el navegador y el servidor; en una aplicación Windows, se extienden a todo el PC. Sistema de archivos, registro, perfil de usuario, impresoras, dispositivos, red, políticas de seguridad, instaladores, runtimes.

La aplicación no se limita a ejecutarse sobre el sistema operativo: queda instalada dentro de todo el entorno de trabajo.

Por eso el desarrollo de aplicaciones para Windows es difícil. Sin embargo, creo que descartarlo sin más diciendo «Windows es malo» no es del todo acertado.

Lo que hay detrás de todo esto es la complejidad del mundo real.

3. Windows es el «sistema operativo del terreno»

Windows no es un sistema operativo pensado únicamente para la tecnología más reciente.

Fábricas, hospitales, oficinas públicas, escuelas, laboratorios de investigación, emisoras de radiodifusión, equipos de inspección, terminales de recepción, terminales de formularios, almacenes, tiendas, contabilidad, nóminas, gestión de inventario. En todos esos lugares siguen funcionando hoy muchos PC con Windows.

Allí no solo hay servicios web de última generación.

Hay macros de Excel. Hay Access. Hay aplicaciones antiguas hechas en VB. Hay aplicaciones de negocio en .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 con comunicación serie. Hay SDK proporcionados por proveedores.

Y, además, no existen de forma aislada.

Una persona los opera, se imprimen formularios, se conectan y desconectan dispositivos USB, se depositan archivos CSV en una carpeta compartida, se ejecuta un proceso por lotes nocturno y a la mañana siguiente empieza de nuevo la actividad. Todo esto funciona dentro de ese flujo continuo.

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

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

Pero eso también significa que no se ha desechado lo antiguo sin cuidado.

4. La retrocompatibilidad, una forma de amor

Si lo único que importara fuera que el sistema operativo luciera bonito, sería más fácil desechar los mecanismos antiguos.

Eliminar las API antiguas. Eliminar los runtimes antiguos. Eliminar las pantallas de configuración antiguas. Tratar las aplicaciones antiguas como si no fueran a funcionar.

Con eso, puede que el diseño quedara más limpio. Puede que la documentación fuera más corta. Puede que el ánimo del desarrollador se sintiera un poco más ligero.

Pero, detrás de eso, hay aplicaciones de negocio que dejarían de funcionar. Hay equipos que se detendrían. Hay lugares de trabajo que se verían en problemas.

La retrocompatibilidad de Windows es, técnicamente, un engorro. Está WOW64 (Windows 32-bit On Windows 64-bit), que permite ejecutar aplicaciones de 32 bits sobre un Windows de 64 bits. El registro y las DLL pueden verse de forma distinta según se trate de 32 o de 64 bits. También existe una estructura que confunde a primera vista: C:\Windows\System32 corresponde al lado de 64 bits, mientras que C:\Windows\SysWOW64 corresponde al de 32 bits.

COM (Component Object Model, el mecanismo de Windows mediante el cual las aplicaciones intercambian componentes entre sí) también resulta engorroso. No basta con colocar la DLL: a veces hace falta registrarla. ¿El registro es por usuario o por equipo? ¿Es COM de 32 bits o de 64 bits? ¿Hacen falta privilegios de administrador?

Con .NET Framework ocurre lo mismo. Hoy existe la opción de usar un .NET más nuevo, como .NET 8 o .NET 9. Pero en el terreno todavía hay aplicaciones de .NET Framework 4.x. Eso no significa simplemente que sean antiguas, sino que esa versión ha sostenido el negocio durante muchos años.

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

Seguir haciendo funcionar lo antiguo también significa cargar con deuda técnica. Pero, al mismo tiempo, es una forma de honestidad: no detener el trabajo de quien usa el sistema.

Creo que ahí es donde reside lo que hace a Windows digno de aprecio.

5. Windows es un sistema operativo hecho de estratos

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, su campo de especialidad y los entornos de trabajo donde se ha usado.

Si solo se mira lo nuevo, puede que lo antiguo parezca un estorbo. Pero, en el desarrollo de aplicaciones para Windows, hay muchas ocasiones en las que no se puede ignorar la capa antigua.

Por ejemplo, aunque se esté creando una aplicación WPF, en la impresión pueden surgir problemas con GDI (Graphics Device Interface, el mecanismo de dibujo e impresión que Windows tiene desde hace mucho tiempo) o con el controlador de la impresora. Aunque se escriba en C#, si el SDK del proveedor es una DLL nativa, aparecen problemas de P/Invoke (Platform Invoke, el mecanismo que permite llamar desde C# a funciones de una DLL nativa) y de número de bits. Aunque se esté creando una pantalla nueva, a veces hace falta conservar componentes COM existentes o la integración con Excel.

Windows no es un jardín completamente ordenado. Se parece más bien a una ciudad enorme que ha sufrido ampliaciones y reformas una y otra vez.

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

Es fácil perderse. Pero, en el fondo de esos callejones, hoy todavía sigue funcionando trabajo importante.

Este «historial de ampliaciones y reformas» se recorre de forma concreta, no como un ensayo sino como una cronología, en Por qué Windows llegó a tener su forma actual: la evolución de Windows vista por un desarrollador, donde se organiza el cambio desde Windows 95 hasta Windows 11 tal como lo ve un desarrollador. Si quiere saber cuándo se fue acumulando cada capa, le recomendamos leer ese artículo.

Lo que necesita un desarrollador no es decidir que «algo es innecesario por ser antiguo». Es discernir qué capa de tecnología sostiene qué parte del negocio.

6. Convertir la incomodidad en diseño

En el título escribí «dejar de preocuparme».

Sin embargo, dejar de preocuparse no significa volverse descuidado. Tampoco significa hacer como si no se vieran los problemas.

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

Por ejemplo, si le preocupa si la aplicación arrancará, convierta la comprobación del arranque en una prueba de humo (smoke test).

Start-Process .\MyApp.exe

No se limite a comprobar que arranca: pruébelo también sin archivo de configuración, sin carpeta de registros, con privilegios de usuario estándar, sin conexión de red, sin impresora configurada, con alto DPI, con rutas largas y con rutas en japonés.

Si le preocupan las DLL, verifique las dependencias. Si hace falta el runtime de Visual C++, decida si lo incluye en el instalador o si lo indica como requisito previo. Si usa DLL nativas, no deje ambigua la relación entre x86, x64 y AnyCPU.

Si le preocupa COM, convierta el procedimiento de registro en un documento de instrucciones y repita todo el proceso desde cero en un PC de verificación.

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

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

Si le preocupan los permisos, evite diseños que solo funcionen con privilegios de administrador. Coloque la configuración del usuario en AppData y la configuración general en ProgramData. Evite diseños que escriban registros dentro de Program Files.

Si le preocupan las rutas, incluya en las pruebas el japonés, los espacios, los nombres de carpeta largos y las rutas UNC.

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

Si le preocupa el DPI, verifique al 100 %, 125 %, 150 % y 200 %. Compruebe también, en un entorno multimonitor, que nada se rompe al pasar entre pantallas con distinta escala. En WinForms, WPF y WinUI el enfoque del soporte de DPI es diferente en cada caso, así que verifíquelo por cada tecnología de pantalla.

Si le preocupan la memoria o los identificadores (handles), use herramientas como Application Verifier, WinDbg, ProcDump o Process Explorer. Si le preocupan los bloqueos, conserve el registro de eventos, los volcados de memoria (dumps) y el registro de la aplicación.

Get-EventLog -LogName Application -Newest 20

O bien, en un entorno más reciente, consulte el registro de eventos de esta otra forma:

Get-WinEvent -LogName Application -MaxEvents 20

Si le preocupan los fallos que no se reproducen en el terreno, aumente el nivel de detalle de los registros. Con «se ha producido un error» no basta. Qué archivo se intentaba abrir. Qué dispositivo se buscaba. Con qué usuario se ejecutó. En qué ruta se intentaba escribir. Qué DLL no se pudo cargar.

Convertir la preocupación en algo observable.

Esto es muy importante en el desarrollo de aplicaciones para Windows.

Si resumimos todo esto en una sola tabla, queda así:

La columna izquierda de esta tabla es, directamente, la lista de preocupaciones. Con las dos columnas de la derecha, la preocupación se convierte en trabajo concreto.

7. El objetivo final es que funcione en el PC del cliente

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

Pero, en el caso de una aplicación Windows, lo que se interpone al final es si funciona en el PC del cliente.

En ese PC ya hay algo instalado. Puede que tenga un controlador de impresora antiguo. Puede que tenga instalado un software de seguridad propio de la empresa. Puede que tenga asignada una unidad de red. Puede que el usuario no tenga privilegios de administrador. Puede que haya circunstancias que impidan aplicar de inmediato las actualizaciones de Windows. Puede que sea un entorno sin salida a internet.

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

¿Basta con entregar un simple exe? ¿Conviene un MSI? ¿ClickOnce? ¿MSIX? ¿Se puede distribuir con winget? ¿Se incorpora al sistema de distribución interno de la empresa? ¿Hace falta un instalador sin conexión? ¿Es necesaria la firma de código? ¿Se detiene por culpa de SmartScreen o del antivirus?

Solo cuando se tiene en cuenta no únicamente la aplicación en sí, sino también la instalación, la actualización, la desinstalación, la recogida de registros y el procedimiento de recuperación, uno se acerca por fin a algo «utilizable en el terreno».

En el desarrollo de aplicaciones para Windows, el trabajo no termina al entregar el software. Es necesario que siga arrancando hoy y mañana en el entorno del cliente.

8. Aun así, por qué amo Windows

Windows tiene aspectos incómodos. Esto es un hecho.

DLL. COM. Registro. UAC. DPI. Impresoras. Runtimes. 32 bits / 64 bits. Unidades de red. Rutas largas. Entorno en japonés. Software de seguridad. Windows Update.

Si uno se pone a enumerar lo incómodo, no hay fin.

Por si acaso, una aclaración: UAC son las siglas de User Account Control (Control de cuentas de usuario), y DPI las de Dots Per Inch (la configuración de escala de la pantalla). Ambas son, también, otra forma de decir que «la aplicación no puede completarse por sí sola».

Sin embargo, buena parte de esa incomodidad proviene de que Windows lleva mucho tiempo cargando sobre sus espaldas el trabajo real.

No desecha los activos antiguos, incorpora también la tecnología nueva, tiene tanto GUI como CLI, acoge tanto aplicaciones locales como web, tanto periféricos como terminales de negocio, tanto PC personales como PC de empresa.

Eso no es una filosofía única y hermosa.

Pero es fuerte.

Y, como desarrollador, merece la pena afrontar el reto.

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

Eso es un trabajo discreto. Pero tiene valor.

9. Resumen

En el desarrollo de aplicaciones para Windows, las preocupaciones no se acaban nunca.

Pero buena parte de esas preocupaciones son también el resultado de que Windows, como sistema operativo, ha ido acogiendo durante mucho tiempo el trabajo real, el terreno, los equipos y la forma de operar de las personas.

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

Es una plataforma enorme, compleja y algo torpe, que ha seguido funcionando mientras se las arreglaba con la realidad.

Y crear software que funcione de forma fiable sobre esa plataforma sigue teniendo, hoy en día, un gran valor.

Dejar de preocuparse.

Pero no bajar la guardia.

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

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

Referencias

• 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.