- Até o fim dos anos 1980, o desenvolvimento de apps para Windows era claro, centrado em um único modelo baseado em Win16/Win32 API, mas nas décadas seguintes houve repetidas transições de plataforma sem consistência
- O colapso da estratégia de GUI do Windows não decorreu do fracasso de uma tecnologia específica, mas de três causas organizacionais: política entre equipes, cultura de anúncios centrada em conferências para desenvolvedores e mudanças estratégicas sem aviso prévio
- Em 1988, Programming Windows, de Charles Petzold, apresentou uma resposta clara para “como criar apps para Windows” com uma única API, o Win32, e um único modelo mental, mas nos 30 anos seguintes a Microsoft não conseguiu recuperar essa clareza
- De MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 e MAUI, houve proliferação de frameworks de GUI por décadas, e em cada iniciativa fracassada o fator principal foi menos a falha técnica e mais o fracasso na tomada de decisão dentro da organização
- Hoje, há mais de 17 tecnologias de GUI realmente usadas no Windows, e a mais amplamente distribuída entre as tecnologias de GUI desktop, o Electron, foi criada fora da Microsoft
- O diagnóstico central — “se uma plataforma não consegue responder em 10 segundos à pergunta ‘como devo criar uma UI?’, então essa plataforma fracassou com os desenvolvedores” — continua valendo para a Microsoft mesmo em 2026
A Microsoft depois do desaparecimento de uma estratégia coerente de GUI
- Há mais de 30 anos persiste a confusão da estratégia de GUI do Windows, sem uma resposta clara para a pergunta “qual framework devo usar para criar um novo app desktop para Windows?”
- Em 1988 existia um modelo único, a Win16/Win32 API, permitindo que os desenvolvedores escrevessem apps de uma única forma
- Nas décadas seguintes, a Microsoft não conseguiu manter uma plataforma coerente por causa de política interna, decisões guiadas por demos e mudanças na estratégia de negócios
- Como resultado, 17 tecnologias de GUI coexistem, de Win32 a MAUI, e os desenvolvedores enfrentam a confusão de uma plataforma sem estratégia
- A causa raiz não foi um fracasso técnico, e sim um fracasso organizacional
A era Petzold: a última fase realmente clara
- Em 1988, Programming Windows (852 páginas), de Charles Petzold, era a única resposta autorizada para trabalhar com a API Win16 em C, e isso por si só era a estratégia de desenvolvimento para Windows
- O Win32 cresceu em escala, mas preservou um único modelo mental de loop de mensagens, procedure de janela e GDI; Petzold explicava isso, e os desenvolvedores podiam aprender e aplicar imediatamente
- “Um OS, uma API, uma linguagem, um livro” — essa clareza era um sinal de confiança da plataforma
A febre da orientação a objetos (1992–2000): o início da complexidade
- Em 1992, o MFC encapsulou o Win32 em C++, mas depois OLE, COM e ActiveX surgiram, e arquiteturas de componentes, não frameworks de GUI, passaram a dominar o desenvolvimento para Windows como um todo
- Em vez de oferecer uma narrativa coerente, a Microsoft forneceu apenas primitivos tecnológicos para que os desenvolvedores montassem tudo por conta própria; isso aconteceu porque a cultura de anúncios centrada em keynotes de conferências priorizava impressionar executivos acima do sucesso dos desenvolvedores
PDC 2003 Longhorn: quando a visão devorou a si mesma
- Apresentado na PDC de 2003, o Longhorn tinha uma visão convincente baseada em três pilares: WinFS (sistema de arquivos relacional), Indigo (comunicação unificada) e Avalon (UI baseada em XAML com aceleração por GPU)
- Em janeiro de 2004, um memorando interno de Jim Allchin chamou isso de “porco (a pig)”, e em agosto do mesmo ano foi declarado um reset completo do desenvolvimento — voltando à base de código do Server 2003
- Após o reset, a liderança determinou “código gerenciado proibido dentro do Windows, todo código novo em C++”; o WPF foi lançado junto com o Vista, mas o próprio shell não usava WPF
- Essa decisão iniciou uma guerra civil organizacional de 13 anos entre a equipe do Windows e a equipe do .NET, culminando no abandono do WPF, no descarte do Silverlight e no fracasso do UWP
Silverlight: o padrão que passaria a se repetir (2007–2010)
- O WPF foi lançado no fim de 2006, mas em 2007 surgiu o Silverlight como plugin de navegador para competir com o Flash, fragmentando o investimento de desenvolvimento
- Na conferência MIX de 2010, um executivo da Microsoft disse durante a sessão de perguntas e respostas que “Silverlight não é uma estratégia cross-platform, é uma estratégia para Windows Phone” — a equipe do Silverlight não havia sido avisada com antecedência, e os desenvolvedores que haviam investido apps LOB em Silverlight também só descobriram ali, na sessão de Q&A
- O fim do Silverlight não foi um fracasso técnico, mas o resultado de uma mudança na estratégia de negócios, estabelecendo o padrão em que os desenvolvedores são sempre os últimos a serem informados
Metro e a guerra entre duas equipes (2012)
- Em resposta às 200 milhões de unidades vendidas do iPhone pela Apple e à invasão do iPad sobre o mercado de PCs, a Microsoft lançou o Windows 8 e o Metro, mas o WinRT foi deliberadamente projetado não como runtime baseado em .NET, e sim como runtime nativo em C++ — um reflexo direto da antipatia da equipe do Windows em relação ao .NET
- Na //Build 2012, os desenvolvedores receberam ao mesmo tempo mensagens contraditórias: “o futuro é WinRT, HTML+JS é cidadão de primeira classe, .NET continua funcionando, C++ voltou, também é possível escrever apps Metro, e o código WPF continua rodando”
- Desenvolvedores corporativos viram o sandbox do UWP, os requisitos de distribuição pela Store e a ausência de APIs Win32, e abandonaram a proposta imediatamente — “a app store para tablets nunca se concretizou”
A confusão de UWP e WinUI (2015–presente)
- O UWP (Universal Windows Platform) do Windows 10 trazia a visão de “escreva uma vez, execute em todo lugar” para PC, telefone, Xbox e HoloLens, mas com o declínio do Windows Phone e sem que os próprios apps principais da Microsoft (Office, Visual Studio e shell) usassem UWP, o sinal ficou claro
- A resposta oficial degringolou para “depende” — UWP, manutenção do WPF, XAML Islands, espera pelo WinUI 3, coexistência com WinUI 2, lançamento do Project Reunion e depois renomeação para Windows App SDK, ampliando a confusão
- Project Reunion / WinUI 3 é um avanço técnico, mas sua própria existência é produto de um problema organizacional em que os controles do UWP estavam acoplados ao OS e não pertenciam à equipe do .NET nem à equipe de ferramentas de desenvolvimento
- Em 2024, a retrospectiva de um desenvolvedor resumiu: “UAP, UWP, substituição de C++/CX por C++/WinRT (sem suporte de ferramentas), XAML Islands, XAML Direct, reinício com Project Reunion, reinício com WinAppSDK, transição confusa entre WinUI 2.0 e 3.0… 14 anos, 14 pivôs”
Um zoológico sem tratadores: a lista atual de tecnologias de GUI no Windows
Frameworks nativos da Microsoft:
- Win32 (1985) — ainda em uso, e o livro de Petzold continua válido
- MFC (1992) — em modo de manutenção, ainda presente em enterprise e CAD
- WinForms (2002) — “utilizável, mas não recomendado”, ainda o caminho mais rápido para formulários de entrada de dados
- WPF (2006) — XAML, renderização via DirectX, open source, sem novo investimento da Microsoft
- WinUI 3 / Windows App SDK (2021) — a resposta “moderna” oficial, com roadmap incerto
- MAUI (2022) — sucessor cross-platform do Xamarin.Forms, a aposta atual da equipe do .NET
Híbridos web da Microsoft:
- Blazor Hybrid — componentes .NET Razor dentro de WebView nativo
- WebView2 — Chromium embutido em apps Win32/WinForms/WPF
Terceiros:
- Electron — Chromium + Node.js, adotado por VS Code, Slack e Discord, hoje a tecnologia de GUI desktop mais amplamente distribuída no Windows, mas sem relação com a Microsoft
- Flutter (Google), Tauri (baseado em Rust), Qt (C++/Python/JS), React Native for Windows (patrocinado pela Microsoft, mas baseado em tecnologia do Facebook)
- Avalonia — sucessor espiritual open source do WPF, adotado por desenvolvedores da JetBrains, GitHub, Unity e outros que não quiseram esperar a Microsoft
- Uno Platform — mais comprometido com o WinUI do que a própria Microsoft
- Delphi/RAD Studio, Java Swing/JavaFX — ainda sobrevivem em mercados verticais e no enterprise
→ 17 abordagens, 5 linguagens de programação, 3 filosofias de renderização — isso não é uma “plataforma”
Diagnóstico central
- Toda iniciativa fracassada de GUI converge para uma de três causas: política entre equipes (Windows vs. .NET), apostas prematuras em plataforma guiadas por anúncios de conferência (Metro, UWP) e mudanças na estratégia de negócios sem aviso prévio aos desenvolvedores (Silverlight)
- A tecnologia em si muitas vezes era boa — WPF era bom, Silverlight era bom, XAML era bom — o fracasso organizacional se tornou o fracasso do produto
- Sem uma Plausible Theory of Success que cubra todo o ciclo de vida de “adoção-investimento-manutenção-migração”, não existe estratégia, apenas keynote de conferência
- Charles Petzold revisou Programming Windows até a 6ª edição para acompanhar as novidades anunciadas pela Microsoft, mas parou de escrever após a 6ª edição, que tratava do WinRT (Windows 8)
2 comentários
No fim, tudo volta para Win32?!!
Comentários do Hacker News
O problema fundamental é que a Microsoft tenta resolver a consistência da GUI apenas na camada de framework
Continua lançando novos frameworks como WinForms, WPF, UWP e WinUI, e no fim acaba abandonando todos
A Apple trata o próprio sistema de design como produto e deixa os frameworks invisíveis, enquanto a Microsoft faz o oposto toda vez
Quer dar alguns exemplos do lado da Apple?
Hoje em dia o WPF está imitando a skin do WinUI, então pelo menos a Microsoft está tentando
Continua sendo um dos caminhos oficiais até na stack moderna do .NET
WinForms ainda é atraente
Graças ao WebView2, ficou fácil desenvolver apps híbridos, e embora dê para ir de web pura, a sensação do chrome nativo é melhor
Como todos os clientes usam Windows, não há motivo para brigar com isso
Ultimamente estou criando um assistente de IA com .NET10 + WinForms + WebView2
Nem quero imaginar ficar retrabalhando repetidamente uma UI de histórico de conversa em WinForms puro
Não concordo com a ideia de que “WPF era bom”
No hardware comum do fim dos anos 2000, apps em WPF eram lentos
Por exemplo, o Logos Bible Software era só um app de texto, mas exigia desempenho gráfico, então engasgava em notebooks antigos
Depois descobri que o Logos 4 era baseado em WPF, e havia muitas reclamações parecidas no fórum
No fim, reimplementei a maior parte do código em Direct3D/Direct2D
A arquitetura do WPF em si era o problema
Disseram que foi por texto borrado e problemas de desempenho
Texto relacionado: edandersen.com / Reddit
Artigo relacionado: Ars Technica
No fim, a discussão sobre desempenho se repete em toda era
A Apple também está passando por problemas parecidos ao migrar de AppKit/UIKit para SwiftUI
Quando o ChatGPT explodiu pela primeira vez, foi uma ideia genial o Bing integrar uma versão com acesso à web
Mas a Microsoft não implementou detalhes como compressão de contexto, então as conversas eram bloqueadas rapidamente
Já OpenAI, Perplexity e outras fizeram isso direito, e hoje isso virou padrão
Se a Microsoft tivesse executado melhor naquela época, talvez pudesse ter substituído o Google
No fim, o problema foi a falta de acabamento em UI/UX, e acho que isso vem da ausência de consistência na cultura organizacional
Eu achava irritante a Apple impedir o empacotamento de bibliotecas de UI, mas é verdade que isso ajudou a manter a consistência da UI
A maioria dos usuários nem percebe
Dizem que um usuário vive colando a mesma história de um jantar com um executivo da Microsoft, e a mensagem é que a Microsoft está 100% focada no enterprise
Mas, na prática, até as empresas estão indo embora por causa da queda de qualidade do Windows e do Azure
Nossa empresa também foi prejudicada por problemas no SLA do Azure, e não recebeu compensação
Por isso estamos reduzindo a dependência de Active Directory e Windows
No fim, não existe mercado corporativo sem usuários
Depois do Win32, a Microsoft nunca conseguiu seguir na mesma direção por mais de dois anos
O WinRT era razoável, mas quando Nadella chegou e mudou o foco para Azure, abandonou a plataforma Windows
Ao passar de Windows → Office → Azure, sua identidade ficou difusa
Office existe tanto na web quanto no desktop, e ainda há hardware e loja
A visão de Satya Nadella não está sendo comunicada com clareza
A loja era péssima e não passava de um projeto para promoção interna
O problema é a Microsoft continuar lançando novos frameworks de GUI, mas ainda assim apps Win32 continuam podendo ser escritos
A Microsoft já adotou uma direção centrada na web há muito tempo, e também contribuiu para avanços em tecnologias como AJAX, Flexbox e Grid
Eu desenvolvo principalmente sistemas multiplataforma baseados em web, Java e Python
Não há motivo para criar GUI só para Windows
Apps web são mais flexíveis e mais acessíveis
A web roda em qualquer lugar, e com o PWABuilder também dá para distribuir em app stores
Participo desse projeto, e é possível criar apps rápidos e leves sem Electron
Pela documentação do Active Desktop, dá para ver como isso era bastante experimental na época
A web continua sendo um quebra-galho; a experiência realmente boa vem do nativo
Por volta de 2007, migrei de Delphi para WPF, mas em 2010 abandonei completamente o Windows
A política interna da Microsoft e o abandono frequente de tecnologias eram demais
Como era a época em que Rails estava em alta, foi fácil trocar
Talvez seja síndrome de Estocolmo, mas como até o Visual Studio ainda é baseado em WPF, não me preocupo muito
De certa forma, antecipou os problemas que vemos hoje nas big techs
Steven Sinofsky publicou recentemente um texto sobre esse mesmo tema
link do x.com
Na época do WinRT ele estava na DevDiv, mas o time do Windows não entendia as necessidades dos desenvolvedores
Havia até um protótipo de Python/WinRT, mas foi descartado porque “os desenvolvedores só querem JS”
Também forçaram o estilo Metro e mudaram os menus do Visual Studio todos para maiúsculas
O Windows RT ainda rompeu a compatibilidade, quase não tinha apps e acabou fracassando
Inclusive, algumas das alegações técnicas do Sinofsky estão erradas (.NET 3.0 vinha incluído no Vista)
O xcancel.com ainda não oferece esse recurso
A resposta é simples — Qt
Não é brincadeira: se você não vai usar Electron, Qt é a alternativa de verdade
Isso é o negócio central da Qt, então ela não muda de direção o tempo todo