Overview do Windows Runtime (WinRT)

Olá pessoal,

Hoje irei falar um pouco sobre a nova API de desenvolvimento de aplicações para o Windows 8, conhecida como Windows Runtime, ou simplesmente WinRT.

Por que uma nova API?

Tradicionalmente, quando desenvolvemos uma aplicação para o Windows (seja ele Windows 7, Vista, XP, ou anterior), quando precisamos acessar algum recurso do sistema operacional, como por exemplo, o sistema de arquivos, ou a recursos de rede, acessamos, de alguma maneira, uma API disponibilizada pelo sistema operacional. Essa API é conhecida como WinAPI, e é composta de milhares de funções e estruturas de dados. As funcionalidades da WinAPI são expostas em um modelo ao estilo de programação em C, ou seja, não é orientada a objetos. Isso a torna um tanto complexa, difícil de usar e aprender. Por essa razão, foram criadas algumas camadas de abstração em cima dessa API, sendo uma das mais famosa delas o .NET Framework. Muitas das APIs do .NET são wrappers, ou seja, encapsulam uma chamada a uma função da WinAPI para que o desenvolvedor não precise se preocupar em detalhes complexos da API nativa do Windows.

Windows Runtime (WinRT)

Para a construção de aplicações Metro do Windows 8, a Microsoft resolveu criar uma nova API chamada Windows Runtime, ou simplesmente WinRT. Essa API é completamente diferente da WinAPI tradicional, baseada no COM (Component Object Model), e toda a API possui metadados descrevendo cada componente, seja ele uma classe, interface, método, propriedade, etc., e tem também alguns recursos que oferecem maior segurança ao usuário.

Como você pode ver na figura acima, o Windows Runtime é utilizado para construção de aplicações Metro, que é o novo tipo de aplicação no Windows 8. Essas aplicações são imersivas e dão ao usuário uma experiência diferente daquela oferecida por aplicações desktop tradicionais.

Com o WinRT, é possível acessar vários recursos do sistema operacional, como arquivos, recursos de media e gráficos, recursos de rede, dados de geolocation, sensores, entre outros recursos. E para criar aplicações que utilizam os componentes do WinRT, o desenvolvedor poderá escolher sua linguagem de preferência, seja ela C++, C# ou VB.NET, ou Javascript. E para a construção da interface de usuário (UI), caso o desenvolvedor escreva a aplicação em C#, VB ou C++, ele irá utilizar XAML para definição dos elementos da UI. No caso do Javascript, será usado HTML5+CSS3.

Arquitetura do Windows Runtime

O WinRT é, obviamente, uma API implementada em código nativo, e é utilizada amplamente pelo sistema operacional para executar suas aplicações, e pela aplicação em si para interagir com o usuário e o sistema operacional.

Cada tipo de dados no WinRT possui metadados sobre ele mesmo, e esses metadados são criados seguindo o mesmo padrão dos metadados do .NET Framework. Esses arquivos de metadados estão localizados no seguinte diretório: C:\Windows\System32\WinMetadata. Nesse diretório, há vários arquivos .winmd, que são os arquivos contendo os metadados sobre os tipos de dados do WinRT. A imagem abaixo mostra o arquivo “Windows.Storage.winmd” aberto no IL Disassembler.

Podemos ver que ele mostra informações sobre os métodos, propriedades, etc.. sobre os tipos contidos na biblioteca de Storage do WinRT. Repare que não há Intermediate Language gerada. Isso acontece por que a implementação dos métodos é nativa, e está contida em algumas dlls do sistema operacional. Esses arquivos .winmd contém somente metadados.

Como o WinRT é baseado em COM, todos os tipos de dados expostos por ele são baseados em Interfaces. E quando ativamos um objeto do WinRT, estamos, na verdade, recebendo uma referência de um objeto que implementa os métodos desta interface.

As linguagens que utilizamos para acessar o WinRT são por sua vez, baseadas em classes, e cada uma tem suas particularidades de utilização de objetos. É exatamente para prover esse mapeamento, e acesso às interfaces do WinRT pelas linguagens utilizadas para desenvolver os aplicativos (C++, C#, VB e JS), e prover uma experiência de desenvolvimento familiar ao desenvolvedor, que a foi criado um componente chamado Language Projection. Assim, o desenvolvedor fica livre de ter que lidar com particularidades de APIs baseadas em COM e trabalha com os objetos da mesma maneira que ele já está acostumado na sua linguagem de preferência.

Outro componente muito importante do WinRT, é o Runtime Broker. Certas APIs do WinRT expoem dados privados do usuário, como arquivos nas pastas pessoais, dados da webcam, dados de geolocation, entre outros. Uma aplicação construída sobre o WInRT não tem acesso direto a esses dados. Quando uma aplicação chama um método para ter acesso a esses dados, a execução da aplicação é desviada para um processo chamado RuntimeBroker.exe que irá verificar se sua aplicação tem privilégios para acessar esses dados, e irá também mostrar um prompt para o usuário perguntando se ele permite que a aplicação acesse estes dados. Se o usuário permitir, então sua aplicação irá poder acessar os dados requisitados. Além disso, para acessar esses recursos, a aplicação terá que definir em um arquivo de manifesto, quais recursos ela irá acessar.

Por último, se uma aplicação é criada em C#/VB ou Javascript, essa aplicação rodará sobre um ambiente de execução, como tradicionalmente aplicações construídas com essas linguagens são executadas. No caso do C#/VB, as aplicações irão rodar sobre a CLR (Common Language Runtime), e aplicações feitas com HTML e Javascript irão rodar sobre a engine do Internet Explorer 10.

Assincronia

Como o Windows 8 é um sistema operacional projetado para rodar em dispositivos móveis como tablets e slate PCs, a Microsoft se preocupou muito em ter certeza que a User Experience fosse a mais responsiva e rápida possível. Por isso, uma das decisões feitas no design da WinRT foi que qualquer chamada a método que pudesse demorar mais que 50 milisegundos, iria ser uma chamada assíncrona. Isso significa que todas as operações de IO, ações que dependem de alguma ação do usuário, e algumas outras, serão assíncronas.

Por hoje é só. Em breve, irei postar mais algumas coisas aqui mais detalhadamente sobre outros assuntos relacionados ao Windows Runtime. Até lá.

Breno Ferreira