セットアップのエクスペリエンスを改良する

Windows のインストールは、将来の Windows についての知識なしに設計された膨大な数のハードウェアの構成や組み合わせにおいても、新しいバージョンの Windows を (たとえカーネルの抜本的な再設計が行われていても) 問題なく実行するという、きわめて特異な対応能力を実現する、複雑なオペレーションです。多くのユーザーは Windows の次期バージョンを新しい PC の購入という形で入手し、その場合はすべてのセットアップ/アップグレードを行うわけではありませんが、新しい PC の “OOBE” (out-of-box experience: “箱から出したばかり” の状態で提供されるエクスペリエンス) の調整だけでも、複雑で技術的に高度な課題なのです。セットアップの改良において私たちが目指したのは、開始から終了までの時間を短縮して、なるべく早く Windows を使用できる状態にすることです。これによって、そこから先のカスタマイズには Windows の能力をフルに活用していただくことができ、ひいては新しい Windows のエクスペリエンスを早く楽しんでいただけることになるはずです。今回の記事は、Setup and Deployment (セットアップおよび展開) チームの Christa St. Pierre が執筆しました。–Steven (なお、米国の祝日の期間はこのブログもお休みさせていただきますのでご了承ください) 過去から現在までのどの Windows のリリースにおいても、セットアップには多大な注意が払われてきました。セットアップは、膨大な種類のハードウェアやソフトウェアのすべてにおいて、とにかく安定して動作する必要があります。個人ユーザーが自分のノート PC をアップグレードする場合でも、企業の IT プロフェッショナルが大規模な配置ツールを使って 10,000 台のデスクトップ PC を新しい Windows に移行させる場合でも、この点は同様に実現されなければなりません。Windows 7 で私たちが主に注目したのは、インストール成功率の向上です。信頼性を高めるためにさまざまな取り組みが行われ、過去のバージョンの Windows で問題の原因となった多くの難しい (ただし比較的まれな) ケースが解決されました。これによって、Windows 7…

0

Windows Update による自動更新後の再起動回数を減らす

