Como o Windows 8 Runtime (aplicativos WinRT / Windows Store / Windows 10 Universal App) se compara ao Silverlight e WPF? [fechadas]

353

Estou tentando entender o novo Windows 8 Runtime usado para criar aplicativos no estilo Metro . Eu sei que você pode usá-lo com XAML e é baseado no .NET, para que C # e VB.NET possam ser usados para escrever os aplicativos, mas parece ter algo a ver com HTML, CSS, DOM e JavaScript.

Alguém pode explicar o que é isso em alguns parágrafos, em termos que um programador de interface do usuário .NET possa entender? (Estou sentindo falta de algo "chave" necessário para entendê-lo.)

Todos sabemos que o WPF, o Silverlight , o Windows Forms etc. continuará funcionando no Windows 8 (e Windows 10) em pelo menos nos sistemas Intel, portanto, não me diga que ...

— Ian Ringrose
fonte

22

Não é baseado no .NET, apenas exposto a ele (um pouco como interoperabilidade COM, mas muito mais transparente ... por exemplo, sem assemblies de interoperabilidade).

— Pavel Minaev 14/09/11

Você está solicitando o WinRT como plataforma (ABI, modelo de objeto etc.) - nesse caso, faz mais sentido compará-lo ao COM ou .NET - ou sobre as bibliotecas de classes padrão do WinRT, incluindo as da interface do usuário?

— Pavel Minaev 14/09/11

11

Observe que você deve distinguir a tecnologia subjacente, o modelo de objeto etc. - semelhante a, por exemplo, COM - e as bibliotecas específicas implementadas usando essa tecnologia. Mesmo no último, nem todas as bibliotecas padrão são bibliotecas de interface do usuário - se você procurar no Pesquisador de objetos no VS, poderá ver a variedade de recursos que os Windows.*espaços de nomes cobrem. A terminologia até agora é um pouco confusa aqui, pois o WinRT se refere à tecnologia e a todo o conjunto de bibliotecas padrão. Eu não acho que exista um rótulo conciso apenas para as bibliotecas da interface do usuário ( Windows.UI.*).

— Pavel Minaev 14/09/11

@TrueWill: faz mais sentido aprender os três, para que seu conhecimento seja mais abrangente e para que você possa decidir qual solução é melhor para um determinado problema. Não basta aprender um dos três.

— Chris Charabaruk

2

@TrueWill: O Silverlight não terá lançamentos futuros: zdnet.com/blog/microsoft/microsoft-releases-silverlight-5/…

— Sabuncu

479

No nível mais baixo, o WinRT é um modelo de objeto definido no nível ABI. Ele usa o COM como base (para que todo objeto WinRT implemente IUnknowne refcounting) e crie a partir daí. Ele adiciona muitos conceitos novos em comparação com o COM antigo, a maioria dos quais vem diretamente do .NET - por exemplo, o modelo de objeto do WinRT possui delegados e os eventos são feitos no estilo .NET (com delegados e adicionar / remover assinante) métodos, um por evento) em vez do antigo modelo COM de fontes e coletores de eventos. Entre outras coisas notáveis, o WinRT também possui interfaces parametrizadas ("genéricas").

Outra grande mudança é que todos os componentes do WinRT têm metadados disponíveis para eles, assim como os assemblies do .NET. No COM, você meio que teve isso com typelibs, mas nem todos os componentes do COM os tinham. Para o WinRT, os metadados estão contidos nos arquivos .winmd - consulte "C: \ Arquivos de programas (x86) \ Windows Kits \ 8.0 \ Windows Metadata \" na Visualização do desenvolvedor. Se você bisbilhotar, verá que eles são realmente conjuntos de CLI sem código, apenas tabelas de metadados. Você pode abri-los com o ILDASM, de fato. Observe que isso não significa que o próprio WinRT seja gerenciado - ele simplesmente reutiliza o formato do arquivo.

