logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

Windows Vista != .NET

Richard Grimes, um conhecido escritor sobre tecnologia Microsoft que abandonou totalmente o .NET (já discutimos isso aqui no site) escreveu um novo artigo seguindo a teoria dele (que eu não concordo, diga-se de passagem) de que a Microsoft não confia no .NET. Nesse artigo ele faz uma medição sobre a quantidade de managed assemblies no Windows Vista, e afirma que o uso do .NET no Windows Vista é muito pequeno, principalmente se for levado em consideração as delarações e pressões feitas pela Microsoft em cima do .NET.

Uma das frases dele é "Microsoft appears to have concentrated their development effort in Vista on native code development" - o que até me parece óbvio já que estamos falando de um sistema operacional. O interessante é que eu estava justamente pensando em escrever algo sobre isso. A primeira coisa que eu fiz após instalar o Vista em casa foi instalar o WinDbg e fazer dump dos symbols de vários executáveis, para saber o quanto de .NET estava sendo usado no Vista. O Windows Explorer tinha algumas partes ou extensões feitas em .NET nos builds alfa do Longhorn. Não existe mais nada de .NET no Windows Explorer, assim como não existe nada de .NET na grande maioria dos executáveis do Windows Vista.

Com esses meus experimentos, eu fiz algumas descobertas bem interessantes: sabe quais bibliotecas tiveram seu uso aumentado consideravelmente no shell do Windows (Explorer e seus adendos) em relação ao Windows XP? ATL e WTL. Outro executável que usa bastante ATL e WTL é o MMC, que agora aceita snapins feitos em .NET (mas continua sendo feito em "old unmanaged code").

Ao invés do Dr. Grimes procurar referências usando os symbols, ele fez um programa para descobrir quais programas que fazem parte do Windows Vista usam realmente .NET. A surpresa é que a lista é muito pequena. O resultado do estudo dele não me espanta. Acho que ele exagera um pouco no FUD, mas é perfeitamente compreensível e perdoável (para mim, uma fonte claramente não-neutra) considerando o gigantesco FUD feito pela Microsoft e comunidade .NET sobre C/C++ e o "old unmanaged code". Só acho que ele podia ter falado mais de Indigo/WCF (que me parece ser feito todo em .NET) e Avalon/WPF (que é 50% managed em usermode e fortemente baseado em DirectX unmanaged em kernel mode). Não dá pra esquecer que o Avalon é um sistema de composição que tem quase nada de dependência do Win32.

Me parece que ele compartilha da minha opinião: o WinFX é parte do Windows da mesma forma que o .NET Framework é. Os desenvolvedores usam para desenvolver aplicações para Windows, mas a própria Microsoft não usa (a não ser em raras situações visivelmente experimentais e para substituir o VBA e VB6). Me parece que nada (ou quase nada) no Windows Vista é feito usando WinFX ou até mesmo .NET. Só o WinFX mesmo é feito em .NET. Tudo no Windows continua sendo feito no velho e carcomido Win32. Parece que tudo que eu escrevi a dois anos continua válido.

PS1: Fora o fato de que o WinFX ainda é muuuuito lento. Eu baixei o Expression da Microsoft que é 100% managed e 100% Avalon/WPF. Rodei tudo em um Turion64 com 512 de RAM e uma GeForce 256MB. O programa consome centenas de MBs de memória e nem chega a ser usável de tão lento que é. Até para desenhar o menu ele demora (sim, isso é sério). Mas, como isso deve melhorar até o RTM, é melhor esperar para ver.

PS2: Dan Fernandez da Microsoft é um dos pregadores que sempre ajuda a defender a visão de que a Microsoft usa bastante .NET internamente. Para ilustrar o seu ponto de vista ele divulgou a quantidade de linhas de código C# usada em vários produtos Microsoft. Mas sua declaração de que o Visual Studio .NET tem 8 vezes mais linhas de código managed do que o Avalon/WPF me deixou em dúvida. Um sistema que quer substituir o Win32 e que é sabidamente complexo com só 900 mil linhas de código C#? Apesar de ser só uma especulação, ainda acho que o Avalon/WPF deveria ser bem maior do que o Visual Studio.


