マイクロソフトのEngineering Windows 7 ブログ : Platform

グローバルマーケットに向けた Windows 7 のエンジニアリング

e7blog — Thu, 23 Jul 2009 13:32:34 GMT

Microsoft は長い間グローバルなソフトウェア会社であり続け、常に世界中のお客様をベースとした製品開発を心がけています。また、インターナショナルへの対応というのは開発がとても複雑な分野でもありますーおそらく、みなさんが思っているよりはるかに複雑であり、私たちもいつも学習し改善しようとしている分野です。グローバルなソフトウェアを構築することはチーム全員の責任です。また、グローバルな機能と特定のマーケットに特化した機能の両方を開発することに注力しているチームもありますーたとえば、フォントの処理や、東アジア言語用の入力システムなどです。もちろん、Windows を 100 近い言語にローカライズ (「翻訳」はあまり正確な表現ではありません) することに対しても、私たちは莫大な開発労力をつぎ込んでいます。Julie Bennett がグローバル開発およびローカライズのチームを代表し、同じチームの John McConnell と一緒にチーム全体と協調して、グローバル マーケット用の開発の概略を説明するためにこの投稿を書きました。--Steven

E7 ブログの読者の多くは、アメリカ以外の場所に住んでいたり、英語以外の言語を話していたりします。そこで、Windows 7 におけるインターナショナルおよび多言語の改良点について共有するのも役に立つのではないかと考えました。私たちの Windows 7 での目標は、世界中のユーザーのためになるワクワクするような機能や、すべてのユーザーが Windows は地域に密着していると感じるような機能を提供することです。Windows 7 がパフォーマンスや信頼性の基礎的なシナリオを向上することに重点を置いているように、私たちがサービスを提供しているすべての国のすべての言語ですばらしいカスタマーエクスペリエンスをもたらすことができるように、プロセスを改善しました。Windows 7 を世界中でできるだけ同時に提供しようとする試みもその 1 つです。このブログでは、Windows 7 が世界中ですばらしいリリースになると信じるに値する新機能と改善されたプロセスについて説明します。

インターナショナル機能

Windows 7 のインターナショナル機能は、NTFS ファイル名でサポートされる文字 (Unicode 5.1 と一致するようにアップグレードされました) といった低レベルの側面から、背景やテーマの選択 (地域と関連のある写真が入りました) といった高レベルの側面まで、システム全体に波及します。しかし、世界のたくさんの言語や文化を適切にサポートするのに本質的に重大な特定の機能があります。ここでは、そのいくつかについて見ていきたいと思います。

フォント

言語と書くことはどんな文化においても中心的存在であり、そのためフォントのサポートはインターナショナルユーザーのサポートに欠くことのできないものです。Windows 7 ではフォントの幅と品質の両方がかなり増えました。次の 50 のフォントを新しく追加しました。

上記の表のフォント名から推測されるように、新しいフォントの多くはラテン系ではない書体用です。実際、Windows 7 は、ラテン系書体より非ラテン系書体用のフォントの方が多い、初めての Windows です。大きな改善点の 1 つが、インドの言語に対するものです。Vista では 9 つのインド言語用フォントが入っていましたが、Windows 7 では40 以上のフォントを追加しました。Windows 7 には、インドの公式言語のそれぞれについて、複数のフォント (通常は、複数の太さ) が入っています。

Aparajita: 新しいデーヴァナーガリー フォントの標準、太字、斜体、および太字斜体

新しいフォント以外にも、多くの既存フォントも改良しました。たとえば、Consolas、Calibri、Cambria Bold、および Cambria Math に対して 2000 を超える字形 (グリフ) を追加しました。しかし、もっとも大規模な改善は、非ラテン系の書体に対してです。たとえば、Windows 7 は、アラビア語で一般的である Lam-Alef リガチャ (合字) (下の図を参照) と母音記号の配置の表示が大変よくなりました。

左: Vista での Lam-Alef リガチャ 右: Windows 7 での Lam-Alef リガチャ

フォントに対する変更は (明白な改善点であっても)、下位互換性の問題により、常に扱いにくいことです。たとえば、ある文字の幅や位置が変わると、既存のドキュメントのリフロー (再作成) が必要になるでしょうが、これは受け入れがたいことです。そのため、フォントを変更するときはいつも、変更に対して大規模な検証テストを実行し、フォントメトリックや他の表が変更されないか確認する必要があります。先に示した Lam-Alef の修正の場合、既存のアプリケーションの中には、古いフォント中のグリフの (文書化されていない) 順番に依存しているものがあることが判明しました。そのようなアプリケーションは、単にグリフを置き換えるだけでは壊れてしまうでしょう。そこで、フォントチームはインターナショナルアプリケーション互換性チームと緊密に働き、変更がフォント中のグリフの順番に影響を及ぼさないようにし、その結果下位互換性を提供できるようにしました。

[フォント] コントロール パネル

Windows 7 での非常にたくさんの新しくそして拡張されたフォントとともに、私たちはユーザーがもっと簡単にフォントを管理できるようにしたいと思いました。そこで、数年ぶりに、コントロールパネルの [フォント] の徹底的な見直しを行いました。

下記の最初の図は、[フォント] コントロールパネルを大アイコンで表示させたところです。最も顕著な違いは、フォントのアイコンがフォントの外観についてより多くの情報を伝えてくれることです。アイコンの内容は、フォントのグリフのレパートリーに関するヒントを与えてくれます。非ラテン語のフォントは、それがどうデザインされているか分かるように書体から代表的なグリフを表示します。微妙な変更点として、あるフォントのアイコンは薄くなっていますが、これはインストールされているが隠されていることを示しています。隠しフォントはデフォルトではリボンやフォントダイアログには表示されません。ユーザーは、[フォント] コントロールパネルで、日常的に使用するフォントを調整できます。まったく使用しないフォントを隠すことにより、アプリケーション内で適切なフォントを選択する動作を単純化できます。デフォルトでは、ユーザーがインストールしている入力ロケール (キーボードレイアウトと言語) で書ける言語をサポートしているフォントのみが表示されます。たとえば、英語とフランス語の入力ロケールをインストールしているユーザーは、ラテン語のフォントのみを見ることになりますし、一方で日本語入力方式をインストールしているユーザーは、日本語フォントだけを見ることになります。このデフォルト設定は、コントロールパネルでフォントを右クリックすることにより、変更することができます。隠しフォントはインストールされているので、隠しフォントを使用するような既存のアプリケーションもこれまでと同様に動作します。