Existem diversas bibliotecas implementadas em termos desse modelo de objeto - definindo interfaces e classes do WinRT. Mais uma vez, veja a pasta "Metadados do Windows" mencionada acima para ver o que há; ou simplesmente inicie o Pesquisador de objetos no VS e selecione "Windows 8.0" no seletor de estrutura, para ver o que é coberto. Há muita coisa lá, e ela não lida apenas com a interface do usuário - você também recebe namespaces como Windows.Data.Json, ou Windows.Graphics.Printing, ou Windows.Networking.Sockets.

Em seguida, você obtém várias bibliotecas, que estão lidando especificamente com a interface do usuário - a maioria seria vários namespaces sob Windows.UIou Windows.UI.Xaml. Muitos deles são muito semelhantes aos namespaces WPF / Silverlight - por exemplo, Windows.UI.Xaml.Controlssão muito semelhantes System.Windows.Controls; idem para Windows.UI.Xaml.Documentsetc.

Agora, o .NET tem a capacidade de referenciar diretamente os componentes do WinRT como se fossem assemblies do .NET. Isso funciona de maneira diferente da COM Interop - você não precisa de artefatos intermediários, como assemblies de interoperabilidade, apenas /rum arquivo .winmd e todos os tipos e seus membros em seus metadados ficam visíveis para você como se fossem objetos .NET. Observe que as próprias bibliotecas do WinRT são totalmente nativas (e, portanto, os programas C ++ nativos que usam o WinRT não exigem CLR) - a mágica de expor tudo o que é gerenciado é dentro do próprio CLR e é de nível bastante baixo. Se você criar um programa .NET que referencie um .winmd, verá que ele realmente se parece com uma referência externa de montagem - não há truques fáceis como o tipo incorporação nele.

Também não é um mapeamento contundente - o CLR tenta adaptar os tipos WinRT aos seus equivalentes, sempre que possível. Assim, por exemplo, GUIDs, datas e URIs tornar-se System.Guid, System.DateTimee System.Uri, respectivamente; Interfaces de coleta do WinRT como IIterable<T>e IVector<T>torne IEnumerable<T>- se e IList<T>; e assim por diante. Isso acontece nos dois sentidos - se você tem um objeto .NET que implementa IEnumerable<T>e o repassa ao WinRT, ele será visto como IIterable<T>.

Por fim, o que isso significa é que seus aplicativos .NET Metro obtêm acesso a um subconjunto das bibliotecas .NET padrão existentes e também às bibliotecas WinRT (nativas), algumas das quais - particularmente Windows.UI- se parecem muito com o Silverlight, em termos de API. Você ainda tem XAML para definir sua interface do usuário e ainda lida com os mesmos conceitos básicos do Silverlight - ligações de dados, recursos, estilos, modelos etc. Em muitos casos, é possível portar um aplicativo Silverlight simplesmente pelos usingnovos namespaces, e ajustando alguns lugares no código em que a API foi ajustada.

O próprio WinRT não tem nada a ver com HTML e CSS, e só se relaciona com o JavaScript no sentido de que ele também é exposto ali, semelhante à maneira como é feito para o .NET. Você não precisa lidar com HTML / CSS / JS ao usar as bibliotecas de interface do usuário do WinRT no seu aplicativo .NET Metro (bem, acho que, se você realmente quiser, pode hospedar um WebViewcontrole ...). Todas as suas habilidades em .NET e Silverlight permanecem muito relevantes neste modelo de programação.

— Pavel Minaev
fonte

E a compatibilidade com o WPF-WinRT? Haverá inconsistências do tipo WPF-Silverlight?

— Den

5

O @Den WPF não é um bom ponto de comparação aqui - a API está muito, muito mais próxima do Silverlight. Se você olhar dessa maneira, existem inconsistências entre os dois, mas a escala está mais próxima do desktop versus WP7 Silverlight, não do Silverlight vs WPF.

— Pavel Minaev 15/09

11

Ótima resposta. O WinRT acessa o kernel do NT diretamente (quando precisa de suporte do SO) ou passa pelo Win32?

— Timores 22/09

4

