ウィンドウズ開発統括部

日本のウィンドウズ開発統括部です。

  Blog ホーム :: ホーム :: 連絡をする :: RSS  :: ATOM :: ログイン
投稿数  142  :: 記事 0 :: コメント 256 :: トラックバック 150

注意事項

当サイトの使用条件、コミュニティ利用規定または eXConn 削除規定に反する内容と判断されるコメントやトラックバックは、事前のお知らせなしに削除させていただく場合があります。ご了承ください。

投稿カテゴリ

アーカイブ

イメージギャラリ

3月 2006 Entries


及川です。

今日は IE7 により提供される改良されたセキュリティ機能について紹介したいと思います。

IE7 では次のような機能によりセキュリティを向上してます。

  • ActiveX Opt-in
    ほぼすべての ActiveX コントロールを無効にすることにより、脆弱な ActiveX コントロールによる被害を最小限に食い止めることができます。詳しくは ActiveX Security: Improvements and Best Practices(英語のみ)をご覧ください。
  • アドオン無効モード
    IE の起動時および特定の Web サイトにアクセス時に、システムが必要とするアドオンを除くすべてのアドオンを無効にすることができます。
  • 初期設定の修復
    インターネット設定が安全でない場合、インターネットオプションの該当部をハイライトさせることや情報バーで警告を出すことでその旨を通知します。
  • URL ハンドリングの改善
    URL パーサーを再設計することにより、URL を利用した悪意のある攻撃に対応することができるようになりました。
  • IDN に対するアンチスプーフィング機能
    IDN とは国際化ドメイン名の対応のことです。日本語ドメイン名とも呼ばれます。IDN は英語以外の言語をドメイン名として使うことができるため便利である反面、たとえば日本語と類似の言語をドメイン名として紛れ込ませることにより、別の悪意のあるサイトに誘導することができてしまいます。IE7 ではこのような IDN を利用したドメイン詐称(スプーフィング)に対応するために、異なる文字セットで IDN が構成されている場合にはユーザーに通知するようになっています。
  • アドレスバー保護
    ユーザーの操作性を高くするためかと思うのですが、Web サイトの中には意図的にアドレスバーを隠すものがあります。IE7 ではアドレスバーはポップアップウィンドウであっても常に表示されるようになっています。
  • フィッシングフィルター
    IE7 では標準でフィッシングフィルターの機能が搭載されています。この機能は Opt-in で提供されています。機能を有効にした場合、既知のフィッシングサイトへのアクセスをブロックします。また、フィッシングサイトであることが疑われるサイトにアクセスした際にはその旨通知されるようになっています。フィッシングサイトではないサイトがフィッシングサイトであると警告された場合にはその旨をマイクロソフトに報告できるようにもなっています。
  • クロスドメイン防御
    異なるドメインのコンテンツに対するスクリプトの実行を制限します。
  • ブラウザ履歴の削除
    一時ファイル、履歴、パスワード、フォームデータ、クッキーなどの一括して削除することができます。
  • セキュリティ ステータスバー
    アドレスバーの横の領域を使って、Web サイトのセキュリティとプライバシーの情報を表示します。たとえば、SSL で接続されたサイトの場合、そのデジタル証明書(X.509)の情報などにしたがって、安全性が確認できなかった場合には、ハイライトで警告を出します。

以上が Windows Vista に含まれる IE7 とスタンドアローンで提供される IE7 の両方に共通して搭載される機能です。一方、以下の2つの機能は Windows Vista においてのみ利用できます。

  • 保護モード(Protected Mode)
    Windows Vista の IE7 は Windows 上のほかアプリケーションから完全に分離して動作させることができます。この場合、IE 上で実行されるスクリプトや AcitveX コントロールからはインターネット一時ファイル用のフォルダ以外の場所には書き込むことができません。
  • 保護者による制限(Parental Control)
    Windows Vista には主に未成年者を対象にした保護者による制限機能が実装されています。これにより、IE7 においても保護者が未成年者(じゃなくてもいいのですが :-))の実行できる機能を制限することができます。

以上、ざっと IE7 により向上されたセキュリティ機能を紹介しました。また、それぞれについて機会があれば、ご紹介したいと思います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月31日 20:35


及川です。

話題の「ウェブ進化論 ― 本当の大変化はこれから始まる」(梅田望夫著 ちくま書房)を読みました。多くの皆さんもお読みになったと思いますが、どのような感想を持たれたでしょうか?

私は、今までずっともやもやしていたものが晴れたようなすっきりとした感じを抱きました。自らの周りで起こっていることを肌で感じながらも、それが言葉として整理できなかったのですが、それを自分の代わりに説明してくれたというのでしょうか、そんな感じです。ただし、著者の意見に全面的に賛成しているわけではありません。

「あちら側」と「こちら側」

読まれた方はご存知だと思うのですが、本書では、現在のネット革命はインターネットの「あちら側」で行われており、インターネットの「あちら側」を代表する企業がグーグルさんをはじめとする先進的なインターネット企業(「不特定多数無限大への信頼」を持ち、「ネットのあちら側」に軸足を置く企業)であるという論理が展開されています。マイクロソフトは PC による IT 革命を起こしたが、あくまでも「こちら側」の企業であり、「あちら側」での変革には乗り遅れていると書かれています。これ以外にも現在のネット革命による社会や個人への影響についても書かれていますが、マイクロソフトの社員という立場では、本書の全体を通して書かれている、この「あちら側」 vs. 「こちら側」というのがもっとも興味を持った部分です。

もちろん反論しなければなりません :-)。

この「あちら側」 vs. 「こちら側」という二元論は、時代や企業群を分類するには便利ですが、残念ながら、必ずしも単純にこの2つに分類できるものではないと思います。たとえば、「こちら側」の企業と言われてしまっているマイクロソフトですが、ご存知のとおり、Windows Live Office Live を中心とした“Software as a Service (サービスとしてのソフトウェア)”の戦略を持っています。それだけ見ても、マイクロソフトを単純に「こちら側」の企業と位置づけることはできないと思います。もちろん、梅田氏はそのようなことはご存知の上で、既存のコアビジネスから大胆に抜け出し、一気に「あちら側」の世界に入ることはマイクロソフトにはできないと言われているのだと思います。ただ、Web をプラットフォームとして利用してもらう際には、「こちら側」の世界である PC や各種デバイスでも最高のエクスペリエンスを実現することも考えることが必要です。それがマイクロソフトが Windows Vista で考えていることの1つです。

MIX06?の基調講演でマイクロソフトが使ったスライドの1つに下のような図が描かれています(クリックで拡大します)。

この図で示すように、現在の Web エクスペリエンスのレベルを上げるために、もっとも基礎的な部分では Ajax を利用すること(マイクロソフトの技術で言った場合、“Atlas”になります)、もっともリッチな環境では、WPF (Windows Presentation Foundation) を利用することを提案させていただいています。革命は「あちら側」ばかりでなく、「こちら側」のデバイスでも起きており、それらを有効活用するためには、“Beyond Browser”、すなわちブラウザ以外の環境においても、Web 技術との連携が必要となります。Windows Vista の WPF のデモをご覧になるとわかりますが、B2C のサイトに WPF で書かれたアプリケーションから利用すると、格段に高い操作性とまったく新しいエクスペリエンスをお客様に提供することができます。このように、今後のソフトウェアにおいては、「こちら側」も「あちら側」も無くなり、すべてが Web 技術と密接に絡み合っていくというのが私の考えです。

テクノロジーカンパニー

本書ではグーグルさんを「テクノロジーを徹底的に極めること」を考えている企業として紹介されています。人材の採用について、本書の中で、グーグルさんとマイクロソフトの類似点が述べられていますが、この「テクノロジーを徹底的に極める」という点に関しても多くの類似点があると思います。そして、私はテクノロジーによる革命が人々の生活を豊かにするものと信じていますので、競合会社をも持ち上げることになるかもしれませんが、このような会社には非常に好感が持てます。

本書の中で、ヤフーさんのサーチ担当副社長(ビッシュ氏)との以下のような対話が紹介されています。

「ヤフーは人、グーグルはコンピュータという言い方には少し違和感があるけれど、ヤフーは、人間が介在することでユーザー経験がよくなると信ずる領域には人間を介在させるべきだと考えている。そこはグーグルと決定的に違うな。そして、ヤフーはコンピュータが完全に人間の代わりができるとは思っていない。」

 私はさらに、「グーグルのほうがすべてを自動化することへの信念・情熱がより深いよね」と尋ねたが、ビッシュは「ノー・クエスチョン」(それは全くその通りだ)と答えた。