Em 25/04/2006 20:28, por Rodrigo Strauss


  
 
 
Comentários
Fabio Galuppo | website | e-mail | em 25/04/2006 | #
Pelo que li nas últimas publicações dele, acredito que não se afastou totalmente do .NET. Num dos artigos recentes de comparação entre native code e managed code, Grimes provou numa aplicação real que o managed code pode superar o native code (Ele portou uma solução de Fast Fourier Transformation - FFT). Então ele parece que esta reavaliando este tópico, não acha?

Qto a pesquisa dele vinha acompanhando e achei muito interessante (inclusive as respostas do Dan Fernandez) - em certos pontos ele tem razão. Concordo com vc, pois a MS não ta desistindo do .NET (pelo contrário). Assistindo um vídeo do Anders, onde ele cita que na MS tem 2 tipos de pessoas - os evolucionários (que queriam evoluir o COM) e os revolucionários (que fizeram o .NET). A iniciativa do .NET partiu da Developer Division, então é mais ou menos óbvio perceber uma restrição do time do Windows - e notar que eles usam tecnologias nativas afinal eles são owners da Windows API. No entanto, com o tempo e maturidade do .NET este quadro deve mudar dentro do Windows. Existe muita coisa feita em managed code, como toda suite do Expression que eu achei fantastica ou até mesmo o F# ou o IronPython.

O que acredito é que native code está perdendo cada vez mais espaço e se tornando nicho (System Programming - alguns casos são possíveis em managed code, Drivers e Gerenciamento manual de memória).

Quanto ao WCF ele é, digamos 99%, managed code e os outros 1% para suportar COM. O programming model do WPF e o XAML são 100% managed code e sua base é o DirectX 9 ( http://microsoft.sitestream.com/PDC05/PRS/PRS311_files/Botto...).
Rodrigo Strauss | website | em 25/04/2006 | #
Sim, em alguns casos o managed code (Java ou C#) pode ser mais rápido do que unmanaged code. Mas são poucos os casos e nada que seja de muito uso prático. Eu sempre escrevi que um dia o managed code pode ser mais rápido que o nativo (não vou repetir os motivos), mas esse dia ainda está um pouco longe.

Claro, Microsoft não vai desistir do .NET. Só que eles são bem mais sensatos do que muita gente que existe por aí, que acha que .NET resolve tudo. Eles sabem que não é verdade. Eu gostaria de saber o motivo deles terem retirado do Windows Explorer a parte managed.

Eu acho o COM COMplicado demais para o povão, .NET é bem mais simples. Um grande progresso nessa área, sem dúvida. Mas em alguns casos (o meu) vale a pena a complexibilidade em troca da flexibilidade e velocidade.

Ainda acho que algo dentro do Windows em .NET (descontando as bibliotecas) e usado pela Microsoft ainda leva algum tempo. Vamos ver no que vai dar esse Expression, já que o último CTP/Beta/sei-lá-o-que que eu testei estava péssimo. Mas tudo bem, o último CTP do Vista também está horrível, vou sentar e esperar.

Eu acho que o unmanaged code (C/C++) continua com o mesmo nicho de antes, e o .NET está tomando o (grande) nicho do VB6, VBA, Java, Delphi e talvez MFC. Com vantagens e desvantagens, é claro. A Microsoft faz coisas Web em .NET (ASP.NET é realmente muito bom) e extensibilidade: Office é C/C++, mas você extende em .NET, SQL Server 2005 é feito em C/C++ mas extensível em .NET. A regra agora me parece: C++ para Microsoft, .NET para o povão. E eu não gosto de discutir nichos porque eu atuo em nichos bem limitado (aplicação financeira server side de alta performance e segurança da informação) onde o uso de managed é completamente inviável.
Fabio Galuppo | website | e-mail | em 26/04/2006 | #
.NET não resolve tudo, mas a questão não é o .NET em si - e sim código gerenciado x código nativo. Abstraindo alguns detalhes, uma aplicação bem escrita em código gerenciado se comporta tão bem como código nativo. Se numa situação o código nativo for necessário, vc tem diversos mecanismos para interoperar (diga-se de passagem q C++/CLI e VC são excelentes nisto).

O .NET não foi criado apenas para substituir elementos de UI ou VB, ele nasceu para ser uma plataforma de desenvolvimento que abrange do simples (VB com VB Compatibility) até server-side (Sockets, Threading, CAS, ...).

No caso do SQL Server, ele necessita de um gerenciamento manual de memória, coisa que um ambiente managed não provê. No entanto, nada impede que outros elementos do produto SQL sejam gerenciados. Outro ponto, é que a maioria dos softwares da MS são feitos em C++ e não vejo sentido reescrever um software inteiro (como o caso do Office). Por exemplo, o BizTalk e o Workflow Foundation são managed code.

"(aplicação financeira server side de alta performance e segurança da informação) onde o uso de managed é completamente inviável." - infelizmente devo discordar, pois pode ter certeza que managed code inclusive neste caso também se sairá muito bem! E ainda sobra um tempo pra tomarmos um chopp no alemão :) :) :)

