MicrosoftはPetzold以降、一貫したGUI戦略を持てなかった

 (jsnover.com)
8 ポイント 投稿者 GN⁺ 23 일 전 | 2件のコメント | WhatsAppで共有
  • 1980年代後半までは Win16/Win32 API を中心とした単一モデルにより、Windowsアプリ開発は明快だったが、その後の数十年間は 一貫性のないプラットフォーム移行 が繰り返された
  • Windows GUI戦略の崩壊 は特定技術の失敗ではなく、チーム間の政治、開発者カンファレンス中心の発表文化、事前予告のない戦略転換という3つの組織的要因に由来する
  • 1988年の Charles Petzold による Programming Windows は、Win32という単一API・単一メンタルモデルで「Windowsアプリをどう作るか」に明確な答えを示したが、その後30年間、Microsoftはこの明快さを取り戻せていない
  • MFC、OLE、COM、ActiveX、WPF、Silverlight、WinRT、UWP、WinUI 3、MAUIに至るまで、数十年にわたるGUIフレームワークの乱立 が続き、失敗した各イニシアチブでは技術的欠陥よりも組織内の意思決定の失敗が主要因として作用した
  • 現在のWindowsで実際に使われている GUI技術は17種類以上 あり、その中で最も広く配布されているデスクトップGUI技術である Electron は、Microsoftではなく外部によって作られたものだ
  • 「プラットフォームが『UIをどう作るべきか』という問いに10秒以内で答えられないなら、そのプラットフォームは開発者を裏切っている」 という中核的な診断は、2026年現在でもMicrosoftにそのまま当てはまる

一貫したGUI戦略を失った後のMicrosoft

  • 30年以上にわたり Windows GUI戦略の混乱 が続き、「新しいWindowsデスクトップアプリを作るならどのフレームワークを使うべきか」という問いに明確な答えがない
  • 1988年には Win16/Win32 API という単一モデルが存在し、開発者は1つのやり方でアプリを書けた
  • その後の数十年間、Microsoftは 社内政治、デモ中心の意思決定、ビジネス戦略の転換 によって一貫したプラットフォームを維持できなかった
  • 結果として、Win32からMAUIまで 17のGUI技術 が共存し、開発者は 戦略不在のプラットフォーム の中で混乱を強いられている
  • 根本原因は技術的失敗ではなく 組織的失敗 にある

Petzold時代: 最後に明快だった時期

  • 1988年の Charles Petzold による Programming Windows（852ページ）は、Win16 APIをCで扱うためのただ1つの権威ある答えであり、それ自体が Windows開発の戦略 だった
  • Win32でも規模は大きくなったが、メッセージループ、ウィンドウプロシージャ、GDIという 1つのメンタルモデル を維持しており、Petzoldがそれを説明し、開発者は学べばすぐ活用できた
  • 「OS1つ、API1つ、言語1つ、本1冊」— この明快さこそがプラットフォームの信頼のシグナルだった

オブジェクト指向ブーム（1992–2000）: 複雑化の始まり

  • 1992年に MFC がWin32をC++でラップしたが、その後 OLE、COM、ActiveX が登場し、GUIフレームワークではないコンポーネントアーキテクチャがWindows開発全体を侵食していった
  • Microsoftは一貫したストーリーの代わりに 技術プリミティブだけを提供 し、開発者自身に組み合わせさせたが、これはカンファレンスの基調講演中心の発表文化が、開発者の成功よりも役員への印象管理を優先していたためだ

PDC 2003 Longhorn: ビジョンが自らを飲み込む

  • 2003年のPDCで公開された Longhorn は、WinFS（リレーショナルファイルシステム）、Indigo（統合通信）、Avalon（GPUアクセラレーション対応のXAMLベースUI） の3本柱から成る説得力あるビジョンだった
  • 2004年1月、Jim Allchin の社内メモはこれを「豚（a pig）」と表現し、同年8月には完全な開発リセットを宣言 — Server 2003 のコードベースへ原点回帰した
  • リセット後、リーダーシップは「Windows内で managed code を禁止し、新規コードはすべてC++」という方針を打ち出し、WPFはVistaとともにリリースされたが、シェル自体はWPFを使わなかった
  • この決定により、Windowsチームと.NETチームの間で 13年に及ぶ組織内の内戦 が始まり、最終的にはWPFの孤児化、Silverlightの廃棄、UWPの失敗へとつながった