Ligeira correcção / adição: A WinRT componente implementa a interface de IInspectable, que deriva de IUnknown ...

— Martin Ba

66

Na palestra Build :

Pilha de palestras

Eles estão fornecendo APIs comuns para aplicativos HTML / CSS / JavaScript e aplicativos C # / XAML. C # e XAML serão usados, mas não serão exatamente o WPF ou o Silverlight.

— RandomEngy
fonte

8

Isso é um pouco mais complicado, pois o novo XAML está disponível para C # e C ++ (nativo). Não é o WPF nem o Silverlight, mas muito próximo do último - como demonstrado na palestra, muitas vezes você pode simplesmente mudar várias utilizações e outras refatorações triviais no código existente do Silverlight. As idéias principais por trás do WPF / Silverlight - marcação declarativa, recursos, estilos, modelos, ligações de dados etc. - estão todas lá. A maioria dos controles também está lá.

— Pavel Minaev 14/09/11

2

Há um gráfico melhor por aí que vi hoje de manhã, mas simplesmente não consigo encontrá-lo novamente. EDIT: Encontrado, graças a outra resposta sobre esta pergunta. dougseven.files.wordpress.com/2011/09/win8-new-platform.png

— Chris Charabaruk

11

Onde o WPF se encaixa no slide?

— Paparazzo

11

Ele é agrupado com o .NET / Silverlight, no canto inferior direito.

— BoltClock

11

Essa imagem é grosseiramente incorreta, no que diz respeito às peças existentes. Você quase pode corrigi-lo substituindo "Windows Kernel Services" por "Win32 kernel32.dll" e "Win32" por "Win32 user32.dll + gdi32.dll" ... mas o IE e o .NET / Silverlight devem estar em camadas principalmente na parte superior do user32.dll + gdi32.dll e aqueles como C / C ++ / Java / Delphi / etc também chegam ao kernel32.dll. O importante é que user32.dll e gdi32.dll NÃO estejam na base do WinRT e que os aplicativos da Windows Store não possam alcançar o WinRT passado diretamente para toda a potência do kernel32.dll.

— Ben Voigt

37

A idéia principal é que agora existem duas faixas de desenvolvimento - o Desktop e o Metro.

A área de trabalho é onde estão os aplicativos antigos.
A nova classe de aplicativos, aplicativos Metro, pode ser criada de várias maneiras, inclusive por VB.NET, C # ou C ++. Essas três opções de idioma podem usar XAML para criar a interface do usuário. A alternativa é usar JavaScript / HTML5 / CSS para o desenvolvimento da interface do usuário e do código do aplicativo.

Alguns pontos importantes:

O Windows 8 parece um sistema operacional de telefonia móvel aprimorado.
No Metro, não há janelas de nível superior sobrepostas, assim como não há em um telefone celular. Se você deseja um aplicativo no estilo MDI, precisa permanecer na área de trabalho.
Os aplicativos estilo Metro são suspensos automaticamente quando não estão visíveis. Isso foi feito para prolongar a vida útil da bateria. Isso significa que não fará sentido que muitos aplicativos de desktop existentes, que executam o processamento em segundo plano, mesmo que o usuário não esteja interagindo com eles, sejam portados para o Metro.
A versão ARM do Windows 8 não suporta aplicativos de área de trabalho. Portanto, se você deseja escrever um aplicativo e deseja que ele funcione em qualquer versão do Windows, ele deve ser um aplicativo Metro.

— dodgy_coder
fonte

2

No Metro, não há janelas de nível superior sobrepostas . Ainda existe Popup( msdn.microsoft.com/en-us/library/windows/apps/… ); portanto, se você quiser, poderá criar algo semelhante ao MDI. Obviamente, não é recomendável abusá-lo, pois você corre o risco de acabar com uma interface do usuário não compatível com o toque.

— Pavel Minaev 15/09

@Pavel - isso é interessante - isso significa que você pode ter algumas janelas de nível superior rodando lado a lado, mas não se sobrepondo? por exemplo lado a lado ... compartilhando metade da tela, por exemplo? O aplicativo WPF em que estou trabalhando agora precisa desse tipo de funcionalidade.