Quando C apareceu, ele sofria o mesmo "preconceito" pelo pessoal de Assembly. Com o tempo C virou a principal linguagem de programação. O lance em si não era o C, mas sim a produtividade (e biblioteca) oferecida por ele, sendo que em alguns casos criticos temos possibilidade de "interoperar" com Assembly. Vejo que o lance de managed code (e seu ferramental) e native code entra neste contexto.
Rodrigo Strauss | website | em 27/04/2006 | #
Uma aplicação em código gerenciado pode se comportar tão bem como em código nativo, apesar de eu ainda não ter visto um exemplo marcante disso. Como um comentário que eu vi no blog do Don Fernandez:

"I can tell exactly what part of Visual Studio uses .Net:

Right click on your project in the Solutions pane, and click "Properties." Wait 3-5 seconds and the properties dialog pops up. How do I know this uses .Net? Because it took 3-5 seconds to load. On the same machine, MSVC 6 shows the properties dialog nearly instantly."

Talvez a intenção do .NET não fosse substituir o VB e VBA, mas ele o fez, com inúmeras vantagens e algumas desvantagens (sendo consumo de memória a pior delas).

Eu não acredito que um banco de dados do porte do SQL Server possa ter partes em managed code. O Java existe faz muito tempo e até hoje ninguém (nem do open source) se arriscou. Não acho viável. Mas só o tempo vai dizer.

Um código gerenciado pode em algumas situações ser mais rápido do que um não gerenciado. O fato é que com o não gerenciado vc está no bare metal, você tem todas as opções a seu dispor. Se um JITter gerou um código rápido para uma determinada situação, você pode analizar como ele fez isso e gerar algo parecido usando C/C++. Você não tem essa opção em código gerenciado.

Ainda acho código gerenciado inviável para o que eu faço. Veja o que eu escrevi em http://www.1bit.com.br/content.1bit/weblog/mais_um_benchmark . Muitas vezes eu tenho que otimizar código em Visual C++, imagina se fosse C#. Em C++ minhas opções de otimização de performance são muito maiores, porque a filosofia do C/C++ é não pagar pelo que você não usa. O foco do managed code não é performance, é outro. É ter um ambiente controlado, com gerenciamento de memória automático e com isolamento. Isso é ótimo para quem precisa disso. Mas eu não preciso tanto disso, e o preço a pagar é muito alto, no meu caso não compensa. Por exemplo, compare o consumo de memória do Word com um aplicativo .NET cuja única linha de código é "Application.Run(new Form());". Eu uso .NET para as coisas que eu acho que ele resolve. E em muitas coisas que eu preciso de produtividade ao invés de velocidade eu já nem uso mais .NET, uso Python.

Hoje em dia, um código feito em C e C++ na maioria das vezes rodam mais rápido do que um em Assembly. Isso não acontece com o managed code, ele ainda é bem mais lento do que o código nativo, por motivos claros e óbvios.

Bom, essa discussão está em vias de se tornar interminável. Acho que vamos ter que marcar um chopp para falar mais sobre isso :-D
Fabio Galuppo | website | e-mail | em 27/04/2006 | #
Rodrigo, releia meus comentários: ".NET não resolve tudo..." :)

