Rodrigo Strauss :: Blog
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
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...).