開発者向けWindows 8:夢の復活? (2/2)

翻訳者から:次の情報はすべて、Microsoftとは無関係の著者の推測に過ぎず、Windowsが直面している問題を理解するためだけにここに提示されていることを理解する必要があります。



前編



ああ、勇敢な新しい世界



Windowsの次のバージョンには、2つの実行可能環境が含まれます。新しいバージョンの.NET(現在4.5と指定されています)と、WinRTと呼ばれる従来のC ++環境(技術的な観点からはCOMまたはその派生物)です。 また、Windows 8には、Windows 7で導入されたDirect2DおよびDirectWrite APIに基づいた、ユーザーインターフェイスを開発するための新しい組み込みライブラリ-DirectUIがあります。明らかにJupiterと呼ばれる新しいバージョンのSilverlightは、DirectUIを使用して動作します。 WinRTとDirectUIは両方とも、組み込みのアクセスツールを介して.NETから直接利用できます。



WinRTは、Win32 APIが以前に示した多くの機能に最新のAPIを提供します。 大まかに言えば、WinRTは新しいWin32であり、「C」用に開発された古い25年前のWin32アーキテクチャとは対照的に、「最新の」C ++から使用するために設計され、.NETコンセプトに美しく適合します。 もちろん、Windows 8でWinRTがWin32を完全に置き換えることはまずありません。Win32は大きすぎて迅速なアップグレードができませんが、将来のバージョンでは非常によく起こる可能性があります。 WinRTの位置は、Redmondから「マージ」された新しいビルドごとに強化されます。



WinRTは、既存のWin32 APIの単なる改良版ではありません-Microsoftは、開発者が利用できる機能も拡張しています。 たとえば、バックグラウンドで残留操作を実行する簡単な方法を提供する非同期操作の包括的なサポートがあり、クリップボードAPIがより柔軟で使いやすくなります。



DirectUIは、現在のWPF / Silverlightテクノロジーのサブセットに基づいており、Win32にはなかった豊富なユーザーインターフェイスレイアウトを提供します。 C ++で記述されたプログラムはDirectUIを使用でき、.NET開発者が使用できるのと同じツールになります。



Jupiter-実際にはSilverlight 6-は、アプリケーションを構築するためのフル機能の柔軟なツールセットです。 DirectUIとJupiterがどのように関連するのかはまだ不明です。同じ機能を実行し、Silverlightレベルに達するまでDirectUIが開発される可能性があり、おそらくDirectUIはより複雑なフレームワークの基本機能のみを実装します。 Jupiterは、新しい形式のフルスクリーンのタッチ指向アプリケーションを作成することのみを目的としている場合もあります。



XAML、WPF、Silverlightなどのツールを使用したユーザーインターフェイス開発は、将来のMicrosoftの優先事項です。 この分野の重要性の確認は、今週初めに行われた会社の構造再編です。 以前はDevDivウィングの下に隠れていたXAML開発チームは、Windows用のXAML開発者はWinDivに、Windows Phone、Xbox、およびWindows Phone用のブラウザプラグインには3つの部分に分かれていました。 Visual StudioやExpression Blendなどの開発ツールに携わったスタッフの一部のみがDevDivに残りました。 Microsoftの内部書簡は、XAMLチームがWindows 8の開発を通じてWinDivと連携しており、現在の変更は両者の関係を正式なものにしたと説明しています。



統合された最新の統合Windows API



現在、Win32 / C ++と.NETが完全に異なるプラットフォームであり、それぞれが独自の機能を備えている場合、近い将来、それらは等しくなるはずです。 MicrosoftがWindowsカーネルに新しいAPIを追加すると、マネージコードから直接アクセスできるようになり、C ++が.NETよりも優れているという主な利点がなくなります。 一方、C ++で記述された既存のアプリケーションは、不要なジェスチャなしで新しいユーザーインターフェイスを使用できます。 これはMicrosoft自体にも当てはまります。2つのプラットフォームの方程式は、システムに付属する.NETアプリケーションへの扉を開きます。



たとえば、10年以内にインターフェイスが標準のWindowsコンポーネントを使用するOfficeのバージョンを見ることができます。



WPFがどのような運命を待っているのかはまだ明らかではありません。 WPFとSilverlightは同じ人々によって開発されていますが、市場はSilverlightをその兄よりもはるかによく認識しています。 WPFは、Silverlightができないことを実行できます。Windows8でその機能が使用されていない場合は残念です。WPFとSilverlightは非常に似ており、おそらくJupiterはそれらの機能を組み合わせることができます。



Microsoftエコシステムの観点から見ると、WPFの過小評価とSilverlightのプロモーションは正当化されます。 Silverlightは、Windows Phone用のアプリケーションの開発に使用されており、Xbox用のSilverlightバージョンも開発中であるという強力な証拠があります。 Windows、Windows Phone、およびXbox上のSilverlightの存在は、「3つの画面とクラウド」と呼ばれるマイクロソフトのイデオロギーを実装します。これは、コンピューター、エンターテイメントセンター、携帯電話でアプリケーションを使用する統一されたエクスペリエンスとエクスペリエンスを提供するように設計されています。



