Hebikuzure's Tech Memo

2013年1月26日

Windows 8 の IE10 で 32ビット版のアドオンが利用できない

Filed under: Internet Explorer — hebikuzure @ 8:00 PM


32-bit browser applications may not work as expected in Internet Explorer 10
http://support.microsoft.com/kb/2716529/en-us


Windows 8 の 64ビット版の既定の動作では、デスクトップの Internet Explorer はトップレベルのウィンドウ フレーム (ブラウザーのクロムの部分) は 64ビット プロセスの iexplore.exe となり、ページを表示する各タブのプロセスは 32ビットの iexplore.exe が利用されます。そのため 32ビット版のアドオンが問題なく利用できるはずです。ただし拡張保護モードを有効にすると ([インターネット オプション] – [詳細設定] – [拡張保護モードを有効にする]) 、タブのプロセスも 64ビットになり 32ビット版のアドオンは利用できなくなります。

ところが拡張保護モードを有効に設定していないのに、32ピット版のアドオンが利用できない場合があります。上記のサポート技術情報ではこの現象とその理由について解説しています。

この現象は以下のレジストリ値が構成される場合に発生します。

  • キー : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
  • 名前 : TabProcGrowth
  • データ : 0

Internet Explroer 8 以降のバージョンでは Loosely-Coupled IE (LCIE) と呼ばれるプロセス モデルが採用されており、前記のようにフレームのプロセスと各タブのプロセスは分離されています。また各タブごとにもそれぞれ別のプロセスが割り当てられます。この動作については「Japan IE Support Team Blog – IE8 のプロセスモデルについて」に解説されています。このページにも書かれているように、TabProcGrowth レジストリ値はタブのプロセス分離の動作を制御するもので、0 に設定すると LCIE が無効になり、IE7 以前と同じようにフレームとページの表示が同じ一つのプロセスで行われます。

Windows 8 の 64ビット版でこの設定になっていると、フレーム プロセスである 64ビット プロセスの iexplore.exe がページの表示にも利用される動作になります。つまりページは 64ビット プロセスでレンダリングされるため、32ビット版のアドオンは利用できなくなります。

この問題を回避するには、TabProcGrowth レジストリ値を削除するか、0 以外のデータに変更します。この手順は技術情報のページに掲載されている Fix it でも可能ですし、手動でレジストリ エディタを利用しても可能です。

TabProcGrowth レジストリ値を 0 のままにしておかなければならない場合は、64ビット版のアドオンを利用する必要があります。

広告

2013年1月20日

ASP.NET サイトを新しいブラウザーに対応させるための Hotfix

Filed under: Internet Explorer — hebikuzure @ 9:46 PM

ASP.NETではクライアントから送信される User-Agnet 文字列を解析してブラウザーを判定する機能があるのですが、この判定ロジックが .NET Framework に組み込まれているため、新しいブラウザーの判定が正しく行えない場合があります。具体的には Internet Explorer 10 の “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)” という User-Agnet 文字列が処理できません。

そのため、.NET Framework を新しいブラウザーに対応させるためのHotfix (修正プログラム) が出ています。そろそろ Windows 7 用の IE10 もリリースされそうですから、今のうちに IE10 でもサイトが正しく機能するよう準備しておいた方が良いですね。

Hotfix は以下のサポート技術情報からダウンロードできます。

2013年1月17日

Internet Explorer 10 でリンク プレビューを指定する

Filed under: Internet Explorer — hebikuzure @ 11:10 PM

この記事では Windows 8 の Internet Explorer 10 と、Windows 8 の [共有] 機能について解説しています。

Internt Explorer 10 と Windows 8 の [共有]

Windows 8の新しいユーザー インターフェースでは、アプリ間の「共有」の仕組みが搭載されています。「共有」がどのような物か、スマートフォンのユーザーなら理解しやすいでしょうが、実行中のアプリで表示されている情報を他のアプリに送信し、情報を「共有」する仕掛けです。共有する相手はローカルのアプリに限らず、というよりむしろソーシャルなアプリ (例えば Facebook、Twitter、Google+、LinkedIN など) への投稿が意識されています。「共有」を行うには、チャームを呼び出して [共有] をタップ (クリック) します。

共有チャーム

この操作が行われると、Windows ストア アプリは別のアプリで利用可能な形式のデータを作成し、Windows に渡します。[共有] チャームで共有先のアプリを選択すると、Windows は受け取ったデータを共有先のアプリに引き渡します。そこから先は共有先のアプリの処理になりますが、例えばクラウド上のワークスペースへの書き込みや、SNS への投稿などがを行うことができます。では Windows 8の新しいユーザー インターフェースの Internet Explorer 10 で Web ページを表示している時に「共有」のアクションを行うと、共有できるデータとしてどのような物が作成されるのでしょうか。

