Windowsが多くの人に使用されていること、そしてすべての人がさまざまなタスクを実行するためのシステムを必要としていることは明らかです：企業サーバーの作成からPOS端末へのインストールから家庭用コンピューターでの使用まで、これだけではありません。 多くの人々は、MicrosoftがWindowsを更新するとき、オペレーティングシステムの正しい動作を確保するために、多くの妥協の決定を下す必要があることを認識しています。 ただし、もう1つのタイプの妥協点があります。多くの人々は、自分自身を上級ユーザーや管理者と呼んでも、その存在を認識していません。 これは、開発者/プログラマーとマイクロソフト自体の競合です。
開発者は通常、ユーザー向けのアプリケーションを作成する人と呼ばれ、Microsoftはこれらのアプリケーションがその後動作するオペレーティングシステムを開発しています。 彼らの連絡先は、新しいOSで以前に作成されたアプリケーションの安定した動作を保証することです。 ユーザーは、Windows自体のためではなく、Windowsに必要な既存のアプリケーションのためにWindowsを使用します。 開発者は多くの場合、作業時間とリソースに制限があり、API / ABIが絶えず変化するため、プログラムの何かを絶えず変更する必要があるため、煩わしいだけです。 さらに悪いことに、APIがOSから完全に除外されると、開発者はアプリケーションをほぼ完全に書き直さざるを得なくなります。 ただし、Windowsの世界では、このようなことはオープンソースの世界よりもはるかに少ないことがわかりますが、この場合でも、このプラットフォームを開発する人々が単純に背を向けるリスクがあるため、非常にまれなイベントです。 さらに、開発者はソフトウェアプラットフォームを絶えず更新し、新しい機能を追加し、エラーを削除することを望んでいます。間違いなく、その作業とプログラミングの両方を簡素化することを目的としています。 多くのユーザーの考えに反して、ソフトウェアプラットフォーム開発者は顧客とユーザーを引き続きサポートし、既存の機能を維持しながら新しい機能を追加したいと考えています。 これはかなり難しいタスクですが、フレームワークまたはプラットフォームが陳腐化するとすぐに、いくつかの新しいタスクを実行できないため、更新せずに使用するのは非常に困難になる可能性があります。
しかし、非常に多くの松葉杖とアーキテクチャ上の問題がプラットフォームに蓄積するため、プラットフォームに根本的な変更を加えることが必要になる場合があり、その開発者は法外なコストでサポートされ改善されます。 Windows開発者は、win32 APIが何年も前に作成されて以来、これを非常によく知っています。 当初、win32 APIは16ビットでしたが、その後64ビットプラットフォームをサポートするように拡張されました。 多くの場所で、それはかなり面倒で非効率的で、多くの場合、単に非常に、非常に冗長であり、開発にC ++を使用することに重点が置かれているため、C指向のwin32 APIは年々陳腐化しています。 Microsoft Foundation Classesライブラリは、ダウンストリームのwin32プラットフォーム用にC ++のAPIを提供するためのMicrosoftの試みでしたが、冗長性の問題の犠牲になり、誰かが明示的なことをしようとした場合の柔軟性の欠如で有名になりました彼女はサポートされていません。 Windowsの開発者の中には、現在の状況に不満を抱き、どんなに苦痛があったとしても、この状況から抜け出す必要性について話した多くの人々がいました。 Microsoftはこれに.NET環境を使用することを決定し、開発者の作業を容易にするためにWinFormsプラットフォームを更新しました。 ただし、.NETプラットフォームはランタイム環境であり、広く普及していますが、ネイティブWindowsアプリケーションを作成する開発者による使用にはまだ適していません。 しばらくして、MicrosoftはWindows Template Libraryと呼ばれるライブラリをリリースしました。これは、Win32 APIの最も厄介な側面を抽象化する一方で、MFCよりもはるかに軽量で柔軟な設計になっています。 多くの人がWTLに夢中になり、これがWindowsで事実上の標準として適用されるべきプログラミングへのアプローチであることが明らかになりましたが、最終的にこの機会を奪う別の視点がありました。
Microsoftが遭遇した問題は、win32 APIの扱いにくく厄介なためだけではありません。 低レベルのシステムも非常に長い間設計されており、実際には現代の要件を満たしていません。 Windowsグラフィックエンジンは、グラフィックスのレンダリングのメインプロセッサが中央プロセッサであった時代に書き戻されました。 ただし、GPUは長年にわたってより強力になり、GPUとの対話ははるかに便利になりましたが、Windowsグラフィックエンジンは単にGPUを操作する方法を知りませんでした。 選択は明白でしたが、一見すると単純ではありませんでした。 マイクロソフトは完全に新しいグラフィックエンジンを開発し、その上に新しいAPIを作成できます。これにより、間違いなくプログラミングとシステムの使用がより便利になります。 同時に、既存のフレームワークやアプリケーションとの互換性を確実に維持する必要があります。そうしないと、ユーザーは新しいバージョンのWindowsを購入する意味がわかりません。 この方向への最初のステップはWindows Vistaでした。WindowsVistaは、多くのアプリケーションとの非互換性に苦しむことさえありますが、それは当然のことながら不当に多くの人が激しいリソースイーターとして覚えています。 ただし、Microsoftは、開発者が増え続けるGPUのパワーに簡単にアクセスできるような基盤を必要としていたため、これらの変更が必要でした。 特にDirect3Dを使用して2Dアプリケーションを作成しようとすると、開発者にDirect3Dを使用したアプリケーションの作成を強制することは、多くの冗長コードを記述する必要が生じるため、冗長になります。
Microsoftはまだ新しいAPIを作成する準備ができていませんが、代わりにWindows Presentation Foundation、Silverlight、およびXNAの開発者を非難しています。 .NET Frameworkのユーザーは、これらの3つのツールすべてが非常に優れていたため、喜んでいました。 WPFはアーキテクチャ設計の欠陥のために深刻なパフォーマンスの問題を抱えていましたが、Microsoftは基礎となるシステムを徐々に改善しました。 Silverlightは、企業のイントラネットアプリケーションで非常に人気があり、それによってIT業界全体にミニ産業が生まれました。 これらすべてが一緒になって、おそらくWindowsベースのサーバーの魅力を高めるのに役立ちました。これは、サーバー環境でLinuxを抑制するためにMicrosoftが常に達成したかったことです。 以前は、多くの企業がWindowsベースのサーバーを主にActive Directoryに使用していましたが、Windows ServerベースのWebホスティングをより真剣に考えるより多くの理由があります。 一方、XNAはかなり複雑で冗長なDirect3D APIから非常に優れたレベルの抽象化を提供するため、アプリケーションの開発者は過度の手間をかけずにGPUの強力な機能を使用できます。 マイクロソフトはまた、独立したゲーム開発者をXbox Liveアーケードサービスに引き付けることを目的としたいくつかの譲歩を提供しますが、ゲームをマーケットプレイスに掲載するには、開発者はまだ特権アカウントが必要です。 これはすべて、XNA開発者のコミュニティを作成するために行われました。開発者はその後、Microsoftが作成および管理するMicrosoftアプリケーションストアを埋めることができました。 これはMicrosoftがこれまでに犯した最大の間違いのようですが、それについては後ほど説明します。
繰り返しになりますが、これらの改善はすべて.NETアプリケーション開発者を対象としており、ネイティブアプリケーション開発者のフラストレーションとフラストレーションを引き起こしています。 彼らはまた、不必要な努力なしに、より強力な機器のすべての利点を使用できるようにしたいと考えていました。これは、グラフィックプロセッサの使用だけでなく、より多くのプロセッサコアでの作業にも適用されますが、既存のオプションはどれもツールとしてのシンプルさと開発者の使いやすさを提供しませんでした.NET開発者。 ただし、Windows 7のリリースと共に、MicrosoftはDirect2Dをリリースしました。Direct2Dは、GPUによって完全に実行されるが、GPU自体と直接対話する必要のないOSに新しい2Dグラフィックスレンダリング機能を追加した新しいシステムAPIです; さらに、Microsoftは、マルチスレッドアプリケーションを容易にするために設計された開発者ツールを提供しています。 Direct2Dの可能性は、ゲーム開発者を含む多くの人にとって明らかでした。特に将来的には機能が向上するだけであることを考慮してください。 Windows XPをVistaにリリースして以来、サードパーティの開発者が経験したすべてのフラストレーションの後、Vista自体から初めて、将来が有望に見え始めました。 そして、事態はかなり奇妙に変わりました。
多くの人は、iPad / iPhoneとAppStoreの組み合わせでAppleが非常に人気を博したときに起こったことを覚えています。 マイクロソフトの幹部は、おそらくこの人気とAppleの関連収益に気付き、この成功を繰り返したいと考えていました。 しかし、市場を征服する準備として、彼らはいくつか奇妙な決定を下しました。 まず、AppStoreまたは他のアプリケーションストアの成功は、主にそのアプリケーションを作成する開発者の数に依存することを常に念頭に置く必要があります。 GoogleとMicrosoftはこれを非常によく理解しており、これらの企業はどちらも、使いやすく強力で柔軟なAPIと優れたソフトウェアツールサポートを提供することで、開発者を引き付けようとしました。 マイクロソフトは、いつものように、開発ツールのサポートに強いため、Visual Studioを使用しなければならなかった人なら誰でもこれを確認します。 マイクロソフトは、XNAプラットフォームを電話用アプリケーションの開発に適したものにするために、ある程度の進歩を遂げました。 そして、Metro / Modern APIを一般に公開することで、Microsoftは実際に開発者コミュニティのほとんどの中指を示しました。
最大の損失はSilverlightとXNAプラットフォームであり、Microsoftは開発者がWindows 8の「モダン」APIを使用するために実際に犠牲にしました。ただし、ここでの問題は、Silverlightの範囲がModernの範囲と一致しないことです。 Silverlightは基本的にWebアプリケーションを実行するために設計されたブラウザープラグインであり、ModernはOSアプリケーション用に設計されています。 さらに、展開シナリオは一致しません。 Silverlightは主にWebサーバーでホストされ、最新のアプリケーションはMicrosoftのデジタルストアからのみダウンロードできます。 もちろん、企業の顧客だけでなく、アプリケーションの開発者も、この決定を喜んでいませんでした。 マイクロソフトは、たった1回の打撃で、WebサイトとしてのWindowsベースのサーバーの価値を下げるだけでなく、企業ユーザーからWindows 8にアップグレードしたいという欲求をほぼ完全に阻止しました。 これに関する最も奇妙なことは、Silverlight開発者は明らかに、デジタルストア用のアプリケーションを手に取り、書き始めることができる種類の人間ではないことです。 Silverlightの使用は、Modernのアプリケーション開発のフレームワークに適合しません。 このテーマに関するMicrosoftの立場（もちろん、単に苦情を無視することは別として）は、単にこれらの人々がHTML5を使用していることを示唆することでした。 繰り返しになりますが、これは決して賢い答えではありません。Silverlight開発者は、一般に受け入れられている意味でWebサイトを作成しませんが、ほとんどの場合、Webサーバーに展開されるビジネスアプリケーションのセットを作成します。 多くの場合、これらのビジネスアプリケーションは非常に複雑であり、開発者の作業を簡素化する多くのツールを提供するため、開発者はまさにSilverlightを選択しました。 さまざまな活動分野でのHTML5の進歩にもかかわらず、HTML5とAJAXは、Silverlightほどこれらの目的に適しておらず、それらを使用すると、必然的に開発時間が長くなり、開発者の生産性が低下します。 なぜこれがすべて必要なのかMicrosoftはまだ明確ではありません。 たぶん、これは単一のAPIを導入することで開発を統一する決定でしたが、オールインワンのパラダイムはこれまでソフトウェア開発で機能したことがなく、近い将来機能しないようです。
XNAコミュニティのメンバーは、まさにアプリケーションストアの使用に簡単に切り替えることができる人々ですが、Microsoftはさらに多くの損害を与えています。 XBLAでの独立したゲーム開発者の扱いは本当に非人道的でした。たとえば、Xbox Liveを実行している人々は、開発者コミュニティとの関係を損なうとしても、Microsoftの収益を最大化するためにできる限りのことをしているようです。 原則として、Microsoftのエンターテインメント部門は長年にわたって損失を被ってきたため、これは理にかなっているかもしれませんが、長期的には、XNAおよびMicrosoftエコシステム全体に対する人々の初期の熱意を深刻に弱めました。 そして、マイクロソフトはXNAを拒否し、再びModernを支持し、再び移行/移行の手順を提供しません。 また、たとえば、NETアプリケーションの開発者は、GPUを使用した作業への直接アクセスを突然失いました。 これは、.NET開発者が多くのすばらしい新しいおもちゃを最初に受け取ったときに、ネイティブ開発者が壊れたジャンクに満足することを余儀なくされていた以前の反復と比較して、逆の状況を作り出します。 ただし、ネイティブアプリケーションの開発者が.NETのプログラムの開発に切り替えることができない、または切り替えたくないことが多いように、.NETの開発者はネイティブアプリケーションの開発に切り替えることができない、または切り替えたくない。 サードパーティの開発者は、Microsoftから独自のバージョンの.NET環境を実装し、Monoと呼んだため、この新しい非対称性はMicrosoftをさらに脅かす可能性があります。 また、独立した開発者は、APIレベルでXNAと完全に互換性のあるフレームワークを作成するプロジェクトを発表しました。これにより、XNAコミュニティのメンバーはMicrosoftエコシステムの使用を完全に放棄できます。 さらに、ソニーは、C＃でアプリケーションを作成するために設計された独自のSDKをリリースしました。 1回の打撃で、Microsoftは実際に開発者コミュニティのかなりの部分を殺しました。それはまさに、デジタルアプリストア向けに開発する準備ができていた可能性が最も高い部分でした。
そして、ネイティブ開発者はどうですか？ その結果、特にwin32と比較した場合、比較的現代的で非常に強力なまったく新しいAPIが確実に得られました。 しかし、私たちの多くはまだ頭を悩ましています。 私たちの多くはコンピューター用のアプリケーションの開発者でしたが、オペレーティングシステムの柔軟性を単に享受していました。 そして、突然、Microsoftは新しいAPIで書かれたプログラムに制限を課し、彼らがこの新しいAPIを開発したのはデスクトップアプリケーションではなく、タブレットと電話であることが明らかになりました。 そして、私たちはそれらを地獄に連れて行きました。
マイクロソフトは戦略的な目標を設定しました。電話とタブレットのエコシステムに切り替えることです。 彼らは、この目標を達成するために、アプリケーションとそれらを作成する開発者が必要であることを明確に理解していました。 その結果、サードパーティの開発者向けのツールの作成に多大な努力が費やされました。 確かに、現時点では、使用したプラットフォームに対するさらなるサポートを拒否する決定と実際に示した無礼に満足していない、または設定により携帯電話やタブレット用のアプリケーションを書くことを余儀なくされたこれらの同じ開発者の大部分を失いました人為的な制限。 マイクロソフトは、彼らのエコシステムが十分な数の新しい開発者を引き付けることに賭けているようで、「高齢者」の避けられない不満に気付かないかもしれません。 彼らは多くを失いますか？ 多分そうではありません...一方、開発者コミュニティ全体の損失、たとえばXNAで行ったことは、長期的な戦略的結果をもたらす可能性があります。 これらは、高品質のアプリやゲームを作成できるため、Microsoftアプリストアを大成功に導く可能性のある人々でした。 彼らはMicrosoftが彼らをどのように扱ったかを長い間覚えているだろうし、もちろんMicrosoftが必要としている他の独立した開発者にそれについてささやくだろう。 マイクロソフトの株主がこのすべての結果を理解するのに十分賢明であるかどうかは、まったく異なる問題です。
結局のところ、Microsoftが実際にシステム全体を完全に再設計したという事実に帰着します。これは多くの開発者が望んでいたものです。 しかし、開発者がデスクトップアプリケーションを開発し続けることができるように、新しい高度なツールを開発者に提供するのではなく、デスクトップオペレーティングシステムを完全に放棄することに似ています。 これは開発者がそのように要求したものとはまったく異なり、現在マイクロソフトは状況を修正しようとしています。 唯一の問題は、Microsoftがアプリケーション開発者に必要なツールを十分に提供する準備ができているか、それとも開発者ストアにアプリケーションを投稿することに同意しないすべての人を簡単に拒否できるようにストアを開発する決心があるか、または彼らの店は「古典的な」コンピューターアプリケーションの販売に大成功するでしょう...しかし、マイクロソフトはゲームがそれほど多くないこと、普通のユーザーが使用するプログラムがあまりないことを理解していないようです。 彼らは日常業務でそれらを使用します。つまり、店舗の飽和点に到達するために必要なアプリケーションの数はそれほど多くありません。 さらに多くのアプリケーションは、あらゆるタスクに焦点が絞られているか特化されており、その要件はModern APIの制限と互換性がないか、アプリケーションストアのモデルにまったく適合しません。 これに基づいて、マイクロソフトは主にゲームに関心があると結論付けることができますが、すでに独立したゲーム開発者のコミュニティとの関係を台無しにしており、私が言ったように、長期的にMicrosoftに深刻な影響を与える可能性があり、とにかくストアを埋める必要があります。 また、通常のアプリケーションの開発者をあまり扱いませんでした。これらはまさに、Windowsをワークステーション、開発、および創造性のプラットフォームとして広く使用した人々です。 マイクロソフトの幹部が十分な柔軟性を発揮してこれを実現できるのか、それとも長期的に成功するプラットフォームを構築し、可能なすべてを破壊し、提供するのが魅力的な短期的な収益成長に専念できるのかを確認するのは確かに興味深いでしょうあなた自身のデジタルストアのモデル。
翻訳：© evilslon
UPD 「DOM Bill Built」のテーマ図を追加しました。