確かに、このイデオロギーがWindows 8でどのように機能するかについての信頼できる情報はまだありません。WindowsPhoneのアプリケーションの開発者は、iOSやAndroidを専門とする同僚とは異なり、製品をWindowsタブレットに簡単に移植できるかどうかを確信していません。 WindowsとWindows Phoneは両方ともSilverlightをサポートしますが、携帯電話の仕様には追加機能が必要であり、現時点ではパーソナルコンピューターには類似していません。



将来は怖くない



数週間前にWindows 8が発表された後、多くの人は、新しいシステムインターフェイス用のアプリケーションはHTML5とJavaScriptを使用してのみ開発されると感じていました。 公式のSilverlightフォーラムのいくつかのトピックには、数百の回答と数千万のビューがありました-フォーラムの他の部分が1か月で授与されたものよりも多く。 開発者は、新しいインターフェイス用のアプリケーションを開発したいが、HTML5とJavaScriptを使用したくない。



そして、彼らはする必要はありません。 そのようなアプリケーションをC ++で作成したいですか? 問題ありません。 C#とSilverlightを使用したいですか? 同様に、これらのテクノロジーは両方ともサポートされています。 過去のすべての開発経験を残す代わりに-これは多くの人がそのプレゼンテーションを見た後に感じた印象でした-Windows 8はタッチスクリーンおよびタブレット指向のアプリケーションを開発するためのC ++とC#の両方の第一級ツールを作ります



HTML5とJavaScriptの組み合わせについてもサポートされます。 ところで、マイクロソフトは既にHTAテクノロジ(HTMLアプリケーション)の形式でHTMLアプリケーションの汚れを試しています。 HTA実行可能ファイルは、HTML、JavaScript、CSS、およびその他のコンテンツで構成され、特別な信頼モードで実行されました。 このため、ローカルリソースへのアクセスの欠如など、通常のHTMLページの制限は、ファイルシステムを使用したり、ネットワークを操作したりできるHTAには影響しませんでした。 つまり、これらは、デスクトップアプリケーションの置き換えを妨げる多くの欠陥のないWebページでした。



新しいHTML5アプリケーションはHTAベースではありませんが、その原理は非常に似ています。 HTAと同様に、HTML5アプリケーションには、通常のWebページよりもオペレーティングシステムとやり取りするためのオプションが多くあります。そのため、Windows API関数を使用し、デスクトップアプリケーションにより似たインターフェースを使用できます。 理想的には、.NETおよび従来のプログラムと同等である必要があり、唯一の違いは、マークアップおよびプログラミング言語としてHTML5およびJavaScriptを使用することです。 結果は、Web開発者に馴染みのある開発方法であるはずですが、Webアプリケーションに固有の機能制限はありません。



Windows 8は開発者の悪夢ではありませんが、大きな前進です。C++またはC#を使用する開発者とWeb開発者にとってWindowsアプリケーションの開発を等しく便利にすることができるステップです。 .NETとクラシックコードの統合、完全なハードウェアアクセラレーション、最新のAPI、Windowsインターフェイスを構築するための主なソリューションとしてのAvalon-Longhornが何年も前に約束していたことは、Windows 8で実現できます。



神秘的な沈黙



このような背景に対して、Microsoftの完全な無音放送の説明はさらに困難です。 同社は、コミュニティが彼らの声明にどのように反応したかを知っていますが、これを本当の問題ではなく、ブロガーによって膨らまされた些細なことと考えています。 「9月のBUILD会議を待つ」以外のことを何も言わないという決定は、マイクロソフト内で最高レベルで繰り返し議論されましたが、それは変更されませんでした。



一週間半前に彼らの立場はわずかに割れたように思えますが、この割れは今日だけ大きくなっていると思います。 Silverlightフォーラムへの1,000万回の訪問は、ブロガーにとって大したことではありません。 このプラットフォームの将来の不確実性はブロガーによって膨らまされる些細なことではないため、Windows Phone開発者はすでにプラットフォームを変更できると言っています。



マイクロソフトが現在すべてのカードを公開したくないという事実は理解できます。 Windows 8はまだ完全とはほど遠いものであり、ビルド前に多くの変更が可能です。 しかし、開発者はすべてを伝えるように求めているのではなく、重要な詳細を知りたいだけです。 C ++または.NETを使用して、新しいインターフェイス用のアプリケーションを開発することは可能ですか? XAMLはサポートされますか? これら2つの質問すべてに答えることで、マイクロソフトは混乱した開発者を落ち着かせることができました。



ビルド後にシステムの開発方向が変わらない場合、これらの両方の質問に対する答えは肯定的であり、Windows用のアプリケーションの開発は、1993年の32ビットWindows APIの登場以来経験していない大きな飛躍をもたらします。 これはエキサイティングな展望ですが、マイクロソフトは何も得ていないため、重要な質問には答えられていません。



All Articles