Internet Explorer 10 では、ページ内のコンテンツが選択されている時に [共有] が呼び出されると、選択されている範囲のデータが共有データになります。こうした共有を「明示的な共有」と呼びます。これに対して何も選択されていない時に [共有] が呼び出されると、現在表示しているページを示す 2 つの形式のデータを作成します。このような共有を「暗黙的な共有」と呼びます。

暗黙的な共有で作成される 1 つめの形式は現在表示しているページの URL です。

http://www.youtube.com/watch?v=TtbrLIwKWWA

URL を共有すれば、例えば SNS で特定のページを多くの人に知らせたり、あるいは自分の備忘録としてページを記録しておくことができます。ただし Internet Explorer で作成されるデータは URL の文字列だけで、ページの内容に関する情報は含まれません。そのため共有先のアプリでは (そのアプリ内で独自に URL のリンク先ページのプレビューやタイトルの取得ができるような機能が無ければ) リンクの文字列だけしか表示されません。そのため、ページの内容を明確にしたい場合、別途説明を書き込んだり投稿する必要があるでしょう。

もう 1 つの形式は、リンク プレビューと呼ばれるデータです。リンク プレビューは現在のページのイメージが含まれるHTMLデータです。このデータの形式は Windows ストア アプリで共通しています。

リンク プレビュー

リンク プレビューには以下のような情報が含まれます。

  • ページの URL
  • ページ タイトル
  • 説明文
  • ページの画像

共有先のアプリケーションがリンク プレビューに対応していれば、リンク プレビューのデータを利用して共有するページを示す表示が行われます。例えば次のスクリーンショットのように、People アプリを共有先として選択して Facebook に投稿する場合、リンク プレビューのデータが利用されます。

Facebook に共有

URI だけ共有するのではなく、リンク プレビューを共有するメリットは、ユーザーが共有しようと思ったページの内容をより具体的に示し、わかり易い形で状態で共有できることです。こうしたメリットが活用されるように、Internet Explorer 10は暗黙的な共有が行われると、常にリンク プレビューを作成します。

共有データを受け取る側のアプリでは、そのアプリの動作や目的に適したデータを利用できます。Facebook のような Web ベースのサービスであれば、共有されているページの情報をより理解しやすくするためリンク プレビューを利用することが適切でしょう。しかし単純なテキスト メッセージングであれば、単純な URL のデータだけを利用した方が良いかもしれません。このように共有可能なデータのうち何を利用するかは、共有先のアプリで決めることができます。