コンピュータの可能性をできる限り追求するという点では、私もマイクロソフトである経験をしています。現在は Exchange Server 担当の VP となっている Dave Thompson?が Windows Server の開発担当 VP であったころ来日したことがあるのですが、私は彼のすべての社内外のミーティングに同席する機会を得ました(別の言い方をすると、「かばんもち」です :-))。社内ミーティングで、Windows Server のある機能の操作が難しいため、その部分の操作方法やトラブルシューティングを詳しく説明した Whitepaper を用意するべきでないかと、彼に相談したところ、彼は、「Tak(彼は私をこう呼びます)、言っていることはわかる。短期的にはそのようなことも考えるべきかもしれないが、われわれはソフトウェアカンパニーだ。ドキュメントを用意するのではなく、ソフトウェア技術でお客様の問題を解決したい」と私に言ったのです。私は目を覚まされる思いでした。確かに、世の中にはコンサルタントや SE を張りつかせることでシステムの安定稼動を保証するようなベンダーさんもありますが、マイクロソフトは同じことをソフトウェアだけで実現すべきだと彼は言ったのです。グーグルさんがコンピュータによる自動化にこだわるのと同じように、マイクロソフトもソフトウェアによる革新を会社のコアミッションとしていることがお分かりいただけるエピソードではないでしょうか。

日本人一万人「移住計画」

本書は最後に「脱エスタブリッシュメントへの旅立ち」という章で結ばれています。この中で梅田氏は次のように新しく始められたプロジェクトについて説明しています。

「日本人一万人・シリコンバレー移住計画」という非営利プロジェクトを立ち上げるこにとした。「世界中からシリコンバレーに集まって切磋琢磨する技術志向の若者たちと一緒になって、日本の若者たち一万人が活躍しているイメージ」を頭に描きながら、その実現のための支援を二十年がかりで行っていこうというものだ。

梅田氏はシリコンバレーで日本人技術者が極めて少ないことに危機感を抱き、このようなプロジェクトを考えられたわけですが、私も同じような危機感を持っています。

数年前、インドに行った際、当時のインド開発センターのディレクターとのディナーで、日本やインドについての教育についての話になりました。

「Tak(彼も私をこう呼びます)、日本では大学を卒業した後、どのくらいの学生が米国企業に就職するんだい?」。

私ははじめこの質問をマイクロソフトのような外資系企業に就職する学生のことを聞いているのかと思ったのですが、よくよく聞いてみると、実はそうではなく、日本を出て、米国で就職する学生の割合を聞いていたのです。私は以下のように答えました。

「日本では日本企業や米国の外資系企業に就職し、会社から米国に出向や派遣されるケースはあるかもしれないが、初めから米国での就職を考える学生はあまりいないよ。僕の時代とは違うから少しは増えているかもしれないけど、ほとんどいないんじゃないかな。」

「そうか。じゃあ、たとえば、クラスに100人同級生がいた場合、何人くらいが米国に行くのかな?」

「う~ん。5名いれば多いほうだと思うよ。」(こう答えましたが、5名もいないだろうと当時の私は思っていました。)

「インドでは半分以上の学生が大学卒業後、インドを出て、米国で職を得るよ。」(半分というのは不確かです。ただ、かなりの割合だったと思います。)

当時、すでにインドは IT 立国として知られていましたので、別段驚くまでも無かったのですが、一方で日本のあまりにも島国的な、ボーダーレスな流動性の無い状況に改めて気づかされた覚えがあります。

インドのすごいところは、一方的な人材流出が起きているだけでなく、きちんと還流もされている点です。インド滞在中にインド開発センターの全体会議に参加する機会を得ることができました。驚いたのは会議の最初に「今月のレッドモンドからの帰国者」というようなコーナーがあったことです。レッドモンドとはこのブログを読んでいる方ならご存知の通り、マイクロソフトの本社の場所です。マイクロソフト本社に行かれたことがある方は、非常に多くのインド人が働いていることをご存知だと思いますが、その何人もが、しばらく本社で働いた後、インドに開発センターができたならということで、インドに戻ってきているのです。

日本においてもこのようなことができたら、なんて素敵でしょう。シリコンバレーやレッドモンドのような環境で武者修行し、日本に戻ってきて、日本の IT 産業への貢献を行うのです。

最後に、ついでに一言。シリコンバレーやレッドモンドにまでは行けないという人は是非、マイクロソフトの日本の開発グループに来てください。勤務場所こそ米国ではありませんが、レッドモンドと同じような環境で開発を経験できます。興味のある人はこちらへ :-)。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月29日 21:11


衛藤です。
セキュリティチームの Blog でも紹介されていた Windows Vista で実装された情報漏えい対策に最適な新機能を紹介します。一言でいうと、USB キーのようなリムーバブル ストレージ デバイスの使用制限です。
少し経緯をお話しますと、去年初頭からあるセキュリティプロジェクトを発足させいろいろな活動を行っていました。その成果の一部が、「情報漏えい対策ガイド (Windows 編)」であり、今回紹介する Vista の新機能になります。Windows のような巨大な製品に新機能や仕様変更のリクエストを行うのは、結構大変な作業でそれなりの覚悟と根気と信念が必要になります。技術的な事ばかりではなく、その機能を追加することにより何・誰がどのように幸せになるのかを示す・正当化するための材料をたっぷり揃えなければならない場合もあります。この情報漏えい対策の機能追加に際しては、情報収集はそれほど苦労しませんでした。当時は、個人情報保護法全面施工前ということもあり、毎日のように何らかのニュースがあり、毎日どこかでセミナーが開催され、オンラインソースだけでなく数多くの書籍も出版されました。情報漏えいというトピックに関しては、まさに情報の宝庫でした。もちろん実際にいろいろな方々からフィードバックを頂いたことがもっとも後押しになりました。調べているうちに日本ほど過熱していないものの、こういった需要は日本に限らずあらゆる国でもニーズがあることもわかりました。そこで「情報漏えい対策ガイド (Windows 編)」を英訳して英語版もリリースしました。

今回のリムーバブル ストレージ デバイスの使用制限は、2つに大別できます。1つはデバイスのインストールを制限する機能で、もう1つはデバイスのアクセスを制限するものです。どちらにも共通して譲れなかった点は、これらの使用制限の設定を中央集中で構成できるようにすること、すなわちグループポリシー経由で利用できることです。

デバイスのインストール制限は、所定のデバイスIDにマッチするデバイスをインストールできないようにする、またはその逆といったような設定が可能です。シナリオ例としては、ある企業では個人情報漏えいを防ぐために USB フラッシュメモリの使用は原則禁止とされている。しかし、全面禁止にしてしまうと生産性に影響が出るためファイルを暗号化して格納する機能を有しているデバイスを会社推奨とし、それに限り使用を許可するといった事が、単なる約束事ではなくグループポリシーで設定できるようになります。これらのポリシーは、gpedit.msc で見ると、コンピュータの構成->管理用テンプレート->システム->Device Installation->Device Installation Restriction にあります。実際の具体的な手順は "Step-By-Step Guide to Controlling Device Installation Using Group Policy" (英語) を参照ください。

もう1つはデバイスのアクセスを制限する機能です。こちらは、コンピュータに対してとユーザーに対してのどちらでも設定可能になっています。設定は、CD/DVD, フロッピー、リムーバブルディスクなど各リムーバブルストレージ毎に読み込み拒否や書き込み拒否の設定が可能です。すべてのリムーバブルストレージデバイスの読み込み/書き込み拒否を行うポリシーも用意されています。読み込みを拒否して書き込みは拒否しないというシナリオはあまりないかも知れませんが、こういった設定も一応できます。これらのポリシーは、gpedit.msc で見ると、コンピュータの構成とユーザーの構成それぞれの下の管理用テンプレート->システム->Removable Storage Access にあります。

情報漏えい対策に利用できる新機能としては、これ以外にもいくつかありますがそれはまたの機会に。今後も日本発でワールドワイドで使えるような新機能を沢山追加すべく頑張ります。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月28日 20:21


及川です。

