Ex-CTO da Microsoft denuncia: Windows transformou-se numa salada de frutas! 14 anos, 14 mudanças, 17 tipos de GUI coexistentes

Ações cotadas é só ver os relatórios dos analistas da Golden Kylin, autoridade, profissionalismo, atempado, abrangente, ajude-o a descobrir oportunidades temáticas com potencial!

（Fonte: KuaiKeJi）

Notícias de 25 de março do KuaiKeJi: Jeffrey Snover, antigo CTO da Microsoft e que trabalhou na empresa durante 23 anos, publicou recentemente um longo post no blogue, no qual organiza sistematicamente as idas e vindas repetidas da Microsoft nas décadas passadas em torno de GUI (interface gráfica com o utilizador), revelando as razões pelas quais o ecossistema de desenvolvimento do Windows acabou por se fragmentar.

Em primeiro lugar, recuemos à década de 1980. Naquela altura, as APIs Win16 e Win32 forneciam a todos os programadores do Windows um modelo de desenvolvimento consistente; bastava ao programador aprender uma única coisa para abranger quase todos os cenários de aplicações Windows.

O autor técnico Charles Petzold escreveu o livro “Programming Windows”, com 852 páginas, que é considerado a bíblia do desenvolvimento de aplicações de ambiente de trabalho.

Chegando aos anos 1990, a Microsoft tentou ultrapassar as limitações do Win32 com tecnologias como MFC, COM, OLE e ActiveX. Snover aponta que essas componentes arquiteturais “se infiltraram em todos os recantos do desenvolvimento do Windows, introduzindo uma complexidade cognitiva sem precedentes”.

Na conferência de programadores, a narrativa tecnológica da Microsoft tornou-se fragmentada. Snover descreveu, sem rodeios, a apresentação de temas daquela altura como “keynote clusterf*ck”.

Em 2003, a Microsoft apresentou a visão técnica do Windows Longhorn, na qual o Avalon (mais tarde renomeado para WPF) assentava num subsistema de renderização vetorial XAML com aceleração por GPU, com uma força técnica extremamente forte. No entanto, em agosto de 2004, a Microsoft mudou de direção de forma repentina, exigindo que todo o novo desenvolvimento usasse C++.

A WPF, embora tenha sido lançada com o Windows Vista, o próprio Windows Shell não a adotou. Esta decisão semeou profundas divisões entre as equipas de engenharia do Windows e as equipas .NET.

Snover salienta que os conflitos internos acabaram por levar ao abandono da WPF, à morte do Silverlight e ao insucesso desde o nascimento do UWP (Plataforma Universal do Windows).

Em 2007, com a WPF já tendo provado a sua capacidade, a Microsoft voltou a mudar de rumo e lançou o Silverlight.

Em 2010, a Microsoft anunciou de repente que o Silverlight não era adequado para desenvolvimento multiplataforma; HTML5 era a direção futura. O Silverlight destinava-se apenas ao desenvolvimento para Windows Phone, e muitos programadores que tinham apostado fortemente no Silverlight ficaram apanhados de surpresa.

Avancemos para 2012, com o lançamento do Windows 8. Introduziu o runtime WinRT baseado em C++ nativo. A hostilidade da equipa do Windows em relação ao .NET fez com que os investimentos de uma década neste fossem instantaneamente descartados. Snover descreve assim o caos daquela época:

“A Microsoft está a contar duas histórias ao mesmo tempo; a equipa do Windows está a trabalhar no WinRT, enquanto a equipa .NET ainda está a empurrar a WPF. Andar após andar, diferentes vice-presidentes, diferentes roadmaps.

O que os programadores ouviram no //Build 2012 foi: o futuro é WinRT; ao mesmo tempo, HTML+JS é cidadão de primeira classe; ao mesmo tempo, o .NET ainda pode ser usado; ao mesmo tempo, o C++ voltou; ao mesmo tempo, deve escrever aplicações Metro; ao mesmo tempo, o seu código WPF corre muito bem. Isto não é estratégia; é ‘Jogos Vorazes’, com seis equipas a disputarem a sua atenção.

Os programadores de empresas olharam para o mecanismo de sandbox do UWP, para a distribuição obrigatória através da loja de aplicações e para a falta das APIs Win32; viraram costas e foram embora.”

Snover aponta que, nos últimos 14 anos, a Microsoft mudou 14 vezes na recomendação das estruturas de GUI do Windows. Atualmente, coexistem no ecossistema do Windows 17 tecnologias de GUI, cobrindo 5 linguagens de programação:

Estruturas nativas da Microsoft: Win32 (1985), MFC (1992), WinForms (2002), WPF (2006), WinUI 3 (2021), MAUI (2022)

Soluções web híbridas da Microsoft: Blazor Hybrid, WebView2

Soluções de terceiros: Electron (VS Code, Slack, Discord estão a usá-lo; Snover aponta em especial que é a tecnologia de GUI de ambiente de trabalho mais amplamente implementada atualmente no Windows, e que a Microsoft não tem qualquer relação com ela), Flutter (Google), Tauri, Qt, React Native for Windows, Avalonia (JetBrains, GitHub e Unity estão a usá-la; Snover ironiza estes programadores: “já não esperam pela Microsoft”), Uno Platform, Delphi, Java Swing/JavaFX

Snover usa a palavra que criou, “boof-a-rama”, para descrever o cenário atual como “fazer coisas estúpidas por gente inteligente”. Ele enfatiza que as tecnologias lançadas pela Microsoft, em si, muitas vezes não são más; aquilo que realmente as mata não são falhas técnicas, mas sim a política interna, a mudança anunciada cedo demais nas conferências de programadores e a estratégia comercial confusa.

O livro de Petzold “Programming Windows” não foi atualizado após a edição de 2012, a sexta (cobrindo Windows 8/WinRT); talvez seja também a melhor explicação para esta fragmentação imprevisível.

Snover entrou para a Microsoft em 1989. Ocupou sucessivamente os cargos de Partner Architect, Distinguished Engineer (2009), Technical Fellow e Chief Architect (2015), CTO (2019). Em 2022, deixou a empresa para se juntar ao Google; em 2025, reformou-se oficialmente. Com base no seu conhecimento sobre o modo como a Microsoft funciona por dentro, a credibilidade deste post no blogue dispensa comentários.

Muita informação, interpretação precisa — tudo na aplicação Sina Finance APP