注 共有先のアプリでの処理方法については「共有のためのデータ形式の選択(JavaScriptとHTMLを使ったWindowsストア アプリ)」(http://msdn.microsoft.com/ja-jp/library/windows/apps/hh771179.aspx)に詳しい解説があります。

リンク プレビューの作成

Internet Explorer 10は [共有] の操作が行われると、表示中のページを解析してリンク プレビューを作成します。解析では、まずリンク プレビューの内容について指定するマークアップが存在するかどうか調べられます。もしそれらが存在していれば、その内容をもとにしてリンク プレビューが作成されます。リンク プレビューの内容を指定するマークアップが存在しなければ、それ以外のマークアップから自動的にリンク プレビューを生成します。

リンク プレビューの内容を指定するマークアップでは、リンク プレビューに含まれる内容ごとにメタ データを定義できます。こうした指定によって、ページが共有された際のプレビューの見栄えがよりよくなるよう調整したり、リンク プレビューに共有先で有益な情報を追加したりすることができます。

リンク プレビューの内容を指定するマークアップと定義できるメタデータは以下の通りです。

プロパティ

HTML タグ

文字数制限

タイトル1

<meta name="title" content="ページのタイトル” /> 160

タイトル2

<title>ページのタイトル</title> 160

説明

<meta name="description" content="ページの説明” /> 253

画像1

<meta property="og:image" content="画像のURI" /> 2,048 (画像 URI の制限)

画像2

<link rel="image_src" href="画像のURI" /> 2,048 (画像 URI の制限)

画像3

<meta name="image" content="画像のURI" /> 2,048 (画像 URI の制限)

画像4

<meta name="thumbnail" content="画像のURI" /> 2,048 (画像 URI の制限)

この表に含まれるマークアップを指定する際に注意が必要なのは、マークアップには優先順位がある事です。この表の表示順はその優先順位を示しています。つまりタイトルについては「タイトル1」(metaタグ)があればそれが優先されて利用され、「タイトル2」(titleタグ)があっても利用されません。画像についても同様で、「画像1」(Open Graphプロトコルでの指定)があれば、「画像2」以下の指定は無視されます。

注 Open Graphプロトコルについては、http://ogp.me/ 参照してください。

もし公開しているページが Windows 8 のユーザーに広く共有される事を期待するのであれば、その共有によるインフルエンスを最大限にするためにも、リンク プレビューが適切に作成されるようこうしたマークアップを記述するべきでしょう。特にプレビューで使用される画像についてはマークアップでの指定が不可欠です。なぜならたいていのページ内にはページ内容とは直接関係しないイメージが多数含まれており、Internet Explorerが自動的に解析した結果は時としてそうしたページのコンテンツの本筋とは関係ない画像を選択する場合があるからです。意図しないような変な画像が表示されたら、せっかくのリンク プレビューも台無しです。

また説明も表示可能な文字数があまり多くないため、内容を的確に要約した説明が指定されているのとそうでないのとでは、共有先での印象が大きく異なります。共有されたページがより魅力的に見えるよう、そしてサイトに実際に訪問してもらえるよう、強くアピールする説明文を指定することが望ましいでしょう。

Web サイトを運営している方、Web サイトの開発者の皆さんは、ぜひリンク プレビューを上手に活用し、サイトへの注目を高めてください。

2013年1月12日

Windows の TCP ウィンドウ スケーリング ヒューリスティック

Filed under: Windows Info — hebikuzure @ 10:56 PM

Hotfix improves TCP window scaling in Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2
http://support.microsoft.com/kb/2780879/en-us


興味深いマイクロソフト サポート技術情報を見つけたので紹介します。

TCP プロトコルではコネクションを確立するために 3 Way ハンドシェイク (SYN –> SYN ACK –> ACK) を行います。クライアントからの SYN にサーバーが応答できなかった場合、クライアントは SYN パケットを再送して再接続を試みますが、Windows 7 以前のバージョンの実装では 2 回目の SYN  再送でサーバーと接続できた場合、このコネクションではウィンドウ スケーリングが無効になります。この動作と、この動作を変更できる修正プログラム (hotfix) について説明しているのが、サポート技術情報 2780879 です。

ウィンドウ スケーリングとは RFC 1323 で定義されている TCP の広帯域ネットワークへの最適化手法で、元々の TCP で設定できるウィンドウ サイズ (送信先からの応答なしに連続して送信できるサイズ) の最大値である65,535 バイトを、1 ギガバイトまで拡張できる方法です。

参考
Windows 2000 および Windows Server 2003 の TCP 機能について
http://support.microsoft.com/kb/224829/JA

なお、Windows Vista / Windows Server 2003 移行のバージョンでは、ウィンドウ サイズは自動調整されるので、上記サポート技術情報に記載されている TCPWindowSize レジストリ値は利用されません。(TCP 受信ウィンドウ自動チューニング http://technet.microsoft.com/ja-jp/magazine/2007.01.cableguy.aspx)

このウィンドウ スケーリングの通知が SYN パケット内で設定されているのですが、上記のように SYN パケットの再送が2回行われると、ウィンドウ スケーリングは無効になり、TCP ウィンドウの最大サイズは 65,535 バイトに制限されます。

この動作を緩和し、より多くのネットワーク環境でウィンドウ スケーリングが機能するよう動作を変更するのが、サポート技術情報 2780879 で提供されているhotfix です。この hotfix を適用すると、netsh コマンドにサブ コマンドが追加され、SYN パケット再送時のウィンドウ スケーリングの動作を指定できます。

  • netsh int tcp set heuristics enabled : SYN パケット再送時のウィンドウ スケーリングを有効にします
  • netsh int tcp set heuristics disabled : SYN パケット再送時のウィンドウ スケーリングを無効にします (既定の動作)

さて、このサポート技術情報と hotfix は対象が「Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2」となっているので、Windows 8 / Windows Server 2012 ではどうなっているのかと思って確認したら、これらの新しい Windows では、既定で上記のコマンドが有効になっており、この機能の事を「ウィンドウ スケーリング ヒューリスティック」と呼んでいました。つまりこの hotfix は Windows 8 / Windows Server 2012 で搭載された TCP の新機能のバックポートだったのです。

この手のバックポートは他にもありそうですし、これからもちょこちょこ出てくるかもしれませんね。

2013年1月8日

Windows 8 では BIOS で日付と時刻を変更しても反映されない

Filed under: Windows Tips — hebikuzure @ 10:48 PM


Changes to calendar date in BIOS is not reflected in Windows 8
http://support.microsoft.com/kb/2792897


Windows 8 がインストールされているコンピューターでは、BIOS でコンピュータのリアルタイム クロックの日付と時刻を変更しても、Windows での日付と時刻にはその変更が反映されない場合があります。これは Windows 8 の仕様です。Windows 8 で日付と時刻を変更するには、Windows のユーザー インターフェイスから変更する必要があります。

上記のサポート技術情報にはこのような仕様となった理由が書かれているので要約すると、実際の時刻は遡る (過去に戻る) ことはないので、Windows で認識している時刻より以前の時刻を BIOS が報告しても、Windows はそうした過去の時刻に戻すことはせず、現在の時刻を保持し続ける動作にしたという事です。そのため時刻を進めるような BIOS での日時変更は、Windows にも反映されます。

この仕様は Windows 8 のみで、Windows 7 以前のバージョンでは BIOS での変更通りに Windows の時刻も変更されます。

ちょっとした事ですが、知らないとトラブルの元になるかもしれない Windows 8 での仕様変更の一つです。

2013年1月6日

Windows To Go 環境への誤認

Filed under: Windows トラブル — hebikuzure @ 10:37 PM

Windows To Go 機能についての詳細は、TechNet ライブラリの記事を参照してください


Windows 8 を利用している際に、何かのきっかけで通常の内蔵ディスク (ハードディスク、SSD) にインストールされている Windows が、Windows To Go で起動されている環境と誤認される場合があるらしいのです。その場合、以下のようなトラブルが発生します。

  • Windows ストアが利用できない
  • 休止状態が無効になる
  • システムのフルバックアップとシステム修復ディスクの作成ができない
  • Windows のリフレッシュができない

それぞれ「Windows ストアは、Windows To Go ワークスペースでは使用できません。」や「この機能は、ポータブルなワークステーション環境では使用できません。」などのエラーメッセージが表示されますので、Windows To Go 環境と誤認されていることが推測されます。またこの現象については以下のように Microsoft Community や TechNet フォーラムでも何件か質問が出ているのである程度の発生頻度があるようです。

これらの質問への回答の中で「My computer thinks it’s a Windows To Go computer but it’s not…」の Rahul Ramadas さん (Microsoft の人ですね) の回答と説明が詳しいので、それについて簡単に解説したいと思います。

Rahul さんによれば、この現象は一時的に接続した USB メモリ デバイスと内蔵ディスクのディスク ID が重複してしまった場合に、Windows が起動しているデバイス (本来は内蔵ディスク) を Windows To Go で利用するリムーバブル メディアであると誤認して発生するようです。Windows で利用しているディスク ID は以下の手順で確認できます (USB デバイスの場合は接続した状態で実行します)。

  1. コマンドプロンプトを管理者として実行します
  2. diskpart を実行します
  3. list disk コマンドを実行します
  4. 表示されたディスク一覧から、ID を表示したいディスクの番号を確認します
  5. select # (# は上で確認したディスクの番号) コマンドを実行してディスクを選択します
  6. unique disk コマンドを実行すると、ディスク ID が表示されます
  7. exit コマンドを実行し、diskpart を終了します

Windows To Go 環境と誤認されている状態を回復するには、以下のレジストリ値を削除するか、データを 0 に設定します。

キー : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
名前 : PortableOperatingSystem

変更後再起動が必要です。

また内蔵ディスクと重複している USB デバイスのディスク ID を削除するには、USB デバイスを接続した上で以下の手順を実行します。ただし USB デバイスの内容が削除されるので、事前に必要に応じてバックアップを取ってください。

  1. コマンドプロンプトを管理者として実行します
  2. diskpart を実行します
  3. list disk コマンドを実行します
  4. 表示されたディスク一覧から、USB デバイスのディスクの番号を確認します
  5. select # (# は上で確認したディスクの番号) コマンドを実行してディスクを選択します
  6. clean コマンドを実行します
  7. exit コマンドを実行し、diskpart を終了します

「6.」の手順で unique disk id=XXXXXXX (XXXXXXX は正しい形式の新しいディスク ID) を実行して新しいディスクID を割り当てることもできるようですが、正しい形式の新しいディスク ID を作成する方法が無いので、基本的には上記のように clean でディスク内容を初期化する方が良さそうです。

現在の内蔵ディスクのディスク ID を調べて、それに +1 するという方法もあるようですが、本当にそれで問題ないのかどうかは不明です。

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。