Durante las últimas semanas, ha habido varios anuncios de Microsoft que invierten parcialmente las direcciones pasadas en términos de desarrollo de Windows. En resumen, Microsoft está minimizando (si no desaprobando por completo) el modelo de la Plataforma universal de Windows.

A continuación, se muestran algunos enlaces relevantes:

• Microsoft publica los detalles de migración de UWP a Win32, pero probablemente no sea lo que piensa  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
• UWP ya no está de moda, ya que Microsoft publica una guía para migrar aplicaciones a Windows App SDK  https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to -windows-app-sdk /
• Microsoft oficialmente desaprueba UWP  https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp

UWP ha sido el enfoque de desarrollo de aplicaciones de Microsoft desde el lanzamiento de Windows 8, y estaba reemplazando el enfoque en la arquitectura .NET como plataforma de desarrollo de Windows.

Ahora bien, esta es una evolución muy interesante desde la perspectiva de los desarrolladores (y proveedores de herramientas de desarrollo como Embarcadero) que se han mantenido enfocados en el modelo clásico de desarrollo nativo de Windows, ya que volvemos a ser ciudadanos de primera clase después de mucho tiempo.

De nativo a .NET y UWP

Durante muchos años, el modelo de desarrollo nativo basado en la participación de la API de Windows clásica y el aprovechamiento de las tres bibliotecas Kernel / User / GDI principales y todas sus extensiones se ha considerado un enfoque anticuado y obsoleto que pronto sería abandonado. Este es el modelo clásico utilizado por Delphi y C ++ Builder (con la biblioteca VCL), pero también por Visual C ++ (con la biblioteca MFC).

Primero se animó a los desarrolladores de Windows a pasar a .NET (con la idea de que las futuras API de la plataforma requerirían .NET y las aplicaciones clásicas en algún momento dejarían de ejecutarse en Windows). Con el tiempo, quedó claro que este no iba a ser el caso.

A medida que el enfoque centrado en .NET disminuyó, Microsoft comenzó a impulsar la siguiente idea: la Plataforma universal de Windows. Esto fue impulsado principalmente por dos ideas: una, la capacidad de ejecutar la misma aplicación en una PC de escritorio, pero también en un teléfono con Windows, una consola de juegos y una tecnología de visera; dos, una plataforma más segura con acceso limitado al sistema operativo subyacente. A nivel de API, la compatibilidad con UWP implicaba el uso de las API de la plataforma WinRT, que eran diferentes e incompatibles con las API clásicas.

UWP tardó en ponerse al día. Para Delphi y RAD Studio no había una opción, pero también la migración desde Visual C ++ y .NET y C # implicaría el uso de diferentes bibliotecas de tiempo de ejecución y diferentes controles de interfaz de usuario, lo que representa una gran reescritura de una aplicación existente. Cuando se envió Windows 8 por primera vez (que aún permitía aplicaciones API clásicas), había muy pocas aplicaciones para UWP disponibles, incluso de Microsoft. Sin embargo, algunas de las nuevas funciones de la plataforma solo estaban disponibles a través de las API de WinRT, por lo que los desarrolladores y las herramientas (incluido RAD Studio) presentaron opciones para llamar a las API de WinRT desde una aplicación clásica. El soporte de notificaciones de Windows de RAD Studio, por ejemplo, se implementa con este enfoque.

Si bien Microsoft siguió presionando por UWP, lo que indicaba que las aplicaciones clásicas iban a quedar obsoletas, los desarrolladores realmente no escucharon. El siguiente paso fue promover el llamado “Desktop Bridge”, es decir, la capacidad de las aplicaciones nativas para aprovechar más API de WinRT y ser “empaquetadas” en un contenedor ligero para mayor seguridad. Esta última característica se logró empaquetando una aplicación como APPX y posterior MSIX. Una vez más, RAD Studio ha ofrecido durante mucho tiempo este soporte directamente en el IDE.

Microsoft describió inicialmente el puente como una forma de ayudar a migrar aplicaciones a UWP, que seguía siendo el objetivo de la empresa. Los desarrolladores pueden mover su solicitud de uno en uno. Rápidamente se hizo evidente que los desarrolladores no tenían un interés real en convertir sus grandes bases de código, pero estaban interesados ​​en utilizar todas las funciones de la plataforma. APPX y MSIX también abrieron las puertas de Microsoft Store para aplicaciones tradicionales.

Avance rápido hasta el último año más o menos. Microsoft anunció Project Reunion (ahora rebautizado como Windows App SDK) con el objetivo de ofrecer interoperabilidad total para que las aplicaciones UWP llamen a API nativas y aplicaciones nativas para llamar a cualquier API de UWP, pero terminó dando al soporte de aplicaciones nativas una prioridad mucho mayor, con UWP ahora dejado atrás, que es lo que indican los anuncios anteriores.

Volver a Native

Entonces, en otras palabras, después de más de 15 años en los que Microsoft ha estado considerando las aplicaciones nativas de Windows como de segunda clase, que pronto serán ciudadanos difuntos, ahora tenemos un cambio total de posición. Las aplicaciones nativas, o aplicaciones API clásicas, llegaron para quedarse y se les da prioridad en el contexto de la modernización, la compatibilidad con nuevas API, la compatibilidad con Windows 11, etc. Microsoft planea llevar los consentimientos y las API de UWP al mundo nativo.

Esto está sucediendo cada vez más, por ejemplo, con el control WebView 2 (Chromium Edge integrado, que Delphi y C ++ Builder ajustan y admiten), un componente COM. Otras API nuevas también usan COM, mientras que otras son nativas y algunas están basadas en WinRT, pero accesibles desde aplicaciones nativas.

Si el modelo de API nativa llegó para quedarse, esta es una noticia fantástica para Delphi y C ++ Builder. No solo es este el modelo al que Embarcadero siempre ha dado máxima prioridad (bueno, con la excepción de la corta era Delphi .NET), sino que también es el modelo que hemos estado extendiendo y expandiendo con el tiempo mucho más de lo que lo han hecho nuestros competidores. sus bibliotecas.

Si considera los marcos de interfaz de usuario alternativos que usan la API clásica, como la biblioteca MFC o la biblioteca WinForms, recibieron mucho menos atención y mejoras de Microsoft que la biblioteca VCL. Desde controles de interfaz de usuario adicionales hasta controles integrados de WinRT y Reunion, desde la compatibilidad con High DPI hasta el estilo de la interfaz de usuario, la biblioteca VCL se ha seguido expandiendo a un ritmo mucho mayor que las bibliotecas nativas de la competencia.

Es por eso que RAD Studio se posiciona hoy una vez más como la mejor solución disponible para crear aplicaciones cliente nativas de Windows. No solo eso, sino que ofrece una migración sorprendentemente fácil para bases de código de 10 o 20 años, incomparable con otras ofertas.

Es bueno ser un desarrollador de Delphi y C ++ Builder y crear aplicaciones de Windows de primera clase, ahora sin siquiera tener que temer que Microsoft desaproveche el modelo de aplicación en la próxima versión de Windows.