February CTP で復活したサイドバーですが、標準ではまだわずかなガジェットしか用意されていません。標準で用意されていないのならば、自作してみましょう。今までは http://microsoftgadgets.com/Build/?にある2つの資料が主なものでしたが、MIX06 の Hands On Lab の資料が公開されましたので、その手順に沿って、実際のガジェットの開発も試せます。こちらです。どうぞお試しください。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月27日 22:18


及川です。

「で、何やってんの?」

時は1週間ほど前。場所は東京某所。私の高校の同窓会で、久しぶりに会った友人から、名刺交換の後、聞かれた質問です。私が現在マイクロソフトに勤めていると知ったので、いったい何をやっているのかと思ったようです。

「Windows の開発」

「スタートメニューとか作ったのは及川?」

「…」

確かに、Windows ほどの開発になると、その開発グループで勤めている言われても、具体的にどういう仕事をしているかイメージが沸きにくいかもしれません。

マイクロソフトの開発グループにはいくつかの職種がありますが、良い機会なので、日本の Windows 開発グループで働くエンジニアの主な職種について、ご紹介しましょう。

プログラムマネージャ

プログラムマネージャはプロジェクトを成功に導くために必要な作業の調整を行います。これには、マーケティング部門とともに行う市場調査/分析、市場ニーズの把握、製品の計画立案、製品の仕様策定、製品スケジュールの作成と管理など、製品の初期のプランニングからリリースまでのすべての作業を含みます。

日本におけるプログラムマネージャは日本市場に対する深い造詣を持ち、米国をはじめとするコンポーネントの開発チームとの密接なコミュニケーションをとる能力が要求されます。

この職種は、マイクロソフト社内では PM と楽して呼ばれます。ただし、マーケティングにプロダクトマネージャという職種があり、こちらも略すと PM と呼ばれることがあるため、それとの誤解を避けるためにプログラムマネージャを PGM と呼ぶこともあります。

プログラムマネージャについての説明はこちら(ごめんなさい。英語です)をご覧ください。

ソフトウェアデザインエンジニア

一般にソフトウェア開発というと想定されるのがこの職種でしょう。狭義のソフトウェア開発者と言った場合、このソフトウェアデザインエンジニアを指すことが多いと思います。

ソフトウェアデザインエンジニアはソフトウェアのデザインを考え、コードを書くことを担当します。プログラムマネージャとともに仕様を決定し、全体のビルドプロセスなどにも影響を与えます。

この職種は、マイクロソフトでは SDE もしくは単に Dev と略して呼ばれます。

ソフトウェアデザインエンジニアについての説明はこちら(ごめんなさい。英語です)をご覧ください。

ソフトウェアデザインエンジニア/テスト

ソフトウェアデザインエンジニア/テストもしくはソフトウェアデザインエンジニア イン テスト。英語で書いたほうがわかりやすいと思いますが、Software Design Engineer in Test - すなわち、テスト作業におけるソフトウェアデザインエンジニアがマイクロソフトではテストを担当します。

ソフトウェアテストというと、特に日本の IT 業界では、たとえば、開発者の書かれたテスト指示書にしたがって機械的に確認作業だけを行うような単純な作業を想定されることが多いようですが、マイクロソフトにおけるソフトウェアテストはそのようなものではありません。

開発の段階からソフトウェアの機能を理解し、テスト計画書を作成し、テストを実行します。最終的に製品の出荷を決める段階でも、ソフトウェアテストからのゴーサインが必須になっており、その意味ではプログラムマネージャやソフトウェアデザインエンジニアと同じか、もしくは品質に関してはそれ以上の責任を負った職種となっています。

以前はソフトウェアテストを担当するエンジニアはソフトウェアテストエンジニアと呼ばれていたのですが、ここしばらく間で多くのエンジニアがソフトウェアデザインエンジニア/テストに変更されました(部署によって異なりますが、Windows ではそうです。まだ名刺などの変更が追いついていないケースもありますが)。これはソフトウェアテストにおいてもできるだけ自動化を進め、穴(テストホール)の無い、効率の良いテストを実施するためにエンジニアに要求される内容が変わってきたことの表れです。現在では多くのソフトウェアデザインエンジニア/テストがテスト自動化ツールを開発し、実行するようになっています。

この職種は、マイクロソフト社内では SDET もしくは SDE/T と略して呼ばれます。

ソフトウェアデザインエンジニア/テストについての説明はこちら(ごめんなさい。英語です)をご覧ください。

日本の役割

このように、日本の Windows 開発グループからも、PM、SDE、SDET の3種類の職種のエンジニアが Windows Vista、Longhorn Server などの開発に参加しています。担当しているのは、日本が受け持っているコンポーネントの開発、日本でしか行えないコンポーネントやシナリオのテスト作業、日本のパートナー様と共同で開発/評価を行うようなコンポーネントに対する作業などです。いずれの場合も、製品の機能を理解し、日本のユーザーやパートナーの方がお使いになるのに適した形になるようにすることを念頭において作業しています。ですので、PM や SDET も仕様を理解し、それに沿って日本側の計画を立てることになりますが、一方的に米国本社の計画に従うだけでなく、日本側から仕様を提案したり、仕様変更の指示を出したりします。また、日本固有の機能の場合には、日本主導で開発を行ったりもしています。

また、ベータに参加していらっしゃる方は日本にベータオフィスがあるのをご存知だと思いますが、このようにベータを通じて日本のユーザーやパートナーの方々とコミュニケーションをとるのも重要な役割の1つです。ソフトウェアエコシステムという言葉がありますが、このエコシステムを健全に育むのも、私たち日本側の開発チームの役割となります。

?

というようなことを、かいつまんで友人には話したのですが、さて、理解してもらえたでしょうか。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月26日 22:45


及川です。

以前、Teredo について紹介しました。Teredo によりピアツーピアに必要な NAT 越えが実現できることについて説明させていただきましたが、では Teredo 対応のアプリケーションはどのように開発すれば良いのでしょうか?

方法は2つあります。1つは Windows Peer-to-Peer API を用いてアプリケーションを作成する方法。もう1つは WinSock でソケット作成時にソケットオプションとして IPV6_PROTECTION_LEVEL? を設定する方法です。

前者の Windows Peer-to-Peer API は IPv6 を前提としています。もし IPv6 のネイティブ接続環境があれば、それをそのまま利用しますが、もし無かった場合には Teredo の接続を用います。したがって、Windows Peer-to-Peer API を使っている場合には、特別な処理は必要ありません。

WinSock アプリケーションの場合には、setsockopt() で IPV6_PROTECTION_LEVEL? を設定します。 IPV6_PROTECTION_LEVEL は次のいずれかの値をとります。

  • PROTECTION_LEVEL_UNRESTRICTED
  • PROTECTION_LEVEL_DEFAULT
  • PROTECTION_LEVEL_RESTRICTED

PROTECTION_LEVEL_UNRESTRICTED は同一サイトにおける接続のみを許可するオプションです。ここで言う「同一サイト」とは IPv6 のリンクローカルアドレスで接続できる場合、IPv6 グローバルアドレスを使っている場合は、プレフィックスから同一サイトと判断できる接続の場合、そして IPv6 サイトローカルアドレスで接続できる場合となります。ただし、IPv6 サイトローカルアドレスは廃止されています(RFC 3879 Deprecating Site Local Addresses)。Windows では互換性のために機能としては残っていますが、使用は推奨されていません。ご注意ください。

PROTECTION_LEVEL_DEFAULT は同一サイトおよび外部との接続を許可するオプションです。現在の主な IPv4 アプリケーションと同じ挙動をするオプションになります。

PROTECTION_LEVEL_RESTRICTED は PROTECTION_LEVEL_DEFAULT の動作に加えて、NAT を介しての通信、すなわち Teredo での通信を許可するオプションとなります。

以上のことを整理したのが以下の表となります。

保護レベル 受信トラフィックの制限の有無
同一サイト 外部 NAT?越え (Teredo)
PROTECTION_LEVEL_RESTRICTED 不可
PROTECTION_LEVEL_DEFAULT 不可
PROTECTION_LEVEL_UNRESTRICTED

オプションを指定しなかった場合は、PROTECTION_LEVEL_DEFAULT の挙動となります。つまり、開発者の意図しない NAT を越えての受信は起こりえないようになっています。

詳しくは MSDN のサイトの説明をご覧ください。