大アイコン表示の [フォント] コントロール パネル

次の下の図は、[フォント] コントロールパネルを詳細表示させたものです。これにより、ユーザーはフォントについてこれまでよりも詳しい情報を得ることができます。たとえば、フォントをスタイルや表示/非表示、フォントの製作者で並び替えることができます。通常、フォントファイルにはフォントのデザイン言語の情報しか含まれていません (たとえば、日本語のフォントは、情報を日本語でしか持っていません)。Windows 7 では、すべての言語ですべてのフォントに対して機能するソリューションが必要でした。そこで、フォント自身からの情報をメタデータ (システム上のフォントについて情報を提供する XML ファイル) と組み合わせるハイブリッドなやり方を考え出しました。

詳細表示の [フォント] コントロール パネル

ローカル パック

Windows 7 では個人用設定の選択肢が増えました。新しいテーマ、背景、およびサウンドにより、Windows 7 を自身の個性にマッチさせるよう簡単にカスタマイズできます。私たちの好みは言語や地域によって影響を受けるという点を、Windows 7 はローカルパックの導入という形で反映しています。ローカルパックは、特定の地域用にカスタマイズされた Windows 7 の視覚テーマを提供します。視覚テーマには、その地域に関連する壁紙の画像や、カスタマイズされた Aero グラスの色、地域色の濃いサウンド設定が含まれます。Windows® Internet Explorer® のお気に入りや RSS フィードも、コンピューター上でローカルパックが有効になっていると更新されます。たとえば、フランスのローカルパックを追加して有効にすると、コントロールパネルの [個人設定] にフランスの市場用にカスタマイズされたテーマが追加され、ユーザーのプロファイルに役に立つフランス公共部門のウェブサイトへのリンクや RSS フィードが追加されます。

[個人設定] コントロール パネルのカスタマイズされたテーマ

ローカルパックの中身は、すぐに使えるシームレスな地域のエクスペリエンスを提供します。ローカルパック自体はユーザーの目には触れません。ユーザーは単に Windows の「ようこそ」でいつもどおり自分の場所を選ぶだけです。そうすると、設定に基づいて、適切な地域のコンテンツが表示されます。

他の国用のテーマを探しているユーザー、または他の分野に興味のあるユーザーは、コントロールパネルの [個人設定] の [オンラインで追加のテーマを取得] リンクからアクセスできる、Windows オンラインギャラリーで見つけることができます。

その他の機能

他の新機能には、5 つの新しいロケール (これにより、サポートされるロケール数の合計は 210 になりました)、12 の新しい入力ロケール、および中国語繁体字の改善された並び替えがあります。また、概して、システムのデータベースを Unicode 標準の最新バージョンである 5.1 にアップデートしました。開発者がよりよいグローバルアプリケーションを開発できるようにインターフェイスも改善しました。後述の [インターナショナルの適時性と品質] セクションで説明しますが、Extended Linguistic Services (ELS) はクールな新しい機能です。

おそらく、コアのインターナショナルの機能以外で最も重要な改善は、検索についで、より多くの言語を認識するようになりました。たとえば、Windows 7 のデスクトップ検索はロシア語の形態論 (単数、複数、時制、および格の決まり) を認識します。つまり、ロシア語のある特定の単語の検索は、これまでの完全一致の単語だけでなく、単語の一般的なバリエーションに対してもマッチさせ、検索結果が格段に向上します。

インターナショナル版リリースのタイミングと品質

前回のバージョンの Windows では、すべての言語の最終製品をすべての市場へ提供するのに数ヶ月かかりました。Windows 7 では、この時差をかなり短くするためにインターナショナル版への取り組み方を変え、世界中のユーザーができるだけ同時に Windows を楽しめるようにしました。この目標は、エンジニアとしてどのように作業を行うか、また、公開テスト期間中にパートナーや顧客とどのようにやりとりするかに対し、広範囲にわたって影響を及ぼしました。

私たちの取り組みを理解していただくために、まず 2 つの重要なコンセプトであるローカリゼーションとグローバリゼーションについて説明します。

ローカリゼーションは、ユーザーエクスペリエンスを他の言語に適応させるプロセスです。文字列の翻訳だけでなく、ダイアログのサイズを変更したり、ヘブライ語やアラビア語のように右から左へ書く言語のためにアイコンを逆にするといった作業があります。メニューの翻訳ミスのようなローカリゼーションのバグは、このプロセスで発生する欠陥です。

一方、グローバリゼーションとは、ユーザーインターフェイスが何語であろうと、すべての国で正しく動作する製品を作るプロセスのことです。グローバリゼーションのバグは、誤った言語で UI の要素を表示するような単純なものから、右から左への文字列の処理が正しく動作しないなど複雑なものまで多岐にわたります。グローバリゼーションのバグは、本質的にローカライゼーションのバグよりも深刻です。なぜなら、グローバリゼーションのバグは通常、多くのまたはすべての言語に影響を与え、技術的な設計を考え直さなければならないことがよくあるからです。過去の Windows では、グローバリゼーションのバグを修正することで、長いリリースの時差が必要になっていました。しかし Windows 7 では、グローバリゼーションのバグを、開発プロセスのできるだけ初期の段階で防ぎ、見つけ、修正するように取り組みました。

擬似ローカリゼーション

一般的なグローバリゼーションのバグを防ぐために、擬似ローカリゼーションビルドが作られました。擬似ローカリゼーションとは、人工言語でローカライズした製品を作るプロセスのことです。その言語は英語とそっくりですが、それぞれの文字は英語の文字に見た目が似た別の文字で書かれています。完全にマシンによって生成されることを除き、擬似ローカライズビルドはローカライズビルドを作るのとまったく同じ方法で作られます。英語しかわからないソフトウェア開発者でさえ擬似ローカライズのテキストは読めるので、開発サイクルの初期にグローバリゼーションの問題を発見する大変優れた方法となっています。Windows 7 のベータでは、いくつかの UI 要素はまだ擬似ローカライズの状態でしたが、この意味について面白い説が唱えられていました。このブログの投稿で謎が解けたかと思います J

擬似ローカライズ版 Windows 7のコントロール パネル

パイロット言語

ベータ版は私たちにとって常にワクワクするときです。なぜなら、みなさんから私たちの努力に対して本当に意見を聞くことができる最初のチャンスだからです。113 の国の人たちが Windows 7 Beta をダウンロードしたと聞いて、感激しました。このように規模が大きく、多様性のあるベータプログラムでは、フィードバックを集めて具体化するには、高度に拡張性のあるプロセスが必要です。Windows 7 では、新しい取り組みに大変張り切りました。