インターネットが登場するまで、サービス パックや “パッチ” などの更新プログラムは、非常に入手しにくいものでした。更新プログラムはメディアの形で注文したり、雑誌の付録 CD から入手したりするのが普通でした。しかし、インターネットの登場によって状況は一変します。 ftp.microsoft.com が初めてセットアップされた際に、最初に提供されたサービスの 1 つが、MS-DOS と Windows の更新プログラムの配布でした。Windows Update の導入によって、私たちは単なるソフトウェア配布サービスではなく、高品質な更新プログラムをタイムリーに提供するシステムを構築するために、真剣に取り組むようになりました。ユーザーに自動更新機能を信頼していただける段階に至るまでには相応の時間がかかりましたが、それなりの成果も得ることができました。現 在、Windows Update はインターネットで最大規模のサービスの 1 つとなっており、もちろん Windows 8 の開発においても、製品アップデートのエクスペリエンスに改良を加えています。この記事は、Windows Update グループ所属のグループ プログラム管理者である Farzana Rahman が執 筆しました。–Steven Windows Update に関して話題になることが多い問題点の 1 つとして、自動更新の際に必要になる再起動の手間が挙げられます。これは当然と言えるでしょう。再起動が必要になれば、重要な作業の最中でも中断を強いられることがあるからです。 まず考えるべきなのは、そもそも更新プログラムのインストールになぜ再起動が必要なのか、ということです。理想を言えば、更新プログラムのインストールが再起動を伴わず、バックグラウンドでシームレスに処理可能なら、それに越したことはありません。しかし現実的には、インストーラーが更新しようとしたファイルが使 用中で更新できないケースがあります。こういった場合は、インストールを完了するためにマシンを再起動する必要があります。このため、自動更新機能は、再起動が必要な状況にも対応できなければなりません。 このアーキテクチャ上の問題は、管理者にとってもエンド ユーザーにとっても厄介ですが、Windows の最先端の技術を示すものでもあります。多くの更新プログラムで、既にメモリに読み込まれている既存のコードを実行し続けることは可能でも、そのコードがセキュリティ上の脆弱性などを持っているので、マシンを再 起動するまではセキュリティや信頼性の問題が残ってしまうことを理解しておく必要があります。この点については、今後も改善していくつもりです。再起動は面倒ですが、Windows Vista から採用された Windows 再起動マネージャーに対応するアプリケーションであれば、再起動後に再起動前とまったく同じ状態から作業を再開できます。 この投稿では、Windows 8 で自動更新のエクスペリエンスに加えている改良点についてお話ししたいと思います。この改良によって、再起動のわずらわしさもいくらか軽減されるはずです。 Windows Update についてのデータ 現在 Windows Update (チームではたいてい…

8

電力効率と汎用性に優れた Windows の実現

この記事では、電力消費量を抑える OS の開発という幅広いトピックを扱います。OS における電源管理の重要性は、2 つの観点から高まり続けています。まず、Windows 8 が市場に出る際、出荷される全 PC の 3 分の 2 が、常時であれ部分的にであれバッテリで駆動されるポータブル デバイスとなることは容易に推定できます。第二に、あらゆる場面で電力の節約が求められており、職場でもカーボン フットプリントの小さいデスクトップ マシンへの需要が高まっています。いずれの場合についても、スタンバイ/休止/再開の際のパフォーマンスといったレベルを超えて、OS 全体の電力消費量削減や、近代的なハードウェアの節電性能への対応について考える必要があり、この記事ではそういった点に迫りたいと思います。今回の記事は Kernel (カーネル) チーム所属のプログラム管理者である Pat Stemen が執筆しました。–Steven バッテリ寿命と電力消費量というトピックは、コンピューター業界において非常に重要な地位を占め続けています。この記事では、Windows 8 における電源管理の考え方と、私たちが毎日行っている電力消費量計測の方法についてご紹介したいと思います。Windows において、電源管理は OS のコア性能の一つであり、チップ アーキテクチャや PC のフォーム ファクターを問わず、きわめて重要な要素として捉えています。 目標 Windows 8 の電源管理は、次の 3 つの目標を念頭に設計しています。 ハードウェアを活かす。Windows 8 は、SoC ベースの Windows タブレットであろうと、SLI 搭載のゲーム用 PC であろうと、そのハードウェア プラットフォームの節電能力を十分に活用できるように設計されています。すべてのプラットフォームに一貫して、標準化された電源管理のインターフェイスが使用されており、ハードウェア パートナーやアプリケーション開発者が、各プラットフォームのハードウェアや電源管理面の差異に気を取られることなく、独自のイノベーションやエクスペリエンスの提供に注力できるようになっています。 優れたバッテリ寿命を維持する。Windows 7 では電力消費量が大幅に低減され、エネルギー効率が大きく向上しました。特にモバイル PC のバッテリ寿命には大きな改善が見られました…

1

バッテリ消費を抑えながらライブ タイルの更新を行う

私たちが使用するさまざまな “画面” に共通して普及の度合いを増しているのが、軽量な通知機能という概念です。当初は Windows ガジェットがこういった役割を担うことを目指していました。重要な情報 (たとえばニュース、天気、スポーツのスコア、基幹業務関連のイベントなど) をすばやく表示するためのヘッドアップ ディスプレイを提供するという趣旨です。しかしながら、ガジェットの起動時間や動作モデルは、全体的な電力消費量の削減 (デスクトップ PC でもノート PC でも重要な要素です) や、開発者のための全画面表示のプラットフォーム提供といった取り組みとは相容れないものです。また、Windows 8 の [Start] (スタート) 画面では、こういった通知に利用できる面積が大幅に広がると共に、ユーザー主導のインターフェイスを通してデータの更新 (ネットワーク リソースの使用を含めて) を管理できるようになっています。プッシュ配信や構造化されたスニペットを通して提供される情報の比率が増え続けている近代的なエクスペリエンスにおいては、このことが開発者にとってもエンド ユーザーにとってもユニークな機会をもたらします。今回の記事では、Metro スタイルのライブ タイルの開発と、このアーキテクチャが多数のタイルに対応しながら全体的な電力消費量とシステム負荷の軽減を実現するしくみについて、Ryan Haveson がご紹介します。–Steven Sinofsky パフォーマンスとバッテリの寿命が Windows の成功に欠かせない重要な要素だというのは、見解の一致するところでしょう。このブログにいただいているコメントでも、一貫してこれらの点が強調されています。KISSmakesmeSMILE さんのコメントはこの点をよく示したものです。 「…軽負荷/低負荷使用時のバッテリ寿命で、(競合製品と) 同等か、できることならより優れたパフォーマンスを実現してみてほしい」 同時に、すべての近代的な環境 (PC からテレビ、電話まで) において、なんらかの形でガジェット、ウィジェット、プラグインなどのモデルが採用され、ひとめで情報を確認できるようになっているのも事実です。テレビでニュース、スポーツ、天気などを見ていても、複数のソースからの情報がリアルタイムでまとめられ、構造化された画面に表示されています。ユーザーが期待するのは、株価、天気、未読メール数、次の予定、基幹業務アプリケーションの状態、ソーシャル ネットワークの状態などをすばやく確認し、数秒のうちに元の作業に戻ることができるというような動作です。多くの点で、PC はこの領域において他のデバイスに後れを取っていると言えるでしょう。通知インフラストラクチャの設計を始めるにあたっての私たちの課題は、アクティビティを生きた情報として表示しながら、電力消費と帯域幅の使用量においてきわめて高い効率を維持することでした。AndyCadley さんのコメントはこの目標をよく表現しています。 「”Metro” アプリを、常に起動している (ただしバッテリやパフォーマンスにはまったく影響がない) ものとして扱う」 [Start] (スタート) 画面では、ユーザー モデルの観点からもこの点の効率性が強化されており、デスクトップ アプリや Metro スタイル アプリの使用を邪魔することなく、全画面表示のヘッドアップ ディスプレイを提供することができます。これに加え、効率性を追求するだけではなく、通知機能を持つアプリをどれだけたくさんインストールしても、パフォーマンスやバッテリ寿命への影響を心配する必要がないようにしたいとも考えました。 Windows…

0

64 個以上の論理プロセッサをタスク マネージャーで扱う

今回は、User Experience (ユーザー エクスペリエンス) チーム所属のグループ プログラム管理者である Ryan Haveson から、Windows Developer Preview リリース以降のタスク マネージャーの進歩についてご紹介します。この記事では、多数の論理プロセッサを備えるシステムの管理に使用する、新しくなったタスク マネージャーのツールを扱います。これはデスクトップ PC の範囲を大きく超えたスケーラビリティを実現する機能であり、サーバーやデータ センター向けに設計されたものです。Windows の開発においては、幅広いフォーム ファクターや CPU アーキテクチャに対応することも、大きな比重を占めています。 コメントについて: コメントの質はコミュニティにふさわしい水準に保つようお願いします。自動的なスパム対策以外にはコメントの審査は行っていないことを、改めて申し添えておきます。  –Steven Sinofsky 新しいタスク マネージャーについては、以前の記事で扱ったほか、Developer Preview (英語) をインストールして実際にご覧になっている方も多いと思います。このトピックにはまとまった関心が集まっているようでしたので、デイリー ビルドに登場したばかりの新機能について、ベータ リリースで体験していただく前に、取り急ぎ簡単にご紹介しようと思います。 下に示すいくつかの画像では、サーバー管理者や、大量の論理プロセッサを備えた巨大な PC 環境を利用するユーザーが主に使用する機能を扱います。前もって確認しておくと、ここで扱うのは論理プロセッサです。ハイパースレッディング対応のシステムをお使いの場合、各物理プロセッサがそれぞれ複数の論理プロセッサとして動作することになります。 こういった多数のプロセッサを備えるシステムを使用されている方はご存知かと思いますが、Windows 7 のタスク マネージャーの CPU 使用率グラフには、いくつかの制約があります。 リアルタイムの比較機能がない: 大量の論理プロセッサを CPU グラフで監視している場合、重要なのは変則的な動きです。こういった規模になると、過去 60 秒間の各 CPU の使用率を表した、変動し続ける折れ線グラフを相互に比較して、何が起こっているかを把握するのはかなり困難です。 グラフが小さい: 論理プロセッサ数 64 個以上の規模では、個々のグラフはかなり小さなものになります。どのプロセッサの負荷が高まっているかを確認しようと思えば、小さなグラフを目を細めて読み取らなければなりません。論理プロセッサが 256 個を超えると、グラフを読むこと自体が困難になってきます。…

1