また、.NET の System.Net を使っている場合は、Socket.SetSocketOption メソッドを使ってオプションを指定することになります。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月25日 18:59


及川です。

IEBlogでも紹介されていますが、Internet Explorer Developer Toolbar Beta2 Preview Updateが公開されています。この IE Developer Toolbar は Toolbar という名前のとおり、IE のツールバーとしてインストールされるもので、主に Web サイトデザイナー向けに Web ページの構造などを解析を手助けするものです。

IE Developer Toolbar をインストールすると、下の画面のようにツールバーが追加されます(クリックすることで拡大されます)。

上の赤で囲まれている部分がツールバーによって追加されたメニューです。この例では、[View DOM] をクリックし、Web ページの DOM 構造を表示させています(下の赤で囲まれている部分です)。このほかにも テスト目的で IE の設定のいくつかを選択的に無効にすることもできますし、テーブル (Table) やイメージなどのオブジェクトを枠をつけて表示させることなどもできます。

くわしくはダウンロードページの説明をご覧ください。

まだ Beta2 ですので、是非お使いいただき、フィードバックをいただければと思います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月24日 22:28


及川です。

先日、ペルソナについて紹介しましたが、そこに ishisaka さん@OPC Diary から次のような質問が(トラックバックで)されていました。

Windows Vistaの開発にはペルソナ法が使われているとのこと。実際に使用方法とかが記事にされて出てくると面白いだろうな。
何人ぐらいのペルソナを使っているんだろう。。

残念ながら、あまり詳しいことは言えないのですが、ペルソナは仕様書のシナリオを書く部分で使われています。たとえば、あるコンポーネントがある場合、どのようなユーザーにどのように使ってもらうことを想定しているかを記述するときなど、ユーザーの細かい特性などを記述する代わりに Windows Vista で使うことが決まられているペルソナを用いてシナリオとして書かれます。

また、今の時期だと、新たに仕様書が書かれることは少ないのですが、デザインチェンジという仕様変更が行われることはまだあります。デザインチェンジにもきちんとした承認がしかるべきチームにより与えられる必要があります。そのデザインチェンジの妥当性を説明する場合にも、ペルソナを用いて利用シーンの説明が行われます。

ペルソナの用いられ方はプロジェクトごとの違いはあまりありません。前回の投稿に2つほどマイクロソフト リサーチが公開しているレポートを紹介させていただきましたが、そちらをご覧になると、もっと詳しく使われ方がお分かりになるかと思います。

また、人数については、残念ながら明かせません。同じく、前回の投稿で紹介しているレポートの中にポスターがあり、そこに一部のペルソナの顔などが出ていますが、少なくともその人数よりは多いと考えていただいて結構です。また、Longhorn Server では私の頭では覚えきれないほど(数え切れないほどではありません)の数のペルソナがいたことだけはヒントとしてお伝えしておきます。

ご質問&コメント、ありがとうございました。これからもよろしくお願いします。

P.S. 初めてのトラックバックです。ちゃんと動くでしょうか。どきどき…。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月23日 17:41


及川です。

Windows Peer-to-Peer の連載ですが、進みがゆっくりなので、Windows Vista での新機能について紹介するまで、少し時間がかかりそうです。その代わりと言ってはなんですが、マイクロソフト本社の担当者による Windows Vista のピアツーピアや Collaboration 技術についての WebCast があります。英語で恐縮ですが、興味のある方は是非ご覧ください。

Channel 9 >> The Videos >> Vista Collaboration

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月22日 15:48


及川です。

Windows Peer-to-Peer や MAX の解説でも出てきたように、マイクロソフトではピアツーピア通信を実現するために IPv6 の利用を推進しています。

ご存知のように、現在の IPv4 での通信ではすべてのホスト(ノードと言ったほうがピアツーピアの説明では良いかもしれません)にグローバルアドレスを割り当てることは現実的ではありません。特に家庭内のネットワークでは、複数の PC や情報家電を持っていたとしても、2つ以上のグローバルアドレスを ISP から取得していることは稀でしょう。そのため、NAT と言われる技術が使われることになります。

NAT は1つのグローバルアドレスで複数のホストをインターネットに接続することを実現しましたし、また家庭内外のセキュリティバウンダリとして、不必要なインバウンドの接続を遮断することにも成功しました。しかし、その一方で、NAT が介在することにより、インターネットでの通信が非対称となり、それによりもともとインターネットが持っていたピアツーピアの環境が失われてしまったこともまた事実です。

現在、もっとも一般的なインターネットの使われ方と言われる Web アクセスやメールなどでは、NAT は問題にはなりません。なぜなら、これらはクライアント/サーバー形アプリケーションであり、NAT 配下のホストがクライアントとして振る舞い、サーバーである HTTP サーバーや POP?および SMTP サーバーにアクセスするからです。NAT では NAT 配下のホストから通信が発生する場合には、そのアウトバウンド通信に対応するインバウンド通信のためのルールが NAT 内のマッピングテーブルに生成されます。しかし、ピアツーピアアプリケーションのように、どのアプリケーションからインバウンドの通信が発生するかわからない状況では、NAT はその通信を阻害する要因となります。

この NAT によりピアツーピア通信が阻害されてしまうことを俗に「NAT 越え問題」もしくは「NAT トラバーサル (NAT Traversal)」と呼びます。マイクロソフトでは、この NAT 越え問題を解決するために、UPnP (Universal Plug and Play) の IGD (Internet Gateway Device) を利用したルータの普及を業界各社とともに進めてまいりました。Windows XP?が UPnP のコントロールポイントとして動作することにより、必要なマッピングルールを IGD、すなわち NAT ルーター(またはブロードバンドルーター)に生成することができます。この UPnP を用いた NAT 対応のピアツーピア機能は MSN Messenger や Windows XP のリモートアシスタンスなどに使われています。

このように、UPnP?を利用することで NAT 対策が可能になったのですが、これにもまだ問題がありました。1つはすべてのルーターが UPnP 対応になっていることは期待できないことです。残念ながら、市場には UPnP 対応と言いながらも、実態は MSN Messenger など一部の主要なアプリケーションの動作だけしか保証していない NAT ルーターが多くあります。このような場合、アプリケーションが UPnP 対応をしても、NAT ルーターによって、動作したりしなかったり、その結果は神のみぞ知るということになりかねません。また、もう1つの問題は、アプリケーション側の対応が必要という点です。アプリケーション開発者にとっては、単にインターネットアプリケーションを書くだけで、NAT が介在しようが、それとも直接インターネットに接続されていようが、同じ挙動をしてくれたほうが良いに決まっています。しかし、UPnP に対応するためには、開発者が UPnP を意識したコードを書く必要があります。

そこで、マイクロソフトが考えたのが、IPv6 を用いたピアツーピアを実現する方法です。ただ、IPv6 は一般には ISP をはじめとする通信事業者により提供されている回線を購入する必要があります。これはネイティブ IPv6 環境と言われるものです。マイクロソフトはこのネイティブ IPv6 が無い環境、つまり IPv4 環境でも IPv6 を使えるようにするトンネリング技術を実装しました。トンネリング技術には、6to4 や ISATAP などいくつかの技術がありますが、どれも NAT が介在する家庭のような環境では簡単には使うことはできません。そこで、マイクロソフトが新たに開発したのが、Teredo という IPv4 の UDP を使うトンネリング技術です。

簡単に説明すると、Tereodo は UDP を使うことで、NAT 越えを実現します。Teredo Server と呼ばれるインターネット上のサーバーを仲介者とすることで、NAT のマッピングテーブルに「穴」を開け、それを利用して UDP/IPv4 通信を実現し、その上に IPv6 トンネルを構築します。一口に NAT と言っても、その種類は Cone NAT、Restricted Cone NAT、Port-restricted Cone NAT、Symmetric NAT の4つに大別することができます。Teredoは、このうち、Symmetric NAT には残念ながら対応できません。しかし、マイクロソフトの実装では、UPnP IGD の技術を併用していますので、市場の NAT ルーターのおよそ95%ほどに対応できています。