過去に、Windows のベータ版用のローカリゼーション言語は、実用的な理由が入り混じって選択されていました。このような場当たり的なアプローチはメリットもありましたが、重大なグローバリゼーションの欠陥が選ばれた言語では現れず、報告されなかったということがよくありました。Windows 7 Beta では、私たちの優先事項はグローバリゼーションのバグを見つけることであり、そのため、これまでの経験上、特定の種類の欠陥が見つかりやすい 4 つの言語 (プラス英語) に集中することにしました。

· ドイツ語 – とても長い単語があるため、ダイアログのサイズや配置の欠陥が他の言語より明らかになりやすいです。

· 日本語 – 何万もの文字、複数の非ラテン語の書体、入力方式エンジンの代替手段、特に複雑なつづりといった理由により、日本語は東アジア言語に影響する欠陥を見つけるにはうってつけです。

· アラビア語 – 右から左へ書き、前後関係によって形が変わるので (文字の形は隣接した文字による)、ドイツ語や日本語では実施できないテストで役立ちます。

· ヒンディー語 - Windows 95 と Windows 98 ではヒンディー語はサポートされておらず、この言語は完全に Unicode に依存しています。ヒンディー語をテストすると、古い (Unicode ではない) 欠陥を見つけるのに役立ちます。

ベータ期間中にこの 4 つの言語に集中することにより、多くの言語に影響を及ぼすグローバリゼーションのバグを見つけて修正できるチャンスを最大限に高めました。それに、実際の製品をリリースする前に、すべての言語のローカリゼーションを向上させるための時間も増えました。下記の図は、ベータで見つかった 2 つのバグですが、パイロット言語に注力したことの利点を示しています。

Windows 7 Beta 中に見つかったグローバリゼーションの欠陥

これらの言語を通じてグローバリゼーションのバグを見つけることに加え、OEM メーカーに対しても、彼らの製造プロセスにおいて言語に関するフィードバックを提供してくれるようお願いしています。多くの OEM メーカーは東アジアに拠点があるので、Windows 7 Beta を簡体字中国語、繁体字中国語、および韓国語にもローカライズしました。

RC の言語パック

先に説明したようなエンジニアリングプロセスの向上を主な理由として、Windows 7 RC では過去の Windows で実現したしたよりも多くの言語パックを提供することができました。Windows 7 RC の Ultimate バージョンを実行している方は、下記の 32 の言語パックを Windows Update からダウンロードできることにお気づきでしょう。

Windows Update にある 32 の Windows 7 RC 用言語パック

将来的には、Beta 版で利用可能な言語はすべて、RC版でも提供できるようにする予定です (たとえば、ヒンディー語は Windows 7 RC には入っていません) 。将来のバージョンではこの点を改善します。

世界中からのフィードバックを理解することについて

Windows 7 の Beta 版は 5 つの言語にローカライズされ、プラス数百の言語用にグローバル対応されているので、Beta 版のバグ報告も世界中のユーザーから受け取ります。Windows 7 の改善にはこのようなバグ報告が欠かせないので、製品の問題かどうか判断するために、バグ報告を読むのにかなりの時間をかけました。バグ報告は世界中のユーザーから非常に多くの言語で寄せられるので、単にフィードバックを理解するだけでなく、できるだけ迅速に対応できるような方法を模索しました。問題を早く理解すればするほど、フィードバックに対応できるチャンスが高まります。バグ報告はユーザーが話すあらゆる言語で寄せられるので、これは時に大変困難な課題です。

過去に、私たちは複数の言語によるバグ報告を手作業で処理していました。それは、個々のバグを確認し、原因となるコンポーネントの責任チームに適切にフォローしてもらえるようひとつひとつ手作業で翻訳するといったプロセスでしたが、とても時間がかかり、しかも Windows 7 Beta のように規模の大きく多様性に富んだプログラムでは、見積もりを間違いやすい方法でした。最悪のケースでは、最終製品に影響を及ぼすような価値のあるインターナショナルのフィードバックが見過ごされ、Service Pack や次期バージョンまで対応がなされない可能性もあります。

Windows 7 では、新しい拡張言語サービス (Extended Linguistic Services, ELS) の言語検出 API を使用することにより、報告されたユーザーからのバグの言語を自動的に検出できるようになりました。ELS は Windows 7 の新機能で、OS の高度な言語機能を活用したい開発者は誰でも利用可能です。Windows 7 から、開発者は Unicode テキストの言語やスクリプトの検出や、文字間でテキストをマップさせるような書き直しに ELS を使用できます。この Windows 7 のサービスおよび今後のリリースに追加する予定のさらなるサービスを使用するには、開発者は 1 つのシンプルで統合されたインターフェイスを学ぶだけです。100 以上の言語を検出する能力が Windows 7 のアプリケーション開発者に提供されますが、この機能をみなさんが世界中から送ってくださったベータフィードバックの優先度を判定して処理するのに適用することができました。ユーザーからのグローバルな問題に対する対応を向上するため、私たちは自身のインターナショナルの開発機能を使用したわけです。

言語を検出すると、続いてその結果のテキストを用いて、機械翻訳サポートを使用します。機械翻訳は、オンラインの Live Translator で利用可能です。これにより、テキストを英語に翻訳し、フィードバックの言わんとすることを理解します。そしてエンジニアは、特徴や機能性の分野を、私たちのフィードバックデータベースで検索します。ユーザーが報告するとすぐに、問題となりそうなインターナショナルアプリケーションのエクスペリエンスについて学べるので、インターナショナルアプリケーションの互換性の確認にも役立ちます。機械翻訳は完全な翻訳ではありませんが、どの問題がさらなる調査が必要そうかの判断には使えます。その結果、ユーザーの問題に対して耳を傾け対応することが、前回のリリースよりも格段に短い所要時間で実現できるようになりました。つまり、世界に Windows 7 をリリースしたとき、それはよりよい品質であるということです。

Windows 7 Beta の終了時までに、このプロセスを使用して、フィードバックツールを使って寄せられた 35,408 件の問題や意見を翻訳しました。

まとめ

グローバリゼーションとローカリゼーションの品質向上に対する取り組みの最終結果は、「すべての完全にローカライズされた言語版の Windows 7 は、10 月の最初のリリースから 2 週間以内にリリースされる」と言う発表に現れています。私たちは、ユーザーのみなさんが、このリリースの全体的な品質がこれまでで一番よいと思ってくださることを願っていますし、それを信じています!

