Nas últimas semanas, houve vários anúncios da Microsoft que revertem parcialmente as direções anteriores em termos de desenvolvimento do Windows. Em suma, a Microsoft está minimizando (se não substituindo totalmente) o modelo da Plataforma Universal do Windows.

Aqui estão alguns links relevantes:

• A Microsoft publica detalhes de migração UWP para Win32, mas provavelmente não é o que você pensa  https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
• UWP não está mais na moda, pois a Microsoft lança orientações para a migração de aplicativos para Windows App SDK  https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to -windows-app-sdk /
• A Microsoft suspende oficialmente o UWP  https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp

A UWP tem sido o foco de desenvolvimento de aplicativos da Microsoft desde o lançamento do Windows 8 e estava substituindo o foco na arquitetura .NET como a plataforma de desenvolvimento do Windows.

Agora, esta é uma evolução muito interessante da perspectiva dos desenvolvedores (e fornecedores de ferramentas de desenvolvimento como a Embarcadero) que permaneceram focados no modelo de desenvolvimento nativo do Windows clássico, já que somos cidadãos de primeira classe novamente depois de muito tempo.

Do nativo ao .NET e UWP

Por muitos anos, o modelo de desenvolvimento nativo baseado no envolvimento da API clássica do Windows e no aproveitamento das três bibliotecas principais de Kernel / Usuário / GDI e todas as suas extensões foi considerado uma abordagem obsoleta e de estilo antigo que logo seria abandonada. Este é o modelo clássico usado pelo Delphi e C ++ Builder (com a biblioteca VCL), mas também pelo Visual C ++ (com a biblioteca MFC).

Os desenvolvedores do Windows foram inicialmente incentivados a migrar para o .NET (com a ideia de que as APIs da plataforma futura exigiriam .NET e os aplicativos clássicos em algum momento parariam de ser executados no Windows). Com o tempo, ficou claro que não seria esse o caso.

À medida que o foco centrado em .NET diminuía, a Microsoft começou a empurrar a próxima ideia: a Plataforma Universal do Windows. Isso foi impulsionado principalmente por duas ideias: uma, a capacidade de executar o mesmo aplicativo em um PC desktop, mas também em um Windows phone, um console de jogos e uma tecnologia de visor; dois, uma plataforma mais segura com acesso limitado ao sistema operacional subjacente. No nível da API, o suporte a UWP implicava o uso das APIs da plataforma WinRT, que eram diferentes e incompatíveis com as APIs clássicas.

O UWP demorou a se recuperar. Para Delphi e RAD Studio não havia uma opção, mas também a migração do Visual C ++ e .NET e C # implicaria no uso de diferentes bibliotecas de tempo de execução e diferentes controles de IU – representando uma grande reescrita de um aplicativo existente. Quando o Windows 8 foi lançado (ainda permitindo aplicativos de API clássicos), havia muito poucos aplicativos UWP disponíveis, incluindo da Microsoft. No entanto, alguns dos novos recursos da plataforma estavam disponíveis apenas por meio das APIs do WinRT, e é por isso que os desenvolvedores e ferramentas (RAD Studio incluído) vieram com opções para chamar APIs do WinRT de dentro de um aplicativo clássico. O suporte a notificações do RAD Studio Windows, por exemplo, é implementado com esta abordagem.

Enquanto a Microsoft insistia em UWP, indicando que os aplicativos clássicos seriam descontinuados, os desenvolvedores não deram ouvidos. A próxima etapa foi promover o chamado “Desktop Bridge”, ou seja, a capacidade dos aplicativos nativos de aproveitarem mais as APIs do WinRT e serem “empacotados” em um contêiner leve para segurança extra. Este último recurso foi obtido com o empacotamento de um aplicativo como APPX e posterior MSIX. Novamente, o RAD Studio há muito oferece esse suporte diretamente no IDE.

A Microsoft descreveu inicialmente a ponte como uma forma de ajudar a migrar aplicativos para UWP, que ainda era o objetivo da empresa. Os desenvolvedores podem mover seu aplicativo um formulário por vez. Rapidamente ficou óbvio que os desenvolvedores não tinham nenhum interesse real em converter suas grandes bases de código, mas estavam interessados ​​em usar todos os recursos da plataforma. APPX e MSIX também abriram as portas da Microsoft Store para aplicativos tradicionais.

Avance para o ano passado ou assim. A Microsoft anunciou o Project Reunion (agora rebatizado como Windows App SDK) com o objetivo de oferecer interoperabilidade total para aplicativos UWP para chamar APIs nativas e aplicativos nativos para chamar qualquer API UWP – mas acabou dando ao suporte de aplicativos nativos uma prioridade muito maior, com UWP agora deixado para trás – que é o que os anúncios acima indicam.

Voltar ao nativo

Ou seja, depois de mais de 15 anos em que a Microsoft vem considerando os aplicativos nativos do Windows como segunda classe, em breve cidadãos extintos, temos agora uma reversão total da posição. Os aplicativos nativos, ou aplicativos clássicos de API, vieram para ficar e têm prioridade no contexto de modernização, suporte a novas APIs, suporte ao Windows 11 e assim por diante. A Microsoft planeja trazer consentimentos UWP e APIs para o mundo nativo.

Isso está acontecendo cada vez mais, por exemplo, com o controle WebView 2 (Chromium Edge embutido, que Delphi e C ++ Builder envolvem e suportam), um componente COM. Outras novas APIs também usam COM, enquanto outras são nativas e algumas são baseadas em WinRT – mas acessíveis a partir de aplicativos nativos.

Se o modelo nativo de API veio para ficar, esta é uma notícia fantástica para Delphi e C ++ Builder. Não apenas este é o modelo que a Embarcadero sempre deu prioridade (bem, com exceção da curta era Delphi .NET), mas também é o modelo que temos estendido e expandido ao longo do tempo muito mais do que nossos concorrentes fizeram. suas bibliotecas.

Se você considerar as estruturas de IU alternativas que usam a API clássica, como a biblioteca MFC ou a biblioteca WinForms, elas receberam muito menos foco e melhorias da Microsoft do que a biblioteca VCL. De controles adicionais de IU a controles embutidos de WinRT e Reunião, de suporte para High DPI a estilos de IU, a biblioteca VCL continuou se expandindo a uma taxa muito mais alta do que as bibliotecas nativas concorrentes.

É por isso que o RAD Studio hoje está mais uma vez posicionado como a melhor solução disponível para a construção de aplicativos cliente nativos do Windows. Não só isso, mas oferece uma migração surpreendentemente fácil para bases de código de 10 ou 20 anos, sem paralelo com outras ofertas.

É bom ser um desenvolvedor Delphi e C ++ Builder e construir aplicativos Windows de primeira classe, agora sem nem mesmo temer a Microsoft depreciar o modelo de aplicativo na próxima versão do Windows.