今回は、ピアツーピアを実現するにあたって、必要となる IPv6 トンネリング技術-Teredo について書かせていただきました。本来でしたら、Teredo の仕組みについて書くべきなのですが、少し複雑で1回で書くことはできそうにありません。実は、以前、IPv6 Style に記事を書かせていただきましたので、詳しくはそちらを参照していただければと思います。なお、この記事では、Advanced Networking Pack for Windows XP をインストールすることで Teredo が利用できるようになると解説していますが、以前の投稿で書かせていただいたように、Advanced Networking Pack for Windows XP の機能はすべて Windows XP SP2 に含まれています。したがって、現在、SP2 を利用されているユーザーの方は追加でのパッケージの導入は必要ありません。

そのほか参考資料を以下に紹介しますので、あわせてご参照ください。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月21日 15:44


及川です。

本日はWindows Peer-to-Peer のアーキテクチャを解説します。

Windows Peer-to-Peer は以下の図にある6つのコンポーネントにより構成されます。

P2P Architecture

  • グラフィング (Graphing)
    「グラフ(Graph)」とは接続されたノードの集合を示します。グラフィングコンポーネントはこのグラフの管理とグラフ内のデータの配送と管理を行います。
  • グルーピング (Grouping)
    グルーピングコンポーネントはグループの作成、グループへの招待、グループへの参加などのセキュリティ機能をグラフに対して提供します。グルーピングコンポーネントは次に説明する PNRP (Peer Name Resolution Protocol) による名前解決と探索を利用しています。そのため、複数のアプリケーションが同一のグラフを共有することができます。
  • NSP (Name Service Provider)
    NSP はその名が示すように、名前空間を実現するサービスプロバイダです。Windows Peer-to-Peer では NSP を介して PNRP が利用されます。
  • PNRP (Peer Name Resolution Protocol)
    Windows Peer-to-Peer における名前解決を実現します。ピアツーピア環境では DNS 名 (FQDN) を使えません。そこで PNRP を用いた名前解決が実現されています。
  • 識別マネージャ (Identity Manager)
    識別マネージャはピアツーピアにおける識別子の作成や管理を行います。
  • Microsoft TCP/IP バージョン 6 プロトコル (IPv6 プロトコル)
    Windows Peer-to-Peer では IPv6 通信が利用されます。IPv6 のネイティブ通信が実現されていない環境では、UDP/IPv4 を用いたトンネリング技術である Teredo を利用して IPv6 接続を行います。

以上の6コンポーネントが Windows Peer-to-Peer を構成するコアコンポーネントとなります。Windows Peer-to-Peer コンポーネントは通常の Win32 のアーキテクチャに沿って設計されているため、上位のアプリケーションインターフェイスは Win32 を、下位のネットワーク部分は WinSock を用いています。また、今後の連載で解説しますが、ピア間の認証については、CAPI (Crypto API) を用いた公開鍵暗号方式が採用されています。

次回からはそれぞれのコンポーネントについてさらに解説を行います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月20日 23:46


及川です。

Windows Vista は製品のプランニングの時期を含めると数年以上前から開始されているプロジェクトですが、そのプランニングや各コンポーネントのデザインには「ペルソナ」と言われる手法が用いられています。

ペルソナとは心理学者ユングが定義した「社会に適応する行動」を意味しますが、製品のデザインにおいては、製品を使うであろう将来のユーザーをできるだけ詳細に思い描いた仮想のユーザーのことを言います。ペルソナは仮想ユーザーではありますが、現実にいるユーザーを代表するものでなければいけません。そのため、フォーカスグループと言われるユーザーインタビューや膨大なマーケットデータなどを元に、ペルソナは作られます。ペルソナはアランクーパー氏が提唱したものであり、多くの会社ですでに用いられていますが、マイクロソフトではこの概念をさらに拡張し、ほかのユーザービリティ手法とともに製品開発に用いています。

Windows のような製品の場合、製品の利用者となるユーザーは1種類ではありません。IT Pro と呼ばれるようなシステム管理者、Information Worker と呼ばれるオフィスでの知的労働者、さらにはコンシューマーユーザーまで複数に分類することができます。実際には、これらの中でさらに、いくつかの層に分類されます。たとえば、IT Pro もヘルプデスクのサポートスタッフから全社の情報システムに対する意思決定を行うような管理職までさまざまな種類のユーザーが存在します。Windows Vista の開発では、考えうる一般的なユーザーをすべてペルソナとして、あたかも実在しているかのように定義することが行われました。

用意されたペルソナは製品の各機能の使われ方を説明する際のシナリオとして用いられます。シナリオはユーザーの利用シーンと言っても良いかと思いますが、具体的にどのような環境や状況で、誰がいつ使うのかを説明したものになります。たとえば、Windows XP の UPnP (Universal Plug and Play) を説明した文書の中に次のような解説があります。

メアリーはベッドにいて寝るところで、明日は土曜です。いつも目覚し時計は朝 7 時に鳴りますが、明日は寝ていたいのです。起こしてはもらいたいのですが、朝 9 時がちょうどいい時間と思えます。そこで彼女は目覚しを朝 7 時でなく 9 時に設定しました。

メアリーの目覚し時計は UPnP 対応なので快適です。彼女の Windows XP® ベースの PC には、目覚し時計から設定された時刻の通知を受け取るスクリプトがあります。スクリプトは設定変更があると、HVAC デバイスのタイマに起床時刻を目覚し時計と同時刻にセットするよう指示します。

さてメアリーの暖房は、彼女がベッドから起きるときに凍えないよう、早い時刻にスイッチが入るでしょう。インテリジェント エアコン (HVAC) システムがあれば、今ある予約機能つき冷暖房機器をはるかに越えた、多数の機能を追加できるはずです。それにはセンサーが人間を検出するシステムや、インターネット経由でリモート制御するシステムが考えられるでしょう。

目覚し時計が彼女のスケジュールにアクセスできれば、もし会議に遅れる時間に起床時刻をセットしても、メアリーに警告できます。いいかえると会議が朝 9 時で目覚しを朝 9 時にセットすると、9 時の会議に間に合うには朝 8 時に起きなければならないと警告できるようになるかもしれません。

シナリオとはこのような文書です。また、この中に出てくるメアリーがペルソナにあたります。

Windows Vista の開発でも、複数のペルソナがあらかじめ用意され、開発者は Windows Vista にて提供したいと考えている機能のシナリオをこれらのペルソナを用いて説明しました。このようにすることによって、開発者の独りよがりな発想を元にした機能がユーザーの最終的な利用シーンを想定することなく実装されていくことを避けることができました。

Windows Vista での新機能は膨大な数になりますし、機能拡張されたものはほぼすべてと言っても過言ではないほどです。ですが、それらすべてのプランニング段階に、このペルソナとシナリオの手法が用いられ、機能追加や拡張の妥当性を検討していたことをご理解いただければ、これほどまでに開発に時間がかかったこともお分かりいただけるのではないかと思います。

最後に、マイクロソフト リサーチから出ているマイクロソフト社内でのペルソナ手法についての論文を紹介しておきますので、興味のある方はご覧いただければと思います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月19日 23:52


及川です。

Winny ウィルスが猛威を振るっているときになんともタイミングが悪いという噂もありますが、あまり気にせずに Windows Peer-to-Peer の(不定期)連載を開始します。

さて、Windows XP SP2 を使われている方が多いと思いますが、皆さんのその Windows の中に Windows Peer-to-Peer という機能が含まれていることにどれくらいの方が気づかれているでしょうか。SP2 を導入してある Windows で [Windows コンポーネントの追加と削除] から [ネットワーク サービス] の [詳細] を見てみてください。次の図のように、「ピア ツー ピア」 というコンポーネントが見つかると思います。

実は、この Winodws Peer-to-Peer は SP2 の前に Advanced Networking Pack for Windows XP という名称の追加ソフトウェアとしてリリースされていました。SP2 では、この Advanced Networking Pack の機能がすべて含まれています。

Windows Peer-to-Peer はその名のとおり、Peer-to-Peer 通信を実現するためのインフラ機能を提供します。Peer-to-Peer 通信を利用したアプリケーションとして、マイクロソフトでは次のようなものを想定しています。

  • リアルタイムコミュニケーション
  • コラボレーション
  • コンテンツ配信
  • ?分散処理

リアルタイムコミュニケーションは MSN Messenger をはじめとするインスタントメッセンジャーや VoIP のようなアプリケーションです。現在、多くのリアルタイムコミュニケーションは見た目は Peer-to-Peer であっても、実態はサーバーを介した、いわゆる「なんちゃって Peer-to-Peer」で実現されています。たとえば、MSN Messenger の場合でも .NET Messenger Service により通信は行われています(実際にはサービスやユーザーの通信環境によりその通信方法は異なります)。このようなリアルタイムコミュニケーションも Peer-to-Peer で実現することができたならば、たとえばインターネットに接続できないようなアドホックネットワークの環境でも利用することができます。