2009 年 10 月にリリースされる Windows 7 の 36 言語

10 月にリリース予定の 36 言語に加え、追加の言語が、どのエディションの Windows 7 にもインストール可能な言語インターフェイスパック (Language Interface Packs, LIP) の形でダウンロードできるようになる予定です。これは、世界中の政府、大学、言語学者との共同研究である、ローカル言語プログラム (Local Language Program, LLP) の一環です。LLP の一環です。(LLP の詳細については、http://www.microsoft.com/unlimitedpotential/programs/llp.mspx を参照してください)。LIP の作業は RTM と同時に開始し、パートナーのスケジュールに基づいてその後何か月も続きます。2 つの LIP が 10 月の Windows 7 と同時にダウンロード可能になる予定です。それは、カタロニア語とヒンディー語です。その他の LIP は、パートナーのスケジュールに基づいて随時ダウンロードできるようになる予定です。最初の 38 言語 (36 + 2 LIP) について、提供時期を改善できたことをうれしく思います。そして、将来のリリースにおいて、さらに改善していきます。私たちの方で信頼できる実績を作り上げることは、世界中の人々が、より統一されたリリーススケジュールの計画を立てるのに役立ちます。

拡張言語サービス (ELS) およびその他の Windows 7 のすばらしい新機能についての詳細は、オンラインで MSDN で提供しています。特に、Windows 7 用の Windows SDK をダウンロードし、「International」セクションで最新情報について読まれることをお勧めします。また、MSDN の新しい Go Global Developer Center には、インターナショナルのテクノロジーについて豊富な情報があります。

フィードバックについては、このブログエントリに対してコメントしていただくか、Windows 7 のフィードバックツールを使用してください。皆さんからのご意見を (どの言語でも) お待ちしています。

-- Windows International Team

Beta から RC への変更点 – Windows の機能をオンまたはオフにする

e7blog — Thu, 26 Mar 2009 13:27:59 GMT

「選択と管理」のテーマは、私たちがどのように Windows 7 を設計したか、多くの側面に当てはまります。このテーマや私たちが行った設計上の選択について多くの好意的なフィードバックが寄せられており、将来どのようにこのテーマを実装していくかに関する提案も少しばかり寄せられています。また、機能をもっとカスタマイズできるようにするべき (たとえば、エクスプローラやログオン画面など) とか、機能を Windows に追加すべき (たとえば、PDF フォーマット リーダー、セキュリティ ツール、ディスク ユーティリティなど) というフィードバックを頂いてきました。そして、一部のユーザーからは、特定の機能なしに Windows を実行したいと思っているというフィードバックも頂いています。この投稿は、コントロール パネルにある [Windows の機能] と呼ばれる Windows のさまざまな機能をオンにしたりオフにしたりできる場所に関するもので、Windows 7 の選択と管理のポイントについてです。そして、フィードバックに基づき、Beta から RC に移行する際に加えた変更に関する論議の続きです。この投稿はドキュメント & プリンティング チームのグループ プログラム マネージャーで、Internet Explorer 8 にも携わっていた Jack Mayo によるものです。 --Steven

「Windows の機能をオンまたはオフにする」は、Windows がまだ 32 ビットコードだった頃からの長い歴史があります。みなさんから、自分自身の選択の基準でオンやオフにしたい機能について、たくさんの提案を頂いてきました。Windows 7 ではより膨大な機能のリストを設計しましたが、幅広い Windows プラットフォームのニーズを踏まえながらそのリストのバランスが取れるようにも取り組んできました。私たちは選択肢を提供したいと思っていますが、同時に開発者へ提供していた API を削除して互換性を損なうことのないようにもしました。また、ユーザーに対して、選択肢を提供すること、アプリケーションとの釣り合いを取ること、および一貫した Windows エクスペリエンスを提供することの間で適正なバランスを取りたいとも思っています。

多くの人は、何が Windows において「機能」または「プログラム」を構成するか、また何が OS の特定できる「パーツ」を構成するかについて、具体的な考えを持っています。そして、異なる人々は異なった視点、しかもしばしば固く信じている視点を持っていることも、私たちは理解しています。ある人はエンドユーザー寄りのアプローチをとって、ウィンドウやスタートメニューのショートカットに基づいて機能を特定するでしょう。ある人は、ストレージやセキュリティといったアーキテクチャーのサブシステムのひとつの視点に基づいたアプローチをとるでしょう。またある人は、自分にとって何が似通った機能性の代わりの選択肢となるかに基づいたアプローチをとるかもしれません。これらすべてはある意味もっともですが、このように多様な観点を考慮していると、一貫して「機能」を特定することにはならないでしょう。エンジニアとして、いかなるソフトウェアシステムも無原則なレイヤーやパーツには分解されない、そして、いかなる分解も時間が経つにつれて変わりやすいことを知っています。

この機能や選択肢についての議論を本題からそらし、コミュニティページの改定履歴から判断してとても挑戦的な課題である OS の定義についての哲学的な議論へとしたくありません。しかし、このブログがスタートした夏から言われてきたフィードバックを満たす助けとなることに重点を置いて機能を改善したいと思っています。

Windows 7 の RC では、[Windows の機能] と呼ばれるコントロールパネルを拡張しました。これは、標準の [プログラムと機能] コントロールパネル (オリジナルの名称である「Add/Remove Programs (プログラムの追加と削除)」から、しばしば “ARP” と呼んでいます。) から利用可能です。この場所は Vista やXP から変わっていませんが、言い回しが明確になりました。Windows 7 にて [Windows の機能をオンまたはオフにする] をクリックして (または単にスタートメニューで “Windows の機能” と入力して) [Windows の機能] コントロールパネルを開くと、RC では下記のようなものが表示されます (デフォルトでは階層は完全に開いていませんが、このスクリーンショットでは追加情報のために、一部の要素を展開しています):

Vista または Beta 版のこのダイアログを見慣れた人は、リストが長くなったことに気付くでしょう。何を追加したか、また、これがどのように動くか、簡単にお話しましょう。

もし機能が非選択状態の場合、その機能は利用可能ではありません。つまり、ファイル (バイナリおよびデータ) は OS によって読み込まれておらず (セキュリティ意識の高いユーザー用)、コンピュータ上でユーザーは利用できません。この同じファイルはステージングされるので、機能はメディアがなくても実行中の OS に簡単に追加することができます。このステージングは、いちいちインストール用の DVD を探したくないユーザーからの重要なフィードバックによるものです。

リストされているどの機能についても、有効または無効へと状態を変更できます。Vista および Windows 7 Beta 版のコントロールパネルでは、幅広い機能がリストされていました。あるものはクライアントのワークステーションに従事している開発者をターゲットとしたもの (IIS、MSMQ など)、他はネットワーク管理者や熱心な人向けのユーティリティ (RSM、SNMP、Telnet など)、またあるものはユーザーがオプションにして欲しいと要望していた機能 (ゲーム、ファックスとスキャン、タブレット PC のコンポーネント) です。

Windows 7 では、この点においてユーザーがコントロールできる機能の数を増やし、このバージョンの Windows で利用可能な機能を管理する上で、ユーザーに対してより高いコントロール、柔軟性、および選択肢を与えています。Windows Vista で既にオン/オフできていた機能に加え、Windows 7 では下記の機能をリストに追加しました:

Windows Media Player
Windows Media Center
Windows DVD メーカー
Internet Explorer 8
Windows 検索
手書き認識 (タブレット PC コンポーネントのオプションを通じて)
Windows ガジェットプラットフォーム
Fax とスキャン
XPS ビューアとサービス (仮想プリントドライバを含む)

「削除」の詳細について説明するのは意味があるかもしれません。それはこのエリアがエンジニアリング的対処が必要であり、また顧客の決断が成される場所でもあるからです。DVD を必要としないよう、将来の使用に備えて機能はステージングしておくようにするという決定については既に述べたとおりです。二番目の決定は、機能のために利用可能な API をサポートし続けるということです。これらの API は Windows の機能性に必要であったり、コンポーネントとは無関係とみなされるような開発者によって使用されたりします。みなさんの多くがご存知のように、これらはしばしば「依存関係」と呼ばれ、Windows では依存関係は Windows 内部と外部のソフトウェアメーカーの両方に及びます。

Windows で新しい機能を開発する際、余計な作業が発生し、パフォーマンスが遅くなり、セキュアにすべき表面が増えるかもしれない複製したコードよりも、根底にあるインフラと関連した API を使用しがちであるのは当然です。コードの再利用はすぐれたエンジニアリング手法だということを私たちはみな知っています。プラットフォームとして、Windows はたくさんのシステム用の API の作成を重視しがちです。それはサブシステムがひとつの大きなシステムの一部とみなされるときでもです。使用されている API があれば、API がそこにあることを期待しているソフトウェアをつかえなくしてしまうか、あるいはAPI をサポートし続けるか、という選択肢があります。API をサポートし続ける場合、私たちのアプローチは、エンドユーザーが伝統的なメカニズムで機能を呼び出せないようにして機能を削除することでした。これはしばしば難しい選択です。なぜなら、開発者の期待、Windows 7 の堅牢なリリースを出荷しようという共通の願望、および「Windows の機能をオンまたはオフにする」機能によって設定された目標をやり通すことの間でバランスを取りながら作業しているからです。このリストで表されるように依存関係について非常に多くの組み合わせがあるので、あるオプションを選択すると、組み合わせを選択することの難題についてある程度分かっていただけると思います (たとえば、Windows Media Player と Windows Media Center はたくさんのコードを共有しているので、片方をオフにすると、平均的なエンドユーザーにとって非常に複雑な状況になってしまうでしょう)。

最後に、数名の方から、この選択肢のセットを「セットアップオプション」にしたらどうかという提案を頂いておりました。あるオペレーティングシステムでは、この種のセットアップエクスペリエンスを提供しています。しかし、いただいた多くのフィードバックを鑑みた結果、大多数の意見はセットアップを簡素化し、PC を実行するにあたって複雑になる可能性を減らすべき、というものでした。そこで私たちは、Windows 7 ではこの機能をセットアップ後のエクスペリエンスに集約することにしました。

--Jack

Windows 7 のアプレットの紹介

e7blog — Wed, 18 Feb 2009 14:29:56 GMT

およそ十年ごとに、私たちは Windows でアプレットと呼ばれるものの更新について大きな決定を行います。なお、アプレットについて説明するときに、アプレットをアプリケーション、プログラム、またはツールとも呼びますのでご注意ください。アプレットは、長い歴史を持つ Calc (電卓) ペイント (MS ペイント、またはペイントブラシ)、ワードパッド (Write)、さらに Windows 7 での新しい付箋などです。古くから知る者として、これらのツールについて考えるときはいつも、これらの歴史のすべてとこれらがどのように登場してきたのか考えます。多くの人々が、弊社の現在のCEOによる、今では「古典」となった video をご覧になっていることと思います。このビデオは、営業担当者たちの注意を Windows に引き付けました (このビデオの最後の言葉は、このビデオが Microsoft 内で実現したことの手掛かりとなります)。Windows 7 は、これらのツールを更新する絶好の機会と思われます。このリリースでアプレットを更新する理由は、アプレットに固有の機能を追加するちょうど 10 年ごとの時期だからということではなく、開発者の皆様が皆様のアプリケーションを Windows 7 デスクトップエクスペリエンスと統合する新たな機会だからです。多くの人々はアプレットを基本ツールとして使用します。アプレットはすべての人向けに「即座に利用可能な」価値を提供していますが、私たちは全体的なプラットフォームエクスペリエンスを示し、Windows 7 上で統合し構築する方法について開発者へガイダンスを提供するとき、アプレットをより価値あるものと考えます。私たちは主に Windows で何が新しいかを示すことに焦点を当てています。多くのフル機能のツールが同様の機能を無料で提供しているので、これらのツールへますます多くの機能を追加しなければいけないという実際的な「緊張」状態にはありません。より高精度のビットマップエディット機能や高度な科学計算用電卓機能への希望でコメントがいっぱいにならないよう願っています :-)。

