Pela primeira vez, desde 1993 (ano do lançamento do Windows NT) a Microsoft introduz uma novidade nas APIs para programação nativa em Windows, o WinRT. O WinRT é um dos destaques do futuro Windows 8 e não é apenas uma camada de abstração sobre as APIs antigas, mas sim uma interface alternativa ao Win32, também acessando o kernel diretamente. A nova API implementa um ambiente de execução completamente novo, com semântica bem diferente do Win32.
Enquanto a Win32 foi projetada com a linguagem C (e Pascal) em mente, a nova API é totalmente escrita em C++ e projetada desde o início para ser orientada a objetos. Consistência, facilidade de uso e desempenho são os principais focos. Como todos os objetos da WinRT suportam reflexão, a API será mais amigável para linguagens como JavaScript, que poderão utilizá-la de forma eficiente. Além disso, foi implementado um modelo unificado de objetos, uma ave rara nas bibliotecas C++.
Uma nota importante: a Microsoft não vai desativar a API Win32, mantendo as duas em paralelo, para continuar suportando as aplicações tradicionais para Windows.
Desenvolvimento em C++
Com a WinRT, as interfaces gráficas em C++ serão prioritariamente escritas em XAML. Todas as bibliotecas para trabalho com o XAML foram portadas para C++ e compiladas como aplicações x86 nativas. Aplicações Metro escritas em C++ e XAML serão aplicações nativas, compiladas no Visual C++, e não serão executadas sobre o .NET.
Invocar métodos dos controles de interface gráfica será o mesmo que invocar métodos de qualquer outro objeto C++, permitindo bom desempenho mesmo em máquinas menos poderosas. Bibliotecas utilizadas por aplicações C++ modernas, como o Boost, também são suportadas.
Tudo o que foi dito sobre a arquitetura x86 também deverá ser verdade para a arquitetura ARM, já que a Microsoft promete que o Windows 8 poderá ser executado em ambos os processadores.
Fim das janelas sobrepostas
Caixas de diálogo, um conceito fundamental do Windows desde o início, não existirão no WinRT. O impacto em usabilidade e desempenho dessa funcionalidade não se justificam mais para a Microsoft. Aplicações que desejarem esse comportamento de interface deverão criar outras maneiras de expressar o comportamento de itens como janelas de mensagens.
Outra biblioteca que não será portada para o WinRT é o GDI. Uma aplicação desenvolvida para a interface Metro deve fazer isso de ponta-a-ponta, e aparentemente não será possível misturar em uma aplicação janelas com interface clássica e interface Metro.
Interface PlayTo
Outra interface que será exposta é o PlayTo. Com ela, aplicações poderão enviar arquivos de mídia, como vídeos ou áudio, para uma entidade intermediária chamada charm. O charm vai permitir que o usuário escolha qual aplicação será usada para ver o conteúdo. Provavelmente não apenas arquivos, mas qualquer mídia que possa ser fornecida através de um stream.
C#/VB.NET: o fim do P/Invoke
A invocação de funções da API nativa em .NET geralmente envolve a definição de estruturas intermediárias e a manipulação de ponteiros. Com o WinRT, todas as APIs serão expostas como objetos que poderão ser consumidos diretamente por aplicações em C# ou VB. Isso colocará os desenvolvedores .NET no mesmo patamar dos desenvolvedores de código nativo em C++.
O tempo de resposta está sendo destacado pela Microsoft. Para convencer os desenvolvedores da importância desse aspecto, todas as APIs com chamadas ao sistema operacional e que levem mais do que 50ms serão expostas como operações assíncronas.
JavaScript
A quarta linguagem de primeira linha no Windows 8 será o JavaScript. Mesmo não utilizado o XAML, as aplicações JavaScript terão acesso direto à API WInRT, da mesma forma que as aplicações nativas (em C++) e as aplicações em .NET. Não se trata apenas de um container como o PhoneGap, desenvolvedores utilizando JavaScript terão a mesma API disponível para os desenvolvedores das demais linguagens.
Para JavaScript, as ferramentas para a construção de interfaces gráficas serão HTML e CSS, ao invés do XAML. Será usado o mesmo mecanismo de renderização do Internet Explorer 10 para as aplicações Metro em JavaScript, apesar de não serem executadas em um navegador. Aplicações escritas dessa forma terão terão a mesma aparência e comportamento das aplicações nativas.
Componentes da interface gráfica em aplicações JavaScript terão o mesmo nível de funcionalidade que os de C++ ou .NET. Alguns serão intrínsecos do motor de HTML; outros serão escritos em JavaScript. Estes últimos serão baseados em elementos div, de forma semelhante a controles do jQuery.
App Container e permissões para Aplicações
Aplicações Metro serão executadas em um ambiente que está sendo chamado de “app container”. Esse mecanismo deve substituir o ambientes de janelas utilizado no Win32.
A maioria das chamadas de API é enviada diretamente ao kernel, mas algumas serão enviadas através de um system broker. Esse broker (intermediário) garantirá que o sistema execute apenas recursos aprovados pelo usuário. Por exemplo, quando uma aplicação tentar acessar a câmera pela primeira vez, pedirá ao usuário que aprove o acesso a esse recurso de hardware. As aplicações precisarão listar em um manifesto todos os recursos controlados de que precisam para execução. Todo esse modelo é bastante familiar aos programadores que já desenvolvem para plataformas móveis.
As aplicações Metro rodando no container WinRT, portanto, serão sempre monitoradas pelo system broker, mesmo aquelas escritas em C++. A ideia é limitar o dano potencial que uma aplicação poderá criar no sistema. Dessa forma será muito mais difícil escrever uma aplicação maliciosa para o ambiente WinRT do que para o ambiente Win32.
Todas as Aplicações Metro Deverão ser Assinadas
Finalmente, com o WinRT, aplicações anônimas não serão mais permitidas. Inicialmente as aplicações poderão ser auto-assinadas, mas para publicação na app store deverão ser assinadas com um certificado verdadeiro.