コラボレーションはユーザー間の共同作業や情報共有のためのアプリケーションです。マイクロソフトの Exchange Server のようなグループウェアはいわゆるクライアント/サーバーのアプリケーションですが、一方で Peer-to-Peer をベースとした Groove Virtual Office のようなものも提供されています。Groove では Exchange Server のような専用のサーバーは不要ですので、たとえば複数の企業のメンバーにより構成されるプロジェクトでの情報交換や共同作業のための環境を簡単に構築することができます。また、悪いイメージが定着してしまっているようですが、ファイル交換アプリケーションなどもコラボレーションの一種と考えることができます。

コンテンツ配信はストリーミングやパッケージの配信や配布を行うような利用形態になります。たとえば、Windows Update や Microsoft Update ではマイクロソフトのサーバーから更新パッケージをダウンロードします。たとえ、すぐ隣のマシンにすでにその更新パッケージがダウンロードされていても、サーバーからダウンロードするしか方法がありません。もし Peer-to-Peer でこの更新パッケージの配信を行うことができたならば、近くにすでにそのパッケージを保持するマシンがあったならば、そこから入手することができるようになります。

分散処理はグリッドコンピューティングとも呼ばれるアプリケーション形態です。複数のマシンの空いた時間を利用して、大規模な数値計算を行うようなアプリケーションは現在でも多く提供されています。しかし、これらは基本的にサーバーからタスクを分割し、それをクライアントマシンに配布し、結果を再度サーバーにアップロードするという方法がとられています。もし、Peer-to-Peer を用いることができれば、隣接するマシンの負荷状況に合わせてタスクを効率よく分散することもできるようになるでしょう。

ここでは4つほど一般的に考えられる Peer-to-Peer アプリケーション例を説明しましたが、実際にはこれら以外にも多くのアプリケーションが出てくることが期待されます。現在のインターネットアプリケーションは、NAT などにより Peer-to-Peer の実現が阻害されていることもあったため、クライアント/サーバーの形態をとることが多くなってしまっています。Peer-to-Peer が利用できるようになれば、今までに考え付かなかったような新しい形態のアプリケーションが出てくることが期待できます。

今回はマイクロソフトの考える Peer-to-Peer のシナリオについて紹介させていただきましたが、次回は Windows Peer-to-Peer の構成要素について説明する予定です。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月18日 0:26


衛藤です。

知っている人は知っている。でも知らない人は名前すら聞いたこともないかもしれない。という事で、今日は Microsoft® コードネーム Max を紹介いたします。(とは言うものの、実はこれって我々のグループが担当している訳ではないので、詳しい訳ではない…)
Microsoft Codename Max
Max Web サイトの紹介文にもありますが、現時点では Max を使って写真をスライドショー付きで共有したり、ニュースを読んだりできます。What will Max do next? とあるように最終形でどのようなものになるのかは、今後のお楽しみということにしておきます。

Max はネットワーキング部分でいうと、Windows Communication Foundation?(Indigo と呼ばれていたもの) 上にインプリメントしており、IPv4 は勿論 IPv6/Teredo もサポートします。これは、もしこれらが利用可能であればサポートするという事であり、Max のセットアップが IPv6/Teredo をインストールするという意味ではありません。もっともビジュアル的にインパクトがある部分は、やはり Windows Presentation Foundation?(Avalon と呼ばれていたもの) を駆使した部分ではないでしょうか。写真のレイアウトを動かすときに、まわりの写真がぐにょぐにょ動くさまは見ていて実に爽快です。この爽快度はビデオの性能に依存します。Max 画面の左下にある About をクリックし、そこで表示されるダイアログで Max Graphics: High と表示されたら爽快度を堪能できます。そうでない場合もそれなりにストレスなく動作します。

Max で写真を共有してもその写真がどこかのサーバーにストアされるといった事はありません。言い換えれば、もしあなたがサインオフしていると、友人はあなたの共有した写真を見てダウンロードすることができないということになります。My lists や Other people's lists の「どの写真がどの誰からのどのリスト」といった類の情報は、%USERPROFILE%\Local Settings\Application Data\Microsoft\Microsoft Codename Max\Store.xml に格納され、アカウントに関する情報は、Settings.xml に格納されます。これらのストア形式は、今後のリリースで変更されるかも知れません。共有されたリストの内容に変更を加えると、その変更は相手側にもきちんと反映されます。既定では同期は1時間毎ですが、Other people's list を明示的にクリックすればすぐに同期されます。

先日、新しいベータ版がリリースされ、この最新版でようやく日本語版の XP での動作が可能になりました。システム要件やダウンロードはこちら です。システム要件にも書かれていますが、WinFX Runtime Components December CTP が必要です。もし December CTP 以前の WinFX ベータ版がインストールされていたら、先ずそちらをアンインストールする事をお勧めします。インストール時間は、WinFX の分も考えるとそれなりに時間がかかりますが、それは現時点異常ではありませんのでご心配なく。

ところで Max 日本語版はあるの?というのが気になるところですよね。計画はあるそうですが、スケジュールは現時点では言えないそうです。もう1つ気になる点としては、Windows Vista 上での動作だと思います。残念ながら現在のバージョンでは、Vista 上では動作しませんが近い将来動作するようになるでしょう。そうなればインストールもずっと楽になりますね。
UI はかなりかっこいいと思いますので、ご興味のある方はぜひお試しください。私の環境では大きな問題もなく動作していますが、あくまでベータ版ですので、自己責任ということで...

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月16日 19:32


及川です。

ターミナルサービスの話を前回書かせていただきましたが、今回はそれから派生して、アプリケーションの作法について書きたいと思います。

「行儀の良いアプリケーション」、英語では Well Behaved Application と言うのですが、これらはマイクロソフトが Windows をアップグレードした場合やサービスパックを提供した場合にも、あまり大きな問題の発生しないアプリケーションです。「行儀が良い」とはちょっと失礼な言い方かもしれませんが、マイクロソフトが推奨した方法で開発されているアプリケーションは Windows 側に変更があった場合でも、あまり大きなインパクトを受けません。

前回、ターミナルサービス対応のアプリケーションが当初少なく、アプリケーションごとにスクリプトを用意する必要があったという話を書かせていただきました。ターミナルサービスの場合は、変更が大きかったため、まったく修正せずにターミナルサービスに完全に対応するというアプリケーションは正直少なかったのですが、それでもアプリケーションの作りによって、ターミナルサービス上で動作させたときの影響は大きく異なりました。たとえば、%SystemRoot% の下にユーザーデータを置き、それを排他制御もせずにオープンするような振る舞いをするアプリケーションがあったとします。この場合、複数ユーザーで同時にそのアプリケーションを動作させると、 %SystemRoot% の下のユーザーデータは排他制御もされずに同時にアクセスされることになりますので、正常動作は当然期待できません。場合によっては、データを破壊してしまうこともあるでしょうし、ほかユーザーのデータが見えてしまうかもしれません。もちろん、正しい方法はユーザーごとに、My Documents の下にデータを置いていただくことになります。こう聞いて、「そうか、My Documents の下か!」と言って、My Documents というのをハードコードで書かかれては、今度は Windows Vista では動作しなくなります(Windows Vista では My Documents のようなスペシャルフォルダの名前規則が変更されています)。正解は Shell API (SHGetFolderLocation) を使っていただくことです。

紹介した例はきわめて簡単な例で、いまどき My Documents をハードコードしているようなアプリケーションは無いとは思いますが、このようにアプリケーションが API を正しく使ってない場合は、Windows のバージョンアップやサービスパックで影響を受ける可能性が極めて高くなります。逆に、正しく API を使っている場合は、たとえアプリケーションの修正が必要になった場合でも、最小限の書き換えで済ませることができます。