この投稿で取り上げられたすべての APIは、 Windows 7 developer guide でご覧いだけるWindows 7用に更新された開発者向け領域の MSDN で説明されています。また、取り上げられた各領域は PDC と WinHEC のサイト上の各セッションでサポートされます。

この投稿は、リーダーの Riyaz Pishori (グループプログラムマネージャー) とアプリケーションおよびガジェットチームの複数の人々によって作成されました。 --Steven

この投稿では、Windows 7プラットフォームのイノベーションのいくつかと、Windows 7 アプリケーションがそれらのイノベーションをどのように採用し公開したかについて説明します。開発者とパートナーが Windows 7 で期待できるプラットフォーム機能のいくつかと、Windows 7 プログラムがそれらのイノベーションをどのように公開したかについて詳述します。この投稿ではさらに、主な Windows の設計原則およびプラットフォームのイノベーションに焦点を当てながら、ユーザーエクスペリエンスおよび機能の点でアプリケーションがどのように革新されたかを説明します。この投稿は、いくつかの新しいWindows プラットフォームのイノベーションに慣れるため、アプリケーション開発者とソフトウェアメーカー向けの指針あるいはガイドにもなります。皆様のソフトウェアの開発にこれらの APIを活用する方法を知っていただきたいと思います。

以下の記述は、サブシステムごと、そして Windows アプレットがその特定のサブシステムを使用する方法ごとに整理されています。