— precisa saber é o seguinte

3

Todo aplicativo Metro possui apenas uma janela de nível superior. Você pode ter dois aplicativos Metro rodando lado a lado, mas isso é algo que o usuário decide - não há como o aplicativo se forçar a essa configuração. Além disso, mesmo se você tiver dois aplicativos sendo executados lado a lado, eles não poderão se comunicar para coordenar (exceto através de gestos explícitos do usuário, como "Compartilhar em").

— Pavel Minaev 16/09

11

Por outro lado, é possível, é claro, subdividir sua própria janela de nível superior em quantas áreas você desejar e fornecer um divisor móvel para redimensioná-las - que, da perspectiva do usuário, pareceriam duas janelas de nível superior com azulejos . No entanto, eles ainda apareceriam como uma coisa no alternador de aplicativos (mas você provavelmente desejaria?).

— Pavel Minaev

3

Segundo Martyn Lovell, não existe nenhum mecanismo deliberado para isso, e alguns que poderiam ser usados para isso são intencionalmente restritos. Os pipes nomeados não estão lá, por exemplo, nem os arquivos mapeados na memória. Existem soquetes (incluindo soquetes de servidor), mas ao conectar-se localhost, você pode conectar-se apenas ao mesmo aplicativo. Você pode usar arquivos normais em uma das "pastas conhecidas" compartilhadas (Documentos, Imagens, etc.), mas esse é um hack razoavelmente grosseiro que requer pesquisa e fica visível para o usuário.

— Pavel Minaev

24

Há uma versão modificada da arquitetura que certamente o ajudará a entender exatamente onde estão as coisas. Um dos ninjas da Telerik conversou com a equipe do CLR e modificou a imagem:

Plataforma e ferramentas do Windows 8 (incluindo o CLR)

Aqui você pode ver onde está o CLR. O framework .NET agora possui dois perfis

1- Perfil do .NET Metro (CLR que lida com o aplicativo Metro)

2- Perfil do cliente .NET (tempo de execução CLR para aplicativos C # e VB.NET)

Espero que isso lhe dê uma imagem mais clara. Leia o artigo completo em Uma imagem ruim vale por mil longas discussões. .

— vendettamit
fonte

17

Muitos detalhes da Microsoft aqui .

O Windows Runtime é exposto usando os metadados da API (arquivos .winmd). Esse é o mesmo formato usado pela estrutura .NET (Ecma-335). O contrato binário subjacente facilita o acesso às APIs do Windows Runtime diretamente no idioma de desenvolvimento de sua escolha. A forma e a estrutura das APIs do Windows Runtime podem ser entendidas por linguagens estáticas, como C #, e linguagens dinâmicas, como JavaScript. O IntelliSense está disponível em JavaScript, C #, Visual Basic e C ++.

Em resumo, o Windows Runtime é um novo conjunto de bibliotecas que expõe a funcionalidade do Windows e está disponível para JavaScript / C # / VB / C ++. Cada idioma foi criado para entender e poder chamá-los diretamente, em vez de precisar passar por uma camada de thunking.

Silverlight e WPF são tipos de XAML executados no CLR. Entre outras funcionalidades, o Windows Runtime expõe uma versão do XAML muito semelhante ao Silverlight, mas de maneira nativa, não por meio do CLR. Ele pode ser acessado pelo CLR, mas também pelo C ++.

— Steve Rowe
fonte

2

A "camada de thunking" pode estar presente - por exemplo, o CLR realmente usa RCWs - mas agora é um detalhe de implementação. Da perspectiva do desenvolvedor, você faz referência direta aos arquivos .winmd do WinRT e trabalha diretamente com os tipos internos.

— Pavel Minaev 15/09

3

Enquanto a camada de thunking usa RCWs, os RCWs para o tempo de execução do Windows são mais leves que os RCWs P / Invoke antigos.

— precisa