Eu não advogo nem pra managed e nem pra native. Sou a favor dos 2: "Managed Code Where Possible, Native Code When Needed". Nem se quer falei de linguagens, pois para .NET posso usar C++/CLI e qdo necessário "chavear" para native code :)

O que estamos discutindo é performance, e não consumo de memória. Otimização para consumo de memória não é coisa para .NET (sabemos que uma app .NET consome bem mais que uma app Nativa), mas no mundo que vivemos (isto inclui alguns dispositivos móveis) a memória é barata! E este tbm é um bom motivo para usar Python (ambiente puramente dinâmico com GC). Na visão mais extrema de performance, programaria em C++ sem OO e qdo necessário "chavearia" para Assembly. Isto é legal qdo vc faz 1, 2 ou n vez. E na maioria das vezes não temos um beneficio real!

O fato de um managed code rodar mais rápido do que unmanaged tem relações independentes, ao contrário do C/C++ e Assembly. Ora, até um programa managed bem feito roda melhor do que um programa Assembly mal feito :) - Se compararmos 2 códigos otimizados ao extremo, 1 em C/C++ e outro em Assembly, a versão Assembly será melhor ou igual (em termos de performance). Optamos por C/C++ ao invés de Assembly por uma série de fatores como produtividade e portabilidade.

Só refletir sobre: "Managed Code Where Possible, Native Code When Needed" - e pode ser Perl com C ;)

Acho que temos muito assunto pro chopp no alemão a semana que vem :)
Rodrigo Strauss | website | em 28/04/2006 | #
Entendi a parte do "não resolve tudo" e sei que você é um cara muito consciente disso. Só ilustrei minha convicção (que pode estar errada, claro) de que managed code não resolve o MEU problema do dia a dia.

"Managed Code Where Possible, Native Code When Needed" é uma frase *quase* perfeita. Não vou entrar no mérito do managed, mas existe zilhares de coisas mais produtivas do que C++ e muitas áreas. Eu sou o primeiro a recomendar .NET quando eu recebo perguntas no formulário de contato do tipo "Quero fazer um programa de cadastro de sei-lá-o-que em C++. O que você acha?". E sou o primeiro a usar Python quando eu não preciso de performance nem UI.

O Python usa contador de referências (COM style) para controlar os objetos. De vez em quando ele roda um tipo de GC só pra detectar referências cíclicas.

O programador é sempre o culpado, programador ruim consegue fazer um código ruim em qualquer linguagem. Eu já vi cada coisa... :-)

Resumindo: nós concordamos em todos os pontos, menos no nível de viabilidade do .NET para alguns tipos de projeto.
Alexandre | e-mail | em 27/06/2006 | #
O que vai ser do Vista agora com a morte do WinFS? Eu sei que ele ja naum fazia parte do sistema a mais de um ano, mas ainda era a inovacao mais esperada...

http://msdn.microsoft.com/data/ref/winfs/

R.I.P. WinFS
Rodrigo Strauss | website | em 27/06/2006 | #
Alguns outros projetos dentro da Microsoft também foram empurrados com a barriga durante décadas, e depois de todo o trabalho seus pedaços foram absorvidos por outros projetos.

O próprio WinFS é um pedaço que sobrou do projeto Cairo: http://en.wikipedia.org/wiki/Cairo_%28operating_system%29

Tudo isso por causa desse costume besta da Microsoft de anunciar todo e qualquer vaporware que eles inventam...
Alexandre | e-mail | em 28/06/2006 | #
Pois eh...mas eu naum acho que o WinFS possa ser considerado vaporware. Parece ate que a MS demonstrou ele no PDC algumas semanas atras. Sei la o que aconteceu. Uma pena. Seria uma inovacao muito bem-vinda!
Eduardo Semsobrenome | em 22/07/2006 | #
.Net tirando mercado do Java? Sonhe amigo, sonhe....

Rodrigo Strauss | website | em 22/07/2006 | #
O .NET surgiu depois do Java. Se coisas que poderiam ser feitas em Java são feitas em .NET, isso é tirar mercado do Java, não é?
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::