Windows リボン

Windows リボンユーザーインターフェイスは、リッチで新しい Windows 開発用ユーザーインターフェイスです。Windows リボンは、現在使い慣れている Office 2007 リボンユーザーインターフェイスを Windows 7にもたらし、アプリケーション開発者とソフトウェアメーカーが利用できるようにしました。

Windows リボンユーザーインターフェイスを採用すると、いくつかの利点があります。それらの多くは、Office 2007 blogs で述べられています。リボンは、さまざまな機能やコマンドを異なるメニューやツールバーの下に公開することなく、すべてのコマンドのリッチなグラフィカルユーザーインターフェイスを一つの場所で提供します。リボン UI は、直接的で説明を要せず、論理的に関連するコマンドが名付けられグループ化されています。リボン UI プラットフォーム上に構築されるアプリケーションを使用する際、ユーザーは特定の機能がどこにあり、どこでアクセスできるかについて気を配る必要はなく、必要なのはワークフローとタスクに集中することだけです。また、リボン UI によりレイアウトが調整されるので、サイズ、場所およびコンテンツをユーザーがカスタマイズできるツールバーと比較すると、一貫性が保たれます。さらに、リボン UI には向上した組み込みキーボードユーザー補助があり、リボンを使用することによって、アプリケーション DPI とテーマがより容易に実現されます。最後になりましたが、リボンユーザーインターフェイス用の XML マークアップに基づいたプログラミングモデルにより、ユーザーインターフェイスの開発および変更は非常に迅速に行えます。

ペイントとワードパッドは、Windows リボン UI プラットフォームを利用した最初の 2 つです。Windows 7 では、両方のアプリケーションが一連の新機能によって拡張されており、これらのアプリケーションのユーザーインターフェイスは、Windows 7 エクスペリエンスにふさわしい標準に達する必要がありました。Windows リボン UI は、これらのアプリケーションが各ユーザーエクスペリエンスを改造して一貫性を持たせ、リッチで楽しく容易に使用できるようにするにはうってつけです。また、これらのアプリケーションのタスクおよびコマンドでは、リボン UI フレームワークを容易に適用できました。これにより、人気のあるネイティブ Windows アプリケーションが、開発者とソフトウェアメーカーと同様コンシューマーに、Windows リボン UI プラットフォームを公開する好機になりました。多くの人々に、リボンを使用する Windows Explorer と IE について尋ねられますが、私たちは Windows 7 では計画しませんでした。Windows 7 で重点が置かれているのはプラットフォームで、ペイントとワードパッドのようなドキュメント中心のアプリケーション用プラットフォームを示すことです。

両方のアプリケーションは、Windows UI リボンの複数の要素を公開します。ペイントとワードパッドの両方のアプリケーションメニューでは、アプリケーションの [ファイル] メニューによって通常参照できるアプリケーションに関連したコマンドを表示します。両方のアプリケーションには、アプリケーションのほとんどのコマンドを表示する [ホーム]、およびアプリケーションのオプションを表示するイメージまたはドキュメントを表示する [ビュー] とからなるコアタブのセットがあります。両方のタブの各コマンドは、関連する機能のグループ内に論理的にレイアウトされます。

クイックアクセスツールバー (QAT) は、ペイントおよびワードパッドの両方で提供されます。これは、アプリケーションにとって重要な [保存]、[元に戻す]、または [繰り返し] のような特定の初期設定を備えています。ユーザーは、QAT ドロップダウンを使用して QAT をカスタマイズしたり、リボンで任意のコマンドやグループを右クリックしてそれを QAT に追加したりできます。

コマンドボタン、分割ボタン、ギャラリー、ドロップダウン、チェックボックス、トグルボタンなどの複数のリボンコマンドが、両方のアプリケーションで使用されます。

さらに、両方のアプリケーションは、コンテキスト中のイメージやドキュメントの印刷プレビューを示す [印刷プレビュー] モードを提供します。モード内では、コアタブはすべて削除され、ユーザーが対話的に操作するためにそのモードだけが表示されます。モードを終了すると、ユーザーは即座にコアタブに戻れます。

ペイントは、さらにテキストツール用の操作別タブを表示します。テキストツールは、テキストコントロールがキャンバスにある場合に限り表示されます。操作別タブは、テキストツールにフォーカスが当たっているときにコアタブセットの横に示され、テキストがキャンバスのイメージに適用されると削除されます。操作別タブセットは、テキストツールのみに固有の関連ツールを含みます。

両方のアプリケーションは、リボンギャラリーによってライブプレビューを提供します。リボンギャラリーは、ワードパッドでテキストをフォーマットする際のフォントサイズおよびフォント名、ワードパッドでの行頭文字や行、ペイントでの色の選択、輪郭線サイズ選択、および図形用の枠線と塗りつぶしのスタイルなどです。ライブプレビューによって、ユーザーはマウスの移動がもたらす変更を瞬時に理解し、選択対象にそれらの変更を適用することを可能にします。これらのプレビューはリボン UI の重要な要素の 1 つで、リボン UI が新しい対話スタイルで、なぜ「大きなツールバー」以上のものであるかということを表しています。
リボンユーザーインターフェイスの採用によって、両方のアプリケーションは、リボン KeyTipを使用する組み込みキーボードユーザー補助サポートを継承し、すべてのコマンドはヒントを持ち、DPI と Windows のテーマ用サポートを備えています。

ペイントとワードパッドは、リボン UI が MFC アプリケーションでいかに容易に使用できるかを示す例です。Windows リボンは、開発者とソフトウェアメーカーがリボンユーザーインターフェイスを使用してアプリケーションを開発する新たな機会およびオプションを提示します。Windows Scenic Ribbon プログラミングモデルおよびアーキテクチャは、開発者が UI のプレゼンテーションとカスタマイズを基になるアプリケーションコードから切り離すのを支援するために、マークアップファイルとC++ コードファイルの分離を強調しています。このプラットフォームは、設計者は UI のプレゼンテーションとレイアウトに集中し、開発者はアプリケーションロジックに集中することができる開発者 - 設計者ワークフローを促進します。私たちはリボン UI には大きな投資を行っています。PDC でScott Guthrie によって示されたように .NET Framework での実装を含め、さらに Microsoft のプロダクト全体にわたりリボン UI が引き続き使用されることをご期待ください。さらに、将来のWindows 7 ではネイティブでサポート構築される予定です。

