- 1980'lerin sonlarına kadar Windows uygulama geliştirme, Win16/Win32 API merkezli tek bir model etrafında netti; ancak sonraki onlarca yılda tutarsız platform geçişleri tekrar tekrar yaşandı
- Windows GUI stratejisinin çöküşü, belirli bir teknolojinin başarısızlığından değil; ekipler arası siyaset, geliştirici konferansı odaklı duyuru kültürü ve önceden haber verilmeyen strateji değişimleri olmak üzere üç örgütsel nedenden kaynaklandı
- 1988'de Charles Petzold'un Programming Windows kitabı, Win32 adlı tek bir API ve tek bir zihinsel model ile "Windows uygulaması nasıl yapılır" sorusuna net bir yanıt veriyordu; ancak sonraki 30 yılda Microsoft bu netliği yeniden kazanamadı
- MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 ve MAUI'ye kadar uzanan süreçte onlarca yıla yayılan GUI framework karmaşası sürdü; başarısız olan her girişimde teknik kusurlardan çok kurum içi karar alma başarısızlıkları temel neden oldu
- Bugün Windows'ta fiilen kullanılan GUI teknolojilerinin sayısı 17'nin üzerinde ve bunların içinde en yaygın dağıtılan masaüstü GUI teknolojisi olan Electron, Microsoft değil dışarıdan bir ekip tarafından geliştirildi
- "Bir platform, 'UI'ı nasıl oluşturmalıyım?' sorusuna 10 saniye içinde yanıt veremiyorsa, o platform geliştiriciyi başarısızlığa uğratmıştır" şeklindeki temel teşhis, 2026 itibarıyla Microsoft için hâlâ geçerli
Tutarlı GUI stratejisi kaybolduktan sonraki Microsoft
- 30 yılı aşkın süredir Windows GUI stratejisindeki karmaşa devam ediyor ve “yeni bir Windows masaüstü uygulaması geliştirirken hangi framework kullanılmalı?” sorusuna net bir yanıt bulunmuyor
- 1988'de geliştiricilerin uygulamalarını tek bir yöntemle yazabilmesini sağlayan Win16/Win32 API adlı tek bir model vardı
- Sonraki on yıllarda Microsoft, iç siyaset, demo odaklı karar alma ve iş stratejisi değişimleri nedeniyle tutarlı bir platformu koruyamadı
- Sonuç olarak Win32'den MAUI'ye kadar 17 GUI teknolojisi bir arada varlığını sürdürüyor ve geliştiriciler stratejisi olmayan bir platform içinde kafa karışıklığı yaşıyor
- Temel neden teknik başarısızlık değil, örgütsel başarısızlık
Petzold dönemi: son kez netliğin olduğu zaman
- 1988'de Charles Petzold'un Programming Windows (852 sayfa) kitabı, Win16 API'yi C ile ele alan tek yetkin yanıt niteliğindeydi ve bu aynı zamanda Windows geliştirme stratejisinin kendisiydi
- Win32 daha büyük ölçekli hâle gelse de mesaj döngüsü, window procedure ve GDI'dan oluşan tek bir zihinsel modeli korudu; Petzold bunu açıklıyor, geliştiriciler de öğrenip hemen kullanabiliyordu
- "Tek işletim sistemi, tek API, tek dil, tek kitap" — bu netlik, platforma duyulan güvenin işaretiydi
Nesne yönelimli dalga (1992–2000): karmaşıklığın başlangıcı
- 1992'de MFC, Win32'yi C++ ile sarmaladı; ancak ardından OLE, COM ve ActiveX geldi ve GUI framework'leri olmaktan çok bileşen mimarileri olarak Windows geliştirme alanının geneline yayıldı
- Microsoft, tutarlı bir hikâye sunmak yerine yalnızca teknolojik primitive'ler sağladı ve geliştiricilerin bunları kendilerinin birleştirmesini bekledi; bunun nedeni, konferans keynote odaklı duyuru kültürünün geliştirici başarısından çok yöneticiler üzerinde etki bırakmayı öncelemesiydi
PDC 2003 Longhorn: vizyonun kendi kendini yutması
- 2003 PDC'de tanıtılan Longhorn, WinFS (ilişkisel dosya sistemi), Indigo (birleşik iletişim), Avalon (GPU hızlandırmalı XAML tabanlı UI) olmak üzere üç sütun üzerine kurulu ikna edici bir vizyondu
- Ocak 2004'te Jim Allchin'in kurum içi notu bunu "domuz (a pig)" olarak niteledi ve aynı yılın ağustosunda tam bir geliştirme sıfırlaması ilan edildi — Server 2003 kod tabanına geri dönüldü
- Sıfırlamadan sonra liderlik, "Windows içinde managed code yasak, tüm yeni kod C++ olacak" talimatını verdi; WPF Vista ile yayımlandı ama shell'in kendisi WPF kullanmadı
- Bu karar, Windows ekibi ile .NET ekibi arasında 13 yıl süren kurum içi bir iç savaş başlattı; sonunda WPF'nin sahipsiz kalmasına, Silverlight'ın terk edilmesine ve UWP'nin başarısız olmasına yol açtı
Silverlight: tekrar edecek modelin yerleşmesi (2007–2010)
- WPF 2006 sonunda çıktı; ancak 2007'de Silverlight, Flash'a karşı geliştirilen bir tarayıcı eklentisi olarak ortaya çıktı ve geliştirme yatırımları bölündü
- 2010 MIX konferansında bir Microsoft yöneticisi, Soru-Cevap sırasında "Silverlight çapraz platform stratejisi değil, Windows Phone stratejisidir" dedi — Silverlight ekibine önceden haber verilmemişti ve LOB uygulamaları için Silverlight'a yatırım yapan geliştiriciler de bunu ilk kez konferansın Soru-Cevap bölümünde öğrendi
- Silverlight'ın sonu teknik başarısızlıktan değil, iş stratejisindeki değişimden kaynaklandı; geliştiricilere her zaman en son haber verilen yapı da bu dönemde yerleşti
Metro ve iki ekibin savaşı (2012)
- Apple'ın 200 milyon iPhone satması ve iPad'in PC alanını daraltmasına karşılık olarak Windows 8 ve Metro çıkarıldı; ancak WinRT, kasıtlı olarak .NET tabanlı değil, native C++ runtime olarak tasarlandı — bu, Windows ekibinin .NET'e yönelik tepkisinin doğrudan yansımasıydı
- //Build 2012'de geliştiriciler aynı anda şu çelişkili mesajları aldı: "gelecek WinRT", "HTML+JS birinci sınıf vatandaş", ".NET hâlâ çalışıyor", "C++ geri döndü", "Metro uygulamaları da yazabilirsiniz", "WPF kodu da hâlâ çalışır"
- Kurumsal geliştiriciler, UWP'nin sandbox yapısını, Store dağıtım gereksinimlerini ve eksik Win32 API'lerini görünce hemen uzaklaştı — "tablet app store" vizyonu hiçbir zaman gerçekleşmedi
UWP ve WinUI karmaşası (2015–günümüz)
- Windows 10'un UWP (Universal Windows Platform) yaklaşımı, PC, telefon, Xbox ve HoloLens'i kapsayan "bir kez yaz, her yerde çalıştır" vizyonuydu; ancak Windows Phone'un gerilemesiyle birlikte Microsoft'un kendi ana uygulamaları (Office, Visual Studio, shell) UWP kullanmayınca sinyal netleşti
- Resmî yanıt "duruma göre değişir (it depends)" seviyesine düştü — UWP, WPF'yi koruma, XAML Islands, WinUI 3'ü bekleme, WinUI 2 ile birlikte var olma, Project Reunion'ın çıkışı ve ardından Windows App SDK olarak yeniden adlandırılması karmaşayı daha da artırdı
- Project Reunion / WinUI 3, teknik açıdan ilerleme olsa da varlığının kendisi, UWP kontrollerinin işletim sistemine bağlı olması ve .NET ekibi ile geliştirici araçları ekibinin bunlara sahip olamaması gibi örgütsel sorunların ürünüdür
- 2024'te bir geliştiricinin değerlendirmesi: "UAP, UWP, C++/CX'in C++/WinRT ile değiştirilmesi (araç desteği olmadan), XAML Islands, XAML Direct, Project Reunion, WinAppSDK yeniden başlatması, WinUI 2.0 ile 3.0 arasındaki kafa karıştırıcı geçiş… 14 yılda 14 pivot"
Bakımsız bir hayvanat bahçesi: bugünkü Windows GUI teknolojileri listesi
Microsoft native framework'leri:
- Win32 (1985) — hâlâ kullanımda, Petzold'un kitabı hâlâ geçerli
- MFC (1992) — bakım modunda, kurumsal ve CAD alanlarında yaşamaya devam ediyor
- WinForms (2002) — "kullanılabilir ama önerilmez", veri giriş formları için hâlâ en hızlı seçenek
- WPF (2006) — XAML, DirectX rendering, açık kaynak, Microsoft'tan yeni yatırım yok
- WinUI 3 / Windows App SDK (2021) — resmî "modern" yanıt, roadmap belirsiz
- MAUI (2022) — Xamarin.Forms'un çapraz platform halefi, .NET ekibinin mevcut tercihi
Microsoft web hibritleri:
- Blazor Hybrid — native WebView içinde .NET Razor bileşenleri
- WebView2 — Win32/WinForms/WPF uygulamalarına gömülü Chromium
Üçüncü taraf:
- Electron — Chromium + Node.js, VS Code, Slack ve Discord tarafından kullanılıyor; bugün Windows'ta en yaygın dağıtılan masaüstü GUI teknolojisi ama Microsoft'la ilgisi yok
- Flutter (Google), Tauri (Rust tabanlı), Qt (C++/Python/JS), React Native for Windows (Microsoft destekli ama Facebook teknolojisi tabanlı)
- Avalonia — WPF'nin açık kaynaklı manevi halefi; JetBrains, GitHub, Unity ve Microsoft'u beklemeyen geliştiriciler tarafından benimsendi
- Uno Platform — Microsoft'tan daha fazla WinUI'ye adanmış durumda
- Delphi/RAD Studio, Java Swing/JavaFX — dikey pazarlar ve kurumsal alanda hâlâ hayatta
→ 17 farklı yaklaşım, 5 programlama dili, 3 rendering felsefesi — bu bir "platform" değil
Temel teşhis
- Başarısız olan tüm GUI girişimleri üç nedenden birine bağlanıyor: ekipler arası siyaset (Windows vs. .NET), konferans duyuruları merkezli erken platform bahisleri (Metro, UWP), geliştiricilere önceden haber verilmeden yapılan iş stratejisi değişimleri (Silverlight)
- Teknolojilerin kendisi çoğu zaman iyiydi — WPF iyiydi, Silverlight iyiydi, XAML iyiydi — örgütsel başarısızlık doğrudan ürün başarısızlığına dönüştü
- "Benimseme-yatırım-bakım-migrasyon" yaşam döngüsünün tamamını kapsayan Plausible Theory of Success olmadan ortada bir strateji değil, sadece konferans keynote'u vardır
- Charles Petzold, Microsoft'un duyurduğu yenilikleri takip edebilmek için Programming Windows kitabını 6. baskıya kadar güncelledi; ancak WinRT'yi (Windows 8) ele alan 6. baskıdan sonra yazmayı bıraktı
2 yorum
Sonunda yine Win32 mi?!!
Hacker News yorumları
Microsoft'un GUI tutarlılığını sadece framework katmanında çözmeye çalışması temel sorun
WinForms, WPF, UWP, WinUI gibi sürekli yeni framework'ler çıkarıp sonunda terk etti
Apple, tasarım sisteminin kendisini bir ürün olarak görüp framework'leri görünmez kılarken Microsoft her seferinde bunun tersini yaptı
Apple tarafındaki örnekleri de anlatır mısın?
Bugünlerde WPF, WinUI skin'ini taklit ediyor; yani Microsoft yine de çabalıyor
En yeni .NET stack'inde bile hâlâ resmi yollardan biri olarak duruyor
WinForms hâlâ cazip
WebView2 sayesinde hibrit uygulama geliştirmek kolaylaştı; tamamen web'e de gidilebilir ama native chrome hissi daha iyi
Tüm müşteriler Windows kullandığı için buna karşı çıkmıyorum
Son zamanlarda .NET10 + WinForms + WebView2 kombinasyonuyla bir yapay zeka asistanı geliştiriyorum
Sohbet geçmişi arayüzünü saf WinForms ile tekrar tekrar elden geçirmeyi düşünmek bile istemem
“WPF iyiydi” sözüne katılmıyorum
2000'lerin sonlarında sıradan donanımlarda WPF uygulamaları yavaştı
Örneğin Logos Bible Software, basit bir metin uygulaması olmasına rağmen grafik performansı istiyordu ve eski dizüstülerde takılıyordu
Sonradan Logos 4'ün WPF tabanlı olduğunu öğrendim; forum gönderisinde de aynı şikayetler çoktu
Sonunda kodun büyük kısmını Direct3D/Direct2D ile baştan yazdık
Sorun WPF mimarisinin kendisiydi
Sebebin bulanık metin ve performans sorunları olduğu söyleniyordu
İlgili yazılar: edandersen.com / Reddit
İlgili makale: Ars Technica
Sonuçta performans tartışmaları her dönemde tekrar ediyor
Apple da AppKit/UIKit'ten SwiftUI'a geçerken benzer sorunlar yaşıyor
ChatGPT ilk patladığında Bing'in web erişimi olan sürümü entegre etmesi dahiyane bir fikirdi
Ama Microsoft, bağlam sıkıştırma gibi uygulama ayrıntılarını yapmadığı için sohbetler hızla kilitlendi
Buna karşılık OpenAI, Perplexity ve diğerleri bunu iyi uyguladı; şimdi de standart oldu
Microsoft o dönemde bunu düzgün yapsaydı Google'ın yerini bile alabilirdi
Sonuçta sorun UI/UX'in yeterince olgun olmamasıydı ve bence bunun nedeni kurum kültüründe tutarlılık eksikliği
Apple'ın UI kütüphanelerini paketlemeyi engellemesi sinir bozucuydu ama bu sayede UI tutarlılığı korunduğu da bir gerçek
Kullanıcıların çoğu bunu umursamıyor
Bir kullanıcı sürekli Microsoft yöneticileriyle yediği bir akşam yemeği hikayesini kopyalayıp yapıştırıyormuş; oradaki mesaj da “Microsoft tamamen enterprise'a oynuyor” şeklinde
Ama gerçekte Windows ve Azure kalitesindeki düşüş yüzünden kurumlar da ayrılıyor
Bizim şirketimiz de Azure SLA sorunları yüzünden zarar gördü ve hiçbir telafi almadı
Bu yüzden Active Directory ve Windows bağımlılığımızı azaltıyoruz
Sonuçta kullanıcısı olmayan bir kurumsal pazar diye bir şey yok
Win32'den sonra Microsoft hiçbir şeyi 2 yıldan uzun süre tek bir yönde itmedi
WinRT fena değildi ama Nadella gelip odağı Azure'a çevirince Windows platformunu bıraktı
Windows → Office → Azure geçişiyle kimliği bulanıklaştı
Office hem web'de hem masaüstünde var; donanımı ve mağazası da var
Satya Nadella'nın vizyonu net biçimde aktarılmıyor
Store berbattı ve iç terfiler için yapılmış bir projeden fazlası değildi
Sorun, Microsoft'un sürekli yeni GUI framework'leri çıkarması ama yine de Win32 uygulamaları hâlâ yazılabiliyor
Microsoft uzun zamandır web merkezli bir yön çizdi ve AJAX, Flexbox, Grid gibi teknolojilerin gelişimine katkıda bulundu
Ben çoğunlukla web, Java ve Python tabanlı çapraz platform sistemler geliştiriyorum
Özellikle Windows'a özel bir GUI yapmam için bir sebep yok
Web uygulamaları daha esnek ve daha erişilebilir
Web her yerde çalışıyor; PWABuilder ile uygulama mağazalarına da dağıtım yapılabiliyor
Bu projede yer alıyorum ve Electron olmadan da hızlı, hafif uygulamalar yapılabiliyor
Active Desktop belgesine bakınca o dönem için epey deneysel olduğu görülüyor
Web sadece geçici bir çözüm; gerçekten iyi deneyim native tarafta çıkıyor
2007 civarında Delphi'den WPF'ye geçtim ama 2010'da tamamen Windows'u bıraktım
Microsoft içindeki politika ve teknolojilerin sık sık çöpe atılması fazlasıyla fazlaydı
Rails'in yükseldiği dönemdi, o yüzden geçiş yapmak kolay oldu
Stockholm sendromu olabilir ama Visual Studio da hâlâ WPF tabanlı olduğu için çok endişelenmiyorum
Bir bakıma bugünün büyük teknoloji şirketi sorunlarını önceden göstermiş oldu
Steven Sinofsky yakın zamanda aynı konuda bir yazı paylaştı
x.com bağlantısı
WinRT döneminde DevDiv'deydi ama Windows ekibi geliştiricilerin ihtiyaçlarını anlamıyordu
Python/WinRT prototipi bile vardı ama “geliştiriciler sadece JS istiyor” denilerek rafa kaldırıldı
Metro stilini dayatıp Visual Studio menülerini tamamen büyük harfe bile çevirdiler
Windows RT uyumluluğu da kırdığı için neredeyse hiç uygulama yoktu ve sonunda başarısız oldu
Hatta Sinofsky'nin bazı teknik iddiaları da yanlış (.NET 3.0, Vista'nın içinde geliyordu)
xcancel.com bunu henüz desteklemiyor
Cevap açık — Qt
Şaka yapmıyorum; Electron kullanmayacaksan gerçek alternatif Qt
Qt için bu iş ana iş kolu olduğu için yönünü sık sık değiştirmiyor