Silverlight: 繰り返されるパターンの確立（2007–2010）

  • WPFは2006年末にリリースされたが、2007年に Silverlight がFlash対抗のブラウザプラグインとして登場し、開発投資が分散した
  • 2010年のMIXカンファレンスで、Microsoft幹部がQ&A中に「Silverlightはクロスプラットフォーム戦略ではなくWindows Phone戦略だ」と発言 — Silverlightチームには事前通知がなく、LOBアプリをSilverlightに投資していた開発者もカンファレンスのQ&Aで初めて知ることになった
  • Silverlightの終焉は技術的失敗ではなく ビジネス戦略の転換 の結果であり、開発者には常に最後に通知されるという構図がこの時点で確立された

Metroと2つのチームの戦争（2012）

  • AppleによるiPhone 2億台販売、iPadのPC侵食への対抗としてWindows 8とMetroを投入したが、WinRTは意図的に.NETベースではないネイティブC++ランタイム として設計されており、これはWindowsチームの.NETへの反感が直接反映された結果だった
  • //Build 2012で開発者は、「未来はWinRT、HTML+JSは第一級市民、.NETも引き続き動く、C++も復帰、Metroアプリも書ける、WPFコードもまだ動く」という 矛盾したメッセージを同時に受け取った
  • エンタープライズ開発者はUWPのサンドボックス化、Store配布要件、欠落したWin32 APIを確認して即座に離脱 — 「タブレット向けアプリストア」は結局実現しなかった

UWPとWinUIの混乱（2015–現在）

  • Windows 10の UWP（Universal Windows Platform） は、PC、フォン、Xbox、HoloLensをまたぐ「一度書けばどこでも動く」というビジョンだったが、Windows Phoneの衰退とともに、Microsoft自身の主力アプリ（Office、Visual Studio、シェル）がUWPを使わなかったことでシグナルは明白になった
  • 公式の答えは「ケースバイケース（it depends）」へと堕し、UWP継続、WPF維持、XAML Islands、WinUI 3待ち、WinUI 2併存、Project Reunionの登場、Windows App SDKへの改名が続き、混乱は深まった
  • Project Reunion / WinUI 3 は技術的進展ではあるが、その存在自体が、UWPコントロールがOSに縛られ、.NETチームや開発ツールチームがそれを所有できなかったという組織的問題の産物でもある
  • 2024年のある開発者の回顧: 「UAP、UWP、C++/CX から C++/WinRT への置き換え（ツールサポートなし）、XAML Islands、XAML Direct、Project Reunion、WinAppSDKへの再始動、WinUI 2.0と3.0の間の混乱した移行… 14年で14回のピボット」

飼育員のいない動物園: 現在のWindows GUI技術一覧

Microsoftネイティブフレームワーク:

  • Win32 (1985) — いまなお使用され、Petzold本も依然として有効
  • MFC (1992) — メンテナンスモード、エンタープライズやCAD分野で残存
  • WinForms (2002) — 「使えるが推奨はしない」、データ入力フォームでは今も最速
  • WPF (2006) — XAML、DirectXレンダリング、オープンソース、Microsoftの新規投資なし
  • WinUI 3 / Windows App SDK (2021) — 公式の「モダン」な答え、ロードマップは不透明
  • MAUI (2022) — Xamarin.Forms のクロスプラットフォーム後継、.NETチームの現在の賭け

MicrosoftのWebハイブリッド:

  • Blazor Hybrid — ネイティブWebView内で動く .NET Razor コンポーネント
  • WebView2 — Win32/WinForms/WPFアプリに Chromium を組み込む

サードパーティ:

  • Electron — Chromium + Node.js、VS Code・Slack・Discordが採用、現在のWindowsで最も広く配布されているデスクトップGUI技術だが、Microsoftとは無関係
  • Flutter (Google), Tauri (Rustベース), Qt (C++/Python/JS), React Native for Windows (Microsoft支援だがFacebook技術ベース)
  • Avalonia — WPFのオープンソースな精神的後継であり、JetBrains・GitHub・Unityなど、Microsoftを待たなかった開発者たちが採用
  • Uno Platform — MicrosoftよりもWinUIに献身的
  • Delphi/RAD Studio, Java Swing/JavaFX — バーティカル市場やエンタープライズで今も生存

→ 17のアプローチ、5つのプログラミング言語、3つのレンダリング思想 — もはや「プラットフォーム」ではない