マルチタッチプラットフォーム

Windows 7 は、マルチタッチ入力データのサポート、およびWindows メッセージによる Win32 でのマルチタッチのサポートを提供します。マルチタッチプラットフォームへの投資先には、アプリケーションにタッチ API を公開する開発プラットフォームが含まれています。これは、Windows 7 でコアユーザーインターフェイスを拡張してタッチエクスペリエンス用に最適化し、アプリケーションが実行するマルチタッチジェスチャを提供します。Windows 7 での開発者は、これらの API 上に構築し、ソフトウェアで提供するタッチサポートの適切なレベルについて決定できます。

ワードパッドは、マルチタッチプラットフォームの使用、およびズームジェスチャとパンジェスチャの使用により、ドキュメント読み取りエクスペリエンスを拡張します。ズームする、ゆっくり動く、または慣性に任せるなどにより、ユーザーは直感的な方法で特定のコンテンツに非常に迅速に到着できます。ズームジェスチャの使用によって、ユーザーは、ワードパッドのステータスバーの右側でズームスライダーを使用したように、ドキュメントにズームインまたはズームアウトすることができます。マルチタッチが可能なハードウェアでは、ユーザーはフィンガーをドキュメントウィンドウ内の任意の場所に置いて、ズームジェスチャを実行することにより、ドキュメントにズームインまたはズームアウトできます。ワードパッドは、ワードパッドで開いているドキュメントのページでパンするためのパンジェスチャもサポートしています。パンジェスチャの実行によって、ユーザーは、ワードパッドアプリケーションのスクロールバーを使用しているように、ドキュメントをスクロールダウンまたはスクロールアップできます。

ペイントで、マルチタッチデータは、ユーザーが複数のフィンガーで描画することを可能にするために使用されます。これは、ジェスチャを使用せずにマルチタッチ入力を可能にするアプリケーションの例です。ペイントの機能の場合、複数のフィンガーペイント能力の提供は、編集モードではなく読み取り専用モードで画像に対して実行するズーム、パン、回転、あるいは他のジェスチャを、可能にするという以上に、より魅力的でよりリッチなものにします。ペイントでの新しいブラシは、マルチタッチ対応で、複数のフィンガーによるタッチ入力を処理します。ユーザーは同時にフィンガーをドラッグさせてキャンバス上に複数のストロークを描けます。これらのブラシには感圧性もあるので、画面に対する圧力に基づいてストロークの幅が変わり、タッチによる現実的なエクスペリエンスが提供されます。マルチタッチプラットフォームを採用してペイントのエンドユーザーエクスペリエンスを拡張するにあたり、カラーピッカー、拡大、テキストツールなどのマルチタッチシナリオが適用されない機能用にシングルタッチエクスペリエンスを保持するために、設計に関して意識的な決定がなされました。
マルチタッチ API を使用して構築することにより、ペイントとワードパッドは、タッチ対応ハードウェア上でより自然により直感的なインターフェイスを作成し、ソフトウェアで開発者がどれだけ異なる機能を公開できるかを「即座に」示します。

タスクバー

付箋 (メモ) は、Windows 7 で使用可能な TabletPC アプレットの拡張機能です。デスクトップ上のノートエクスペリエンスで重要なことの 1 つは、引き続き新しいノートを確実に容易に作成できる一方で、迅速にすべてのノートを取り去り、また戻すことができることです。私たちは、付箋アプリケーション用の単一のトップレベルウィンドウを持つことにより、これを達成しました。シングルクリックで、ノートをすべて最小化し、コマンドバー上でノートをプレビューで表示できます。重ねて表示されるプレビューは、新しい縮小表示プレビュー API を使用して実現されました。この APIは、アプリケーションが、実質的にトップレベルのアプリケーションウィンドウのリダイレクトされたスナップショットである既定の各タスクバープレビューをオーバーライドし、独自に提供できるようにします。これにより、アプリケーションは、トップレベルのアプリケーションウィンドウからこのプレビューを切り離し、シナリオに基づいたより生産的なプレビューを提供できるようになります。これは、たとえば、最後にタッチされたノートを迅速に見ることにより生産的なワークフローが実現できる付箋シナリオにおいて非常に価値がありました。いったんプレビューがタスクバーに与えられれば、タスクバーはそのようにプレビュー縮小表示イメージをキャッシュします。アプリケーションはそれ維持する必要はありません。ただし、それが変化した場合は、アプリケーションは更新されたプレビューを送信する必要があります。

タスクバーにおけるもう一つの有効なカスタマイズエンドポイントは、レプリケート先メニュー (別名 jumplist) です。このメニューは、ユーザーがタスクバーでこのアプリケーションを右クリックするか、[スタート] メニューでこのアプリケーションアイコンをポイントすると表示されます。付箋アプリケーションには、単一のメインアプリケーションウィンドウがありません。このため、アプリケーションは実に軽く感じられ、Windows 7 のシンプルで強力なユーザーエクスペリエンスを作成するという哲学によく合っています。課題は、主要な場所あるいは潜在的には他のカスタム「タスク」から新しいノートを作成できるような機能を公開することでした。レプリケート先メニューは、シンプルであってもこれまでにないような方法でこれらのシナリオを公開するのに役立ちます。

新しいタスクバーの機能性と拡張性により、開発者はソフトウェアを Windows デスクトップと統合するとき、ユーザーが生産的で効率的な方法でアプリケーション/シナリオを実行するのをより簡単に実現できます。

検索

Windows での検索の長い歴史および Windows 7 での重要な拡張機能に基づき、各コンテンツを Windows 7 のデスクトップ検索ユーザーエクスペリエンスとより深く統合できる開発者が使用可能な API があります。これらの API の使用方法の一例を付箋で示します。