どのようにして「行儀の良いアプリケーション」を書けば良いかですが、もっともお勧めの方法は Designed for Windows ロゴのための仕様書を見ていただくことです。Designed for Windows はソフトウェアやハードウェアでマイクロソフトによるある基準を満たしたものにつけられているロゴですが、これはマイクロソフトのマーケティングキャンペーンではありません。きちんとした技術的な基準を設定させていただき、これを満たしたものにだけ発行させていただいているものです。Windows Vista でもさまざまな新機能や変更を加えさせていただいておりますが、その影響はロゴを取得しているアプリケーションでは、ロゴを取得していないアプリケーションとは比べ物にならないほど小さいです。ですので、開発者の方は是非、Designed for Windows ロゴ取得を、最低でもアプリケーション仕様書に目を通すことはしていただきたいと思います。それが Windows Vista への対応の第一歩となります。

  • Windows XP までの Designed for Windows アプリケーション仕様書はここにあります。
  • そもそも、ロゴってな~にという方はまずこちらからご覧ください。
  • Windows Vista 向けのアプリケーション仕様書はまだドラフトですが、こちら(ごめんなさい。まだ英語だけです)にあります。

是非ご参照ください。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月15日 20:09


初めまして。衛藤です。
ここはウィンドウズ開発統括部の Blog だが、このグループは及川という人間しかいないのかと疑いをそろそろかけられそうなので登場しました。

個人情報保護法が全面施行されてからもうすぐ1年になろうとしていますが、情報漏えいの問題は相変わらず後を絶たないようです。我々 Windows 開発統括部でも情報漏えい対策について何か行おうという事で、昨年8月に「情報漏えい対策ガイド ( Windows 編 )?」というホワイトペーパーをリリースしました。これは正真正銘日本発のドキュメントです。おかげ様で大好評を頂いており、技術情報のホワイトペーパーとしては異例のダウンロード数を記録しています。ちなみに日本以外の国からも沢山要望があったので、英語版もリリースしました。もしまだでしたら、ぜひご一読を。

以外と知られていないのが、この「情報漏えい対策ガイド ( Windows 編 ) 」のアンケートサイトです。このアンケートサイトですが、3月いっぱいで終了する予定になっています。(ホワイトペーパーは引き続き提供されます)? どの程度役に立ったとかどの内容が良かったといった数分程度の簡単なアンケートですので、ぜひ皆様のご感想やご意見、ご要望ををお寄せください。お寄せ頂いたアンケート結果は、私がすべて目を通しています。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月13日 13:31


及川です。

今日は Windows Server に搭載されているターミナルサービス、そしてそのクライアント版ともいえる Windows XP のリモートデスクトップと私とのかかわりについてお話してみようと思います。

私がマイクロソフトに入社したのは今から 9 年前のことですが、入社前よりすでにマイクロソフトがマルチユーザー対応の Windows を開発しているということは話題になっていました。ここで言う、マルチユーザーというのは、1 台のマシンで同時にデスクトップ画面を表示させ、ウィンドウ操作を実現することです。そのころからすでに、Windows (Windows NT) は当時の商用レベル最高の C2 レベルセキュリティを備えており、複数ユーザーをきちんと別のセキュリティエンティティとして区別していました。また、それを用いた ACL(アクセス制御リスト)も完備されており、比較されることの多かった UNIX (R) などと比べても恥ずかしくないマルチユーザー対応はされていました。しかし、UNIX では Telnet や R コマンドなどでコマンドベースのリモート管理、さらに X ウィンドウによるマルチユーザー ウィンドウシステムも当たり前のように利用されていたことを考えると、1 台のマシンを複数ユーザーで同時利用するという意味でのマルチユーザー対応は自社からはまったく提供できていない状況でした。

また、当時の IT 業界には、ある 1 つのトレンドがありました。TCO というキーワードで代表される管理コスト低減です。それを実現するためにという理由で、業界にシンクライアントブームが起き、一説には PC 不要論というものまで出る始末でした。ブラウザと Java (TM) があれば PC のようなファットクライアントは必要ないというような論理がメディアでも大きく取り上げられたことは当時業界にいらっしゃった方なら、まだ覚えていらっしゃるのではないでしょうか。PC が不要というのは、ちょっと行き過ぎにしても、定型業務や特殊作業環境下などでは、PC ではなく、もっと軽量なクライアントが必要という確かに事実であり、それに対し、マイクロソフトは自社製品だけでは応えられていなかったのです。

ユーザーからの要求も強くなり、シンクライアントという業界の流れもある中で、マイクロソフトの取った戦略は、当時 Windows NT 上でマルチユーザー機能を提供していた Citrix Systems とライセンス契約を結ぶというものでした。Citirx Systems は当時、WinFrame (R) という名前で Windows のマルチユーザー対応を実現していました。WinFrame (R) は ICA という優れたプロトコルを持ち、Windows のみならず、ヘテロジニアス(非均一)な環境でのクライアントにも対応できていたため、UNIX (R) マシンからでも Windows の画面にアクセスすることができました。マイクロソフトはこの Citrix Systems からライセンスを受け、それをベースに Windows NT Server 4.0 Terminal Server Edition というものを開発したのです。これが現在のターミナルサービスおよびリモートデスクトップの最初です。

Windows Server のマルチユーザー環境とは簡単に言うと、通常ビデオカードからディスプレイに表示され、マウスとキーボードを入力デバイスとするデスクトップ環境を複数動作させ、コンソールと呼ばれる物理的にそのマシンに接続されているディスプレイやキーボード、マウスによるデスクトップ環境以外のセッションをネットワークを介したほかマシン上で実現するというものです。このために、マイクロソフトは RDP (Remote Desktop Protocol) というプロトコルを開発し、さらに 1 つの Windows 上で複数ユーザーが共存するため OS の修正を行いました。

画面出力をコンソールではなく、ほかマシン(クライアント)に出力させるには、RDP を用いて、画面データをクライアントに送ることになります。これだけ書くと、そう難しいことでは無いように思われるかもしれませんが、実は実用的なパフォーマンスを保った上でこのようなことを行うにはいくつもの最適化が必要となります。あまりオープンになっていないことだと思うので、詳しくは書けませんが、1 つのテクニックとして用いられているのが、クライアント側のキャッシュになります。画面の一部に更新がかかるたびにすべてのウィンドウ情報を送っていては、それこそまるで月面との間で動画をやりとりするようになってしまいます。そこで、クライアント側にウィンドウコントロールをキャッシュしておき、キャッシュにある情報についてはサーバーから送信するのではなく、キャッシュ上の情報を使うようになっています。実は、さらに日本語版ではある仕組みを取り入れようとしていたのですが、最終的にその仕組みを入れることなく、現在にいたっています。ここに書けないのが残念ですが、その機能を入れるか入れないかについて、ネットワーク上のトラフィック量、実際の描画速度などを計測し、結果的に実装しないでも十分なパフォーマンスが出る(むしろ実装しないほうがパフォーマンスが出る)という結論に至ったのですが、今日のターミナルサービスのパフォーマンスを見るとそのときの決断が間違っていなかったと思います。

キーボードの入力をクライアントから行うことも実は裏ではいろいろなことが行われています。ターミナルサービスでは、ネットワーク上はキーボードのスキャンコードがクライアントからサーバーに送られています。これは、スキャンコードから実際の仮想キーコードにするのは、サーバー側の処理になることを意味します。つまり、サーバー側にスキャンコードを適切な仮想キーコードに変換するためのキーボードドライバがロードされていなければならないのです。たとえば、サーバー側には US キーボード(101 キーボード) が物理的に接続されていたとしても、クライアントのユーザーが 106/109 キーボードを使っていたならば、サーバー側のセッションでは 106/109 キーボード用のキーボードドライバがロードされなければなりません。このために、ターミナルサービスでは接続時にキーボードタイプのネゴシエーションが行われています。実は、日本のように、スキャンコードそのものが 101 キーボードと異なるようなキーボードというのは世界ではほかに韓国など一部の国でしか使われていません。キートップの刻印が違っても、スキャンコードそのものは 101 キーボードと同じという国がほとんどなのです。そのため、日本語版の開発では、この部分でも工夫が必要でした。当時は日本でもキーボードが 106/109 だけでなく、富士通の親指シフトや NEC の PC-9800 キーボードなど、まだ複数のキーボードが使われていた時期でしたので、私の机には一時それこそ秋葉原のジャンクショップのようにいろんな型のキーボードが置かれていたものです。