核心的な診断

  • 失敗したすべてのGUIイニシアチブは、3つの原因のいずれかに帰着する: チーム間政治（Windows vs. .NET）、カンファレンス発表中心の早すぎるプラットフォーム賭け（Metro、UWP）、開発者への事前通知なしのビジネス戦略転換（Silverlight）
  • 技術そのものはしばしば優れていた — WPFは優れていた、Silverlightは優れていた、XAMLは優れていた — 組織的失敗がそのまま製品の失敗になった
  • 「採用-投資-保守-移行」という全ライフサイクルを貫く Plausible Theory of Success なしでは、それは戦略ではなくカンファレンスの基調講演にすぎない
  • Charles Petzold は、Microsoftが発表する新しいものに追いつくため Programming Windows を第6版まで改訂したが、WinRT（Windows 8）を扱った第6版を最後に執筆をやめた

関連記事

2件のコメント

 
iolothebard 22 일 전

結局Win32?!!
 
GN⁺ 23 일 전
Hacker Newsの意見

  • MicrosoftがGUIの一貫性をフレームワーク層だけで解決しようとしているのが根本的な問題
    WinForms、WPF、UWP、WinUIなど、次々に新しいフレームワークを出しては結局捨てている
    Appleはデザインシステムそのものを製品として扱い、フレームワークは見えないようにしてきた一方で、Microsoftは毎回その逆をやっている

    • 70年代生まれで80年代からコンピュータに触ってきた立場として、この発言にはコーヒーを吹きそうになった
      Apple側の事例も聞かせてほしい
    • 40年前のWin32アプリにMetroデザイン、タッチスクリーン、ダークモードを一度に載せるのは不可能
      最近のWPFはWinUIスキンを真似していて、それでもMicrosoftが努力しているのはわかる
    • 同意する。ただしWinFormsはいまもサポート中
      最新の.NETスタックでも依然として公式ルートの1つに残っている
    • 「Appleが解決した」という話はTahoe以前に書かれたコメントのように見える
    • 洞察に富んだコメントだった

  • いまだにWinFormsには魅力がある
    WebView2のおかげでハイブリッドアプリ開発が簡単になり、完全なWebにも行けるが、ネイティブのクロームが与える感覚のほうが良い
    顧客は全員Windowsを使っているので、あえて逆らう必要がない
    最近は.NET10 + WinForms + WebView2の組み合わせでAIアシスタントを作っている
    純粋なWinFormsだけで会話履歴UIを何度も作り直すのは想像したくもない

  • 「WPFは良かった」という意見には同意しない
    2000年代後半の一般的なハードウェアではWPFアプリは遅かった
    たとえばLogos Bible Softwareは単純なテキストアプリなのにグラフィック性能を要求し、古いノートPCでは重かった
    後で調べたらLogos 4はWPFベースで、フォーラム投稿でも同じ不満が多かった

    • 2010〜2011年ごろに複雑なWPFアプリを作ったが、性能はHTML/JS/Blinkよりずっと悪かった
      結局、コードの大半をDirect3D/Direct2Dで書き直した
      WPFアーキテクチャ自体に問題があった
    • 2010年ごろ、EvernoteがWPFを捨てた事例があった
      理由はぼやけたテキストと性能問題だったと言われている
      関連記事: edandersen.com / Reddit
    • 問題はWPFではなく、MicrosoftがIntelの低性能ハードウェアを「十分だ」と認めたことのほうが大きい原因だ
      関連記事: Ars Technica
    • これはAppleのTahoe/iOS 26のように、効果を盛りすぎてやり過ぎた結果になった例にも見える
    • 昔はWinFormsが遅いと言われていたが、今ではElectronがその立場にいる
      結局、性能論争は時代ごとに繰り返される
      AppleもAppKit/UIKitからSwiftUIへ移る中で似た問題を経験している

  • ChatGPTが最初に爆発的に広がったとき、BingがWebアクセス可能なバージョンを統合したのは天才的なアイデアだった
    しかしMicrosoftはコンテキスト圧縮のような細かな実装を行わず、すぐに会話が打ち切られるようになった
    一方でOpenAIやPerplexityなどはそれをうまく実装し、いまでは標準になっている
    Microsoftがあの時きちんとやっていれば、Googleを置き換えられたかもしれない
    結局のところ問題はUI/UXの完成度不足であり、それは組織文化に一貫性がないことが原因だと思う
    AppleがUIライブラリの同梱を防いでいるのは窮屈だったが、そのおかげでUIの一貫性が保たれていたのも事実だ

    • AppleがUIライブラリを制限していても、FlutterやKMPのようにキャンバス描画すればよい
      ほとんどのユーザーは気にしない

  • あるユーザーがMicrosoft幹部との夕食話を繰り返しコピペしているが、その内容は「Microsoftはエンタープライズ全振り」というものだ
    だが実際にはWindowsとAzureの品質低下で企業も離れつつある
    うちの会社もAzureのSLA問題で被害を受けたが、補償はなかった
    そのためActive DirectoryやWindowsへの依存を減らしている

    • Microsoftが企業ばかり見て個々のユーザー体験を忘れたことが問題だ
      結局、ユーザーのいない企業市場など存在しない

  • Win32以降、Microsoftは2年以上一つの方向に押し進めたことがない
    WinRTは悪くなかったが、Nadellaが来てAzure中心へ転換し、Windowsプラットフォームを捨てた

    • いまではMicrosoftが依然としてプラットフォーム企業なのかさえ疑わしい
      Windows → Office → Azureと移る中でアイデンティティが曖昧になった
      OfficeはWebにもデスクトップにもあり、ハードウェアもストアも持っている
      Satya Nadellaのビジョンが明確に伝わってこない
    • WinRTは技術的にもいまひとつで、Microsoft Storeの強制方針のほうがさらに大きな失敗要因だった
      ストアはひどい出来で、社内昇進のためのプロジェクトにすぎなかった

  • Microsoftが新しいGUIフレームワークを出し続けるのは問題だが、それでもWin32アプリはいまでも書ける
    Microsoftはかなり前からWeb中心に舵を切っており、AJAX・Flexbox・Gridのような技術の発展にも貢献してきた
    私は主にWeb・Java・Pythonベースのクロスプラットフォームシステムを開発している
    わざわざWindows専用GUIを作る理由はない
    Webアプリのほうが柔軟でアクセシブルだ

    • なぜWindows専用アプリを作る必要があるのか疑問だ
      Webはどこでも動き、PWABuilderでアプリストア配布も可能だ
      私はこのプロジェクトに関わっており、Electronなしでも高速で軽量なアプリを作れる
    • Windowsは24H2以前までHTMLアプリをサポートしていた
      Active Desktop文書を見ると、当時としてはかなり実験的だった
    • しかしWebアプリのUXは依然としてネイティブアプリより劣る
      Webはあくまで間に合わせであり、本当に良い体験はネイティブから生まれる

  • 2007年ごろにDelphiからWPFへ移ったが、2010年には完全にWindowsを離れた
    Microsoft内部の政治と頻繁な技術の廃棄があまりにもひどかった
    Railsが盛り上がっていた時期だったので乗り換えやすかった

    • いまWindows GUIを使うならWPFを使い続ける
      Stockholm症候群かもしれないが、Visual StudioもいまだにWPFベースなので心配していない
    • Microsoftには優秀な人材が多かったが、リーダーシップとビジョンの欠如で壊れてしまった
      今日のビッグテックの問題を先取りして見せていたようなものだ
    • それでもVBはいまでも動くのだから、完全に捨てたわけではない

  • Steven Sinofskyが最近同じテーマで投稿していた
    x.comリンク

    • Sinofskyが.NETを批判しているのは笑える
      WinRT時代にDevDivにいたのに、Windowsチームは開発者のニーズを理解していなかった
      Python/WinRTのプロトタイプもあったが、「開発者はJSしか望んでいない」という理由で廃棄された
      Metroスタイルを押し付けて、Visual Studioのメニューをすべて大文字に変えたりもした
      Windows RTは互換性まで断ち切ったせいでアプリがほとんどなく、結局失敗した
      しかもSinofskyの技術的主張の一部は間違っている（.NET 3.0はVistaに含まれていた）
    • その投稿はこの記事への応答記事なので、上部にリンクを追加する予定だ
    • x.comを経由せずに読む方法があるのか尋ねる人もいた
      xcancel.comはまだその機能をサポートしていない

  • 答えは明白 — Qtだ
    冗談ではなく、Electronを使わないならQtが本当の代替手段だ
    Qtにとってこれは中核事業なので、方向性を頻繁に変えない