付箋アプリケーションは、[スタート] メニューの Windows インライン検索によってコンテンツを検索することにより、ユーザーがノートに戻ることを可能にします。これにより、アプリケーションが閉じられている場合にさえ、ユーザーは関連するノートに可能な限り迅速にアクセスできます。テキストとインク両方のコンテンツに対して検索を実行できたとしても、インクでは様々な手書きのスタイルがあるため成功率が低いので、テキストに制限されています。アプリケーションは、各ノートの URL を生成するプロトコルハンドラーを登録します。付箋フィルターハンドラーは、検索インフラストラクチャによってインデックスを付けられる各ノートに関連付けられたコンテンツ用に要求されます。これらのインデックスは、ユーザーが後ほど Windows シェルによって提供される検索インターフェイスを検索する場合に使用され、迅速な参照を実行します。ユーザーが結果上でクリックすると、検索は、プロトコルハンドラーが生成した対応する URL で、関連付けられたアプリケーションを呼び出します。それは、フィルターハンドラーが Search indexer に送信したコンテンツと関連付けたものです。

索プラットフォームには、渡されたコンテンツの言語を指定し、言語を計算するのに使用する既定の検索ヒューリスティックをオーバーライドすることを可能にする機能もあります。これにより、検索の正確さが非常に高まり、全エコシステムの国際的サポートが拡張されます。

付箋がプロトコルハンドラーをフィルターハンドラーに加えて実装した理由は、それが Windows ファイルシステムのトップに独自の統合ストレージスキーマを実装しているからです。すべてのノートは単一の .snt ファイルによって表されます。プロトコルハンドラーは個々のエンティティ (この場合はノート) の URL を生成します。フィルターハンドラーはこれらの各 URL のコンテンツを選び、検索にインデックス作成用に提供します。
これは、アプリケーションが容易に Windows 7 で検索プラットフォームに接続でき、プラットフォームと同様にアプリケーションからも全体的なユーザーエクスペリエンスを拡張するできる検索ハンドラーを追加できることを示しています。

リアルタイムスタイラス

リアルタイムスタイラス (RTS) は、ペンまたはタッチデジタイザーからのスタイラスイベントへのアクセスを提供するインフラストラクチャです。これは、ストロークとポインに関する情報を提供し、インク関連のイベントへのアクセスを提供します。RTS を使用すると、アプリケーションは、スタイラス情報にアクセスでき、魅力的なエンドユーザーシナリオおよびエクスペリエンスを開発できます。
付箋では、手描き入力ハードウェアの可用性によって、ユーザーはノート上でインクとタイプを使用できます。ユーザーはキーボード入力を使用してノートにタイプでき、スタイラスを使用してノートにインクできます。このエクスペリエンスは、ユーザーが特定のノートでインクまたはテキストのどちらかを使用することを念頭において設計されましたが、同じノートにインクとタイプの両方が可能です。ただし、これらの面は互いに不可知に維持されます。さらに、付箋は、ノートにインク中にノートを自動で広げ、インクされたコンテンツに合うようノートのサイズを調整するリアルタイムエクスペリエンスを提供します。

リアルタイムスタイラス (RTS) は、付箋で提供される手描き入力機能用に使用されます。また、手描き入力ジェスチャがアプリケーションで使用可能で、インクを消すジェスチャがコンテンツを削除するために付箋に実装されました。

さらに、ペイントは RTS を使用して、キャンバスでストロークを描くために使用されるマウス、スタイラス、あるいはタッチから位置入力を得ます。ペイントはさらに、入力がデジタイザーから使用可能な場合、圧力やタッチ面積など他の入力変数をキャプチャします。そして、キャンバスでペイントストロークを生成するために使用されるストロークアルゴリズムへこれらの入力をマップします。ユーザーはこのアルゴリズムを使用して、キャンバス上の圧力やタッチ面責基づくストロークの幅や他のパラメーターを調整できます。

RTS の使用は、手描き入力プラットフォーム上に構築するアプリケーションおよびソフトウェアの開発を可能にし、マウスやキーボードを越えるアプリケーションとの対話方法を提供します。スタイラス、手描き入力、およびジェスチャを使用すると、開発者はエンドユーザー用に対話型エクスペリエンスを作成できます。

再起動と復旧

Windows エラー報告 (WER) インフラストラクチャは、Windows 7および他の以前のバージョンの Windows クライアントおよびサーバーに組み込まれる一連のフィードバックテクノロジーです。WERは、アプリケーションがアプリケーションエラー用に登録し、それを報告することを同意したエンドユーザーのため、データをキャプチャすることを可能にします。このデータは、開発者がアクセスして分析し、エラー傾向およびダウンロードデバッグ情報を監視するために使用できます。また、開発者やソフトウェアメーカーがアプリケーションエラーの根本的原因を判定するのに役立ちます。

WERは、開発中やエンドユーザーから初期のフィードバックを得られるベータテスト中や、重要な修正プログラムを分析し優先度をつけられる製品リリース後に、そして製品のライフサイクルの最期など、ソフトウェア開発のさまざまな段階で非常に有益です。

アプリケーションが実行されている時に、Windows パッチによってリスタートがかかってしまった場合や、コンピューターが再起動された場合、レポートを上げるためにアプリケーションはWERを使うことができます。アプリケーションのクラッシュやハングあるいは応答しない状態を引き起こす障害への対応や、オプションで紛失データの復旧用にも利用することができ、復旧用に独自の機構を開発できます。
複数の Windows アプリケーションは、データを収集して分析するために WER インフラストラクチャを採用しています。電卓、ペイント、およびワードパッドは再起動用に、動作していたアプリケーションのセッションの現在のデータを回復します。付箋は再起動と復旧のため、デスクトップ上で開いている一連のノートへユーザーを返します。WER を使用すると、エンドユーザーは、Windows によって問題データをキャプチャして収集することができ、そのため、前と同じ状態でアプリケーションに戻れます。

すでにお分かりのように、私たちが Windows 7 のアプレットで主に取り組んだのは、開発者が使用できる新しいプラットフォーム API とイノベーションのいくつかを公開することです。これらのアプリケーションを使っていただけば、いくつか一般的に要求をいただいた機能も追加されたことをがおわかりいただけると思います。その一部は次のとおりです。電卓での確認と修正、各計算モード、およびテンプレート、ペイントでの新しいブラシ、図形、およびマルチタッチサポート、ワードパッドでのオープンスタンダードサポート、付箋でのインクとテキスト、タスクバー、および検索統合。私たちは 10年を待たずに再びこれらを更新する予定です :-)

--Riyaz Pishori とチーム

マイクロソフトのEngineering Windows 7 ブログ : Platform

グローバル マーケットに向けた Windows 7 のエンジニアリング

Beta から RC への変更点 – Windows の機能をオンまたはオフにする

Windows 7 のアプレットの紹介

グローバルマーケットに向けた Windows 7 のエンジニアリング