Windows OS 本体でも複数ユーザーの同時ログインを実現するために、いくつもの変更が行われました。その 1 つがセッションという考えの導入です。繰り返しになりますが、それまでの Windows では物理的に接続されたコンソールのみがデスクトップ環境を実現するものでした。そこに複数ユーザーが同時にデスクトップを利用することができるようにするため、セッションという考えが導入されました。それにあわせてカーネル部分にも変更が加わりました。Windows は 4GB の仮想メモリ空間のうち、2GB をシステム空間として、残りの 2GB をユーザー空間として利用していましたが、複数ユーザーが同時に利用するため、このユーザーの 2GB 部分が複数存在することになります。しかし、いくつかのエリアは異なる複数ユーザーが同時に利用するとは言っても共通な部分となります。そこで導入されたのがセッションスペースという考えになります。

また、Windows のシステムフォルダなどへのアクセスをリダイレクトするために新しい API も導入されました。ただ、製品発売当初はこれらの API を正しく使ってくれるものはあまりありません。そこで、アプリケーションをターミナルサービス上で正しく動作させるためのスクリプトが提供されました。この部分も日本語化で苦労したところです。ある外資系のソフトウェアなどは製品名もバージョンも本社のものと違っており、英語版の Terminal Server Edition で提供されているスクリプトを完全に書き直す必要さえありました。スクリプトとは言っても、当時は WSH がシステムに導入されていることを前提にはできなかったので、基本的にすべてバッチコマンドでスクリプトは作られています。当時の担当者はスクリプト開発作業でリリースすることにはすっかりバッチの達人になっていました。

最初の Windows NT Server 4.0 Terminal Server Edition では以上のような作業を私を含め日本側のチームで行いましたが、実は、私の入社時の面接では、この Terminal Server Edition(当時はまだ Hydra という開発コード名で呼ばれていました)について、日本でどういう作業が必要になるかを質問されました。Terminal Server Edition というものを良く理解していなかったのですが、幸運にも、ここで述べたような内容のいくつかを答えることができ、無事入社することができました。その意味でも、私にとって、ターミナルサービスは思い入れの強いコンポーネントです。

その後、Windows NT Server 4.0 Terminal Server Edition は Windows 2000 でメインストリームの OS に統合され、そして、Windows XP ではリモートデスクトップという名前でクライアントにも組み込まれるようになっています。あと、気づかれていないかもしれませんが、リモートアシスタンスの機能もこのターミナルサービスの機能を用いていますし、Windows XP(ドメインに属していない場合)のユーザーの切り替え機能(ファーストユーザースイッチング)もターミナルサービスでの複数同時セッションをベースとしたものです。はじめは限られた用途だったターミナルサービスの機能がこのようにクライアントも含め、一般的に用いられる機能になったのは、当初からこの製品、コンポーネントを見てきたものとしては感慨無量です(ちょっと大げさですが)。

Windows Vista や Longhorn Server でも、このターミナルサービスの機能はさらに強化されて実装されてきます。そのうち、このブログでも紹介できると思います。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月11日 19:15


及川です。

業界の主にハードウェア関係の開発者向けの開発会議である WinHEC が今年も開催されます。今年は 5/23 から 5/25 までワシントン州シアトルで行われます。

毎年、この WinHEC では Windows 向けのコンピュータシステムやデバイスの開発のための最新情報を提供させていただいています。開発者の皆様、特にハードウェアに関連している方々は是非ご参加をご検討ください。

なお、3/27 までに申し込むと、割引料金が適用されます。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月9日 15:10


及川です。

昨日の投稿でも触れましたが、Windows Vista や Internet Explorer は Web 2.0 といわれる新しい潮流で用いられる技術を標準で実装しています。その技術の 1 つで、Ajax の実現に欠かせないのが、クライアント側の XMLHTTP サポートです。

XMLHTTP はクライアント側で単に HTTP でデータの送受信を行う(レンダリングは必要ない)というような用途のために開発されました。Internet Explorer では 以前より? MSXML の ActiveX オブジェクトとして実装されています。

このように、バージョン 6 までの Internet Explorer でも XMLHttpRequest はサポートされていたのですが、今回の Internet Explorer 7 での変更点は、ActiveX ではなく、標準で XMLHttpRequest が実装された点です。

皆さんもご存知のとおり、ActiveX は Web クライアントの世界に新しいユーザーエクスペリエンスを実現しました。しかし、一方で ActiveX を用いたセキュリティ上のさまざまな問題が起きているのも事実です。お客様によっては ActiveX を無効にしている場合もあるでしょう。このようなクライアントでは、Ajax アプリケーションを使いたくても、使えない環境に今まではあったわけです。

Internet Explorer で標準で XMLHTTP がサポートされることにより、セキュリティ上の管理基準を変更することなく、Ajax などの新しい Web アプリケーションを使っていただくことができます。

XMLHTTPRequest を使ったスクリプトは次のような形になります。

if (window.XMLHttpRequest) { // ネイティブで XMLHttpRequest をサポートしているブラウザ
var xmlHttp = new XMLHttpRequest();
} else if (window.ActiveXObject) { // Inetnet Explorer
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP")

}

2 つめの "else if (windows.ActiveXObject)" という部分が ActiveX としてXMLHttpRequest を実現している部分ですが、Internet Explorer 7 ではここではなく、1 つ目の "if (windows.XMLHttpRequest)" のブロックのほうが実行されます。したがって、Internet Explorer 7 にクライアントを限定できる場合は、この IF ブロックは不要です。単に XMLHttpRequest オブジェクトを生成すれば良いことになります。ただし、既存 Web アプリケーションとの互換のために、ActiveX オブジェクトとしての XMLHTTP は残されています。

ActiveX オブジェクトとしての XMLHTTP も残っていることから、ぱっと見た目、あまりインパクトが無いかもしれませんが、今までは会社のセキュリティポリシーにより ActiveX が使えなかったユーザーの方はすなわち Ajax も使えていなかった可能性が高いです。今回の XMLHTTP の標準サポートは地味ながら非常に意味のある機能拡張でしょう。

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。
投稿日時: 2006年3月9日 1:37


及川です。

10 人に聞いたら 10 通りとまでは言いませんが、3 通りくらいは別々の定義が聞けそうな Web 2.0 ですが、今日はこの Web 2.0 と Windows Vista の関係について考えてみましょう。

Web 2.0 は Web をプラットフォームとしてとらえた概念です。RSS?による配信や?Ajax による高い操作性を持つ Web アプリケーションなどが Web 2.0 の具体例としてあげられます。また、マッシュアップという複数のコンテンツや Web サービスを組み合わせて提供されるアプリケーションも Web 2.0 の要素として注目を浴びています。

Web 2.0 では、Web がプラットフォームになるということで、クライアントとしては必要最小限のブラウザーがあれば十分という考えを持つ人がいるかもしれませんが、本当にそうでしょうか。

たとえば、Ajax。XMLHTTPRequest をサポートし、JavaScript が動作し、DHTML がサポートされていれば、クライアント側は十分です。しかし、快適な操作性を実現するためには、やはりクライアント側にも高い処理能力が必要です。また、現在は JavaScript と DHTML がブラウザへの要件となりますが、さらに高性能なユーザーインターフェイスを追求した場合、ブラウザではなく、別の Web クライアント(この場合の Web クライアントとは Web 2.0 の概念でクライアントとなりうるアプリケーションという意味)がユーザーとの対話を受け持つということも起きえるのではないでしょうか。Windows Vista では、Windows Presentation Foundation (WPF)Windows Communication Foundation (WCF) により、そのようなアプリケーションを開発することができます。Web がプラットフォームになるということ、すなわちクライアント側はブラウザと限定する必然性は無いですし、そのように発想を制限してしまうと、Web の持つ可能性も制限してしまうことになるように思います。

また、マッシュアップですが、Windows Vista に実装されるサイドバーのガジェットをマッシュアップのためのプラットフォーム技術と考えることもできます。サイドバーのガジェットは DHTML で書かれます。標準のガジェットには RSS フィードを受けるものもあり、いくつかのガジェットはローカルマシン上だけで動作を完了するのではなく、インターネットを介して、Web サービスと連携したり、配信されるコンテンツを受信したりするものとなることでしょう。そもそも RSS などに関しては、Windows Vista では RSS フィード技術(RSSの受信機能)が単にブラウザなどのアプリケーションの 1 機能としてでなく、OS の標準サービスとして実装されます。これにより、サイドバー以外にもさまざまな機能で利用されることが予想されます。

以上、多少強引な