http://shoda.tk/ それでも私は・・・shoda T.の日常非日常 ja Copyright 2012 Thu, 21 Jul 2011 19:40:51 +0900 http://www.sixapart.com/movabletype/?v=3.21-ja http://blogs.law.harvard.edu/tech/rss 20日（現地時間）、米GoogleはGoogleの実験的なサービスを公開してきた「Google Labs」を終了させると発表した。ラリー・ペイジCEOが第2四半期の業績発表時に打ち出した「製品への集中」の取り組みの一環という。 Google Labsは、Googleの従業員が「20％の自由時間」で開発したβ版のサービスを公開するサイトとして公開されていたもので、Google Mapsや Google Readerなどの多くの正式版のサービスも、Labsで立ち上げられ、同社の自由闊達な社風と多彩なサービスの急速開発の象徴のような存在。 現在も「Body Browser（3D人体模型）」や「Swiffy（Flash→HTML5変換）」など約80のサービスが提供されている。 いくつかのサービスや技術は関連する製品に統合されるほか、Androidアプリは、今後もAndroid Marketでの提供を続けるが、その他のほとんどのサービスは終了する。 Google Labs はGoogle独自のアイデアと云うより、オンラインソフトの開発手法（公開β版→製品化）の Google的展開ともいうべきもので、開発手法や経営的視点からは決して効率の良いものではないでしょう。 実際、Google Mapsなどの成功例よりも、アイデアが実ることなく葬り去られたものの方が多いと思います。特にSNS関係は二転三転を繰り返し、最近になってようやく Google+ と云う形にまとまりつつあるわけですが・・・ その Google+ も、希望者が殺到した（リソースが足りない？）ことを理由に、クローズドなβテストになってしまったようで、このあたりも Google Labs の閉鎖と関係しているのでしょうか。 ただ、開発効率だけを追求するような今回のCEOの決定は、決して Google の将来にはプラスにならないと思います。これを機に「製品への集中」と云う開発者への「締め付け」が強化されれば、スピンアウト（離散）が進むのではないでしょうか。 それはインターネットの開発社会にとっては結果的には良いこととなる可能性はありますが、多くの痛みを伴いますし、Google の変質を促し、そしてこれまで多くの成長企業が辿った道・・・成長から停滞、衰退へ・・・を Googleもたどる可能性を示してもいるわけです。 別の言葉で言えば Google 神話の終焉、でしょうか。 http://shoda.tk/archives/2011/07/google_google_labs.html http://shoda.tk/archives/2011/07/google_google_labs.html ニュースの視点 Thu, 21 Jul 2011 19:40:51 +0900 今月の5日に韓国の高層ビルで原因不明の振動が起き、入居者らが避難する騒ぎとなった原因は、人気エクササイズの「タエボー」だったことが、原因究明に当たっていた建築工学の専門家チームの調査と再現で明らかになった。 調査に加わった専門家は「タエボーによって生じた振動サイクルが、たまたま同ビル特有の上下振動サイクルと衝突した」と説明。これによってビルの振動が増幅され、揺れが生じたという。 「タエボー」というのは、ボクシングとテコンドーを組み合わせたエクササイズで、ポップソングに合わせて行なう。騒ぎの当日は17人がエアロビクスに励んでいたと云う。 たった17人でも、波長が合うとこの騒ぎです。特に高層ビルは耐震のため揺らして振動を吸収する構造になっているため、起こりやすいのでしょう。 それだけに、特定の周波数に過敏に反応しない設計が望まれるところです。 そういえば、以前にもどこか（国内）の新設のドーム（体育館？）の屋根が陥没した原因も、同様の多くの人の運動に伴う振動でした。 また、京セラドームなどでもライブでの観衆のジャンプなどの振動が周辺地域に与える影響が問題になったりしてます。 もっと古い例では、米国タコマ・ナローズ橋が開通４ヶ月で、想定より遙かに弱い19m/sの横風で自励振動を起こし落橋した事故はあまりにも有名です。 対人関係でもそうですね。波長が合うと・・・こちらは良い影響ですが:-) http://shoda.tk/archives/2011/07/post_453.html http://shoda.tk/archives/2011/07/post_453.html ニュースの視点 Wed, 20 Jul 2011 12:38:36 +0900 産業技術総合研究所や明星大などのチームが、打ち水や日本版サマータイム（タイムシフト）について科学的分析を行った結果、都心での電力消費 は減らないことがわかった。 22日からつくば市で開かれる日本ヒートアイランド学会で発表する。 理由としては、職場を早期退社しても、家庭でのエアコン利用が増えるだけであり、オフィスの電力需要は10％程度減るが、逆に集合住宅では27％、一戸建てでも23％程度増加するという。 特に東京の場合、１人暮らしが全世帯の約4割を占めことが、夕方以降の電力消費を押し上げ、エアコンなどの利用効率を悪くしているようだ。 打ち水も、気温は0.6度下がるが、湿度が上がるため、エアコンの負荷は逆に高まるのだという。 たとえば、午後1時に道路1平方メートル当たり1リットルの散水（打ち水）をした場合、オフィスや集合住宅では節電効果がなく、一戸建てでは逆に1％電力消費が増えたと云う。 一方、すだれなどによる日射遮蔽で5％減、エアコンの設定温度の見直し（住宅24.5度→28度、オフィス26度→28度）で5％減の効果があった。 やはりイメージや思い込みだけではなく、キチンとした科学的手法を用いた分析が重要なようです。 原発廃絶論にしても、どうも思い込みだけの水掛け論が多いような気がしますが、もっとさまざまな状況の見直しや、目標を定めての詳細な分析を元にした、腰の据わった議論が必要なのではないでしょうか。 http://shoda.tk/archives/2011/07/post_452.html http://shoda.tk/archives/2011/07/post_452.html ニュースの視点 Thu, 14 Jul 2011 20:50:33 +0900 13日、NTTドコモ、KDDI、沖縄セルラー電話、ソフトバンクモバイルおよびイー・アクセスの5社は、Ｇ３携帯電話のショートメッセージサービス(SMS)の相互接続を開始した。 SMSは、NTTドコモ、ソフトバンクモバイル、イー・アクセスの呼称で、KDDIや沖縄セルラー電話では「Cメール」と呼んでいるが、いずれも全角で70文字程度の携帯電話専用の短いメッセージの送受信サービス。 なおKDDIのS007、T007、CA007、T008、K009ではアップデートにより、これまで全角50文字であったCメールが、他社と同様に70文字まで拡張される。 なんだか唐突な感じがしますし、何を今更感が強いのですが・・・実はこの話は二年ほど前に基本合意が出来たもので、ようやく実現した、と云うところです。時間がかかった理由はよくわかりませんが、設備や技術的すり合わせに時間が必要だったためなのか、あるいは震災を機に・・・なのか。 SMSは音声やメールなどのように音声チャネルを使うのではなく、制御チャネルを使いますので、「軽く」速いだけでなく混雑に強い性質があります。 そのため、震災では音声が非常につながりにくくなったのに対し、SMSでの連絡がスムーズに行えた、という教訓が、相互接続の実現を加速させた面もあるのかもしれません。 ただ、電話番号によるSMSってスパムの温床化しやすく、事業者間が隔絶している国内では、使ってない人も多いのでは？って気がします。 もっとも、海外では事業者間の接続が保証されており、音声やメールに比べて通信料が安いこともあり、さかんに利用されています。 NTTドコモやソフトバンクモバイルでは、海外との他社接続は行っており、海外経由だとドコモとソフトバンク間でもSMSを送れる、と云う変なこともあります。 いずれにしても今更なSMSの相互接続ですが、すでにi-modeメールなどが一般化している国内では、これを機にSMSが普及する・・・ってことは無いような気がしますが、さて？ http://shoda.tk/archives/2011/07/post_451.html http://shoda.tk/archives/2011/07/post_451.html ニュースの視点 Thu, 14 Jul 2011 12:26:15 +0900 5日（現地時間）、米Microsoft は米GoogleのモバイルOS「Android」を搭載した端末に関して、台湾Winstron社と特許ライセンス契約を結んだと発表した。 Microsoft は Winstron から特許料を受け取るが、金額など詳細は明らかにしていない。 このほかにも、Microsoft は Android搭載端末をめぐる特許ライセンス契約をこの二週間で他にも３件結んでいるほか、2010年4月には台湾HTC社とも締結している。 いずれも、個別の特許ライセンスではなく、知的財産権に関わる包括契約とみられ、相手企業としては、事前に特許を巡る訴訟攻撃をかわすことが目的と思われる。 Microsoft は多くの大手企業との訴訟を抱えているが、Android 関連だけでも電子書籍リーダーに関して米Barnes & Nobleと、スマートフォンに関しては米Motorola と係争中である。 Microsoft が Android 関係の特許ライセンス？ 一見すると奇妙に思われますが、それだけ Microsoft はOSやデバイス制御、あるいは携帯端末に関する特許を多数保有している、と言うことでもあるのでしょう。特許問題は、特にWinstron等の中小ベンダーに取っては悩ましい問題ですし、Microsoft等の大手企業が正面から攻めて来たら一たまりもないほど重要な問題でもあります。多少なりとも出費が嵩んだとしても、事前に包括契約した方が、長期的には得策だとの判断があるのでしょう。 また、Microsoftと包括契約を結ぶことは、同様に特許訴訟攻撃に熱心な Apple への対抗と云う意味合いもあるようです。いざとなれば、Microsoftが後ろ盾となってくれるだろう、と云う読みもあるのでしょうか。 http://shoda.tk/archives/2011/07/microsoft_android.html http://shoda.tk/archives/2011/07/microsoft_android.html ニュースの視点 Thu, 07 Jul 2011 01:22:51 +0900 1日、日本ネットワークセキュリティ協会（JNSA）は2010年の日本国内での個人情報漏えい事件に関する調査結果を公表した。 それによれば、公表・報道された個人情報漏えい事件（事故）は1,679件、漏えいした個人情報の総数は557万9,316人分にも及ぶという。 また、漏えい原因で最も多かったのは「管理ミス」で、全体の36.3％、誤操作が32.3％、紛失・置き忘れが12.6％と続き、盗難は7.6％であった。 漏えい経路としては紙媒体が全体の7割弱を占めているが、数量（人数分）としては全体の7％程度で、逆に件数は少ないが数量的には半数近くがインターネット経由となっている。 他国はわかりませんが、少なくとも日本ではまだまだ管理ミスや誤操作など、人災的なものが多いようです。 逆に云えば、マニュアルや手順を整備し、訓練を徹底すると同時に、システムを整備すれば、防げるものが多数だということですね。 http://shoda.tk/archives/2011/07/500.html http://shoda.tk/archives/2011/07/500.html ニュースの視点 Mon, 04 Jul 2011 21:45:50 +0900 6月29日（現地時間）、米News Corporationと広告ネットワークの米Specific Mediaは、ソーシャル・ネットワーキング・サービス（SNS）の「MySpace」をSpecific Mediaに売却したことを明らかにした。 両社合意条件のもと、NewsはSpecific Mediaの少数株主となる。米メディア各社によれば、Specific Mediaは約3500万ドルを支払うという。 MySpace.comは1998年にオンラインストレージサービスとして運用開始。 ところがこの種のサービスは違法コピーの温床だという非難や、ユーザ数の伸び悩みなどが原因で2001年に閉鎖された。 現在のMySpace.comは2003年に創設、一部をeUniverse社（その後Intermix Mediaに社名変更）が保有していた。両者（MySpace）については同じメンバーが創設・運用を行なっていたとする記事と、全く関係がないとする記事が存在し、関係は不明だが、いずれにしてもIntermix Media社自体は、2005年時点でMySpaceの他にも複数のサイトを運用しており、これらのWeb資産が目的でNews社が5億8000万ドルでIntermix Media社を買収した。 しかし News社はここ数年急激に業績が悪化しており、ようやく回復の兆しは見えるものの、MySpace は一時はSNSのトップを極めたものの、その後はFaceBookの台頭に業績は低迷、News社の業績悪化の一因とも謂われ、売却の噂が絶えなかった。 詳細はわからないが、推測されている金額や元の買収金額などから考えてもIntermix Media社全体というより、MySpace部門だけの売却のようだ。 買収したSpecific Media社は、ディスプレイ、ビデオ、モバイル広告などを組み合わせた広告ネットワークの会社で、元々SNSと云うより、音楽関係のプロモートなどへの活用が主であった MySpace を、音楽だけでなくショーやビデオ等も含めたメディアの広告媒体としての活用を考えているようだ。 http://shoda.tk/archives/2011/07/newsmyspace.html http://shoda.tk/archives/2011/07/newsmyspace.html ニュースの視点 Fri, 01 Jul 2011 01:16:32 +0900 めむ・フレッシュ Ver 1.50β ]]> http://shoda.tk/archives/2011/06/gismo_memfreshener_ver_150.html http://shoda.tk/archives/2011/06/gismo_memfreshener_ver_150.html めむ・フレッシュ Tue, 21 Jun 2011 21:56:48 +0900 15日、東京地裁は、ロス疑惑の容疑者として2008年に逮捕され拘留されたロサンゼルス市警の留置場で自殺した三浦和義さんの妻が、産経新聞とヤフーを相手取って名誉棄損で訴えていた訴訟について、原告側の主張の一部を認め、両社に対して計66万円の支払いを命じた。 訴訟は2008年に YAHOO!JAPAN に掲載した写真（1985年当時の手錠姿の三浦氏）や同記事で名誉を傷つけられたとして計660万円の損害賠償を求めたもの。ヤフーは産経の記事と写真を無批判に転載したことで同罪を問われた。 松並裁判長は「記事の内容から、（手錠姿の）写真を公表する必要性は乏しい」として写真について名誉棄損を認めた。一方、記事の掲載は不法行為にあたらないとして訴えを退けた。 産経新聞はともかくとして、契約に基づいて転載したヤフーに対しても名誉棄損を認めた判決は初めてで、もしこのまま判決が確定すれば、自動的に、あるいは契約上取捨選択権なしで転載しているサイトなどにも影響が及ぶとみられる。 ヤフー側は訴訟で「記事などが第三者の権利を侵害するものではないと配信元が保証している」と免責を主張したが、認められなかった。 別件だが、今年4月に最高裁は、共同通信社が配信した記事の掲載による賠償責任をめぐる訴訟で、配信元が真実と信じる相当の理由があれば、掲載した加盟社も名誉棄損の不法行為責任を負わない」との判決を下している。どちらの判決が優勢になるか、注目していく必要はあるだろう。 http://shoda.tk/archives/2011/06/post_450.html http://shoda.tk/archives/2011/06/post_450.html ニュースの視点 Thu, 16 Jun 2011 12:12:32 +0900 14日、BCNはパソコンなどデジタル機器の市場動向に関する説明会を開催。 パソコンの販売台数は前年同月比で4月が119.6％(金額ベースで104.2％)、5月が118.5％(同104.5％)と2ヶ月連続で2ケタ増となったと発表した。 同社は全国の大手家電販売店のPOSデータを基にデジタル機器の販売台数や金額情報を集計・提供している。 3月は東日本大震災の影響ばかりでなく、米インテルの新型チップセットに不具合が見つかり春モデルの出荷が遅れたことなどが影響して、販売台数ベースで95.5％（販売金額ベースで88.2％）まで落ち込んでいた。 http://shoda.tk/archives/2011/06/post_449.html http://shoda.tk/archives/2011/06/post_449.html ニュースの視点 Wed, 15 Jun 2011 17:05:35 +0900 14日、NTTドコモは6日に発生したネットワーク障害の原因および今後の対策について発表した。 障害は約13時間におよび、関東甲信越地域で契約した172万人が通話やパケット通信できない状況に陥った。障害はドコモユーザだけでなく、ナンバーポータビリティ制度（MNP）で他社に移ったユーザも着信出来ない現象が発生した。 障害が発生したのは「サービス制御装置」と呼ぶ携帯端末の位置情報を管理するシステムで、対象となった端末の位置が把握出来なくなったため、他の電話からの着信を最寄の基地局に受け渡せなくなった。 MNPで移転したユーザも、番号そのものはドコモの管理下にあり、ドコモから移転先へ受け渡すが、MNP対象の番号かどうかの情報も同じ制御装置に格納されているため、影響を受けた。 NTTドコモによれば、3日に機能追加のために制御装置のソフトウェアの更新を行ったが、その際、本番テストを兼ねて40台ある制御装置のうち一台だけを更新。6日夕方にはテストを終え、残りの39台にも実施する予定だったが、6日朝8時27分にハードウェア故障が発生。 ソフトに不具合が見つかった場合は更新前の状態に戻す設計になっていたため、テストそのものは正常だったが、ハード故障を検知しため、設計通りに以前の状態に戻す処理を行った。これがたまたま通勤時間帯に重なったことなど（電車などで移動中のユーザが多く、位置情報の更新が多い）から処理に遅延が発生した。 このサービス制御装置は二重化されており、所謂ホットスタンバイ構成になっている。そのため、本番系が処理に時間がかかっていることを待機系が検知して、待機系に切り替わってしまった。 ところが切り替わった場合には、位置変更のない端末の情報もすべて強制的に更新する仕様になっているため、さらに負荷が増え輻輳（ふくそう）状態（物が1ヶ所に集中し混雑する様態）に陥ってしまった。 午前9時26分には通信規制を実施したがあまり効果はなかった。「待機系のシステムになんらかの不具合があるのでは？」と考えたドコモは、正常に稼働していた本番系への切り替えを検討、午後0時46分に本番系への切り替えを実施した。 しかしこれにより再び大量の位置情報更新が発生し、輻輳状態が続いた。 さらに通信規制を強化し、待機系への切替判定ソフトの機能もオフにし、負荷状態を見ながら、徐々に規制を解除していった。午後6時52分になってようやく通常状態に戻すことが出来たという。 ところが・・・時間に注目してほしい（苦笑） 機能復活した本番系と待機系の切替判定ソフトが、オフにしていた期間の履歴を参照し、処理遅延など不安定な状態が続いたと判断。ここで再び 待機系へ切替 → 大量の位置情報更新 → 輻輳状態 というループに突入したのだ。 結局、再び通信規制を行い・・・午後9時36分になってようやく規制解除を行って正常状態に戻した。 http://shoda.tk/archives/2011/06/ntt_4.html http://shoda.tk/archives/2011/06/ntt_4.html ニュースの視点 Wed, 15 Jun 2011 12:10:49 +0900 64bits Windows で32bitsアプリの振る舞いについては別項で詳細に論ずるとして、ここではレジストリへのアクセスについてまとめる。 基本的には特別なことをしなくても、32bits Windows 上と同様に扱うことが出来る。 ただし、それは HKEY_CURRENT_USER 下に関してのことで、それ以外のルートノードに関しては若干の注意が必要。 まず特筆すべきは、HKEY_LOCAL_MACHINE\SOFTWARE ノード下へのアクセス。 32bits アプリ（on WOW64）でここへアクセスすると、一見何の問題もないかのように読み書き出来る。したがって、そのアプリだけが読み書きするキーやエントリーだけであれば、何の問題も起きない。 しかし実際に読み書き出来ているのは、HKEY_LOCAL_MACHINE\SOFTWARE 下ではなく、 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node と言う、特殊なキーの下へリダイレクトされている、と言うことに注意する必要がある。 したがって問題になるのは、他のアプリ（64bits版）や Windows システムと共用するレジストリエントリである。 そういうケースはあまりないと思われるが、最も可能性の高いのは HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion などへのアクセス。 ここには、Windows に登録してある所有者名や会社名、あるいは、Windows のバージョン情報等が書かれている。 そしてなぜか、32bitsからアクセス出来る Wow6432Node 下の方には、たとえば所有者や会社名として「Microsoft」が登録されており、ProductId 等は設定されていない。 通常、これらを参照する機会は少ないかもしれないが、一部のデータについては他に読み取るAPI等がないことや、コントールパネル等からも設定変更出来ないので、直接操作したいという需要はある。 もちろん、Wow6432Node と言うノードを直接指定してアクセスするという手はあるが、汎用性、ポータビリティなどからは問題だ。 そこで 64bits Windows では、これを回避するための手段が用意されている。 #define KEY_WOW64_64KEY 0x0100 これは LONG WINAPI RegCreateKeyEx(HKEY hKey,LPCTSTR lpSubKey,DWORD Reserved,LPTSTR lpClass,DWORD dwOptions,REGSAM samDesired,LPSECURITY_ATTRIBUTES lpSecurityAttributes,PHKEY phkResult,LPDWORD lpdwDisposition); において samDesired で指定するマスク値で、これに KEY_WOW64_64KEY を or 指定した場合に、64bits Windows としてのネィティブな値にアクセス出来るようになる。 指定しなければ、HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node ノード下が HKEY_LOCAL_MACHINE\SOFTWARE ノード下に直接見える。 ただし、このマスク値に対しては 64bits 版 Windows 以外の環境では定義されていないので、指定しない方が無難だろう。 必要な環境かどうかは、 BOOL WINAPI IsWow64Process(HANDLE hProcess,PBOOL pbResult); と言うAPIを使って調べることが出来る。この API については、Windows XP(SP2?)以降の Kernel32.dll に実装されているようだ。 http://shoda.tk/archives/2011/06/64bits_windows32bits.html http://shoda.tk/archives/2011/06/64bits_windows32bits.html FAQ:Windows API Sun, 12 Jun 2011 21:12:03 +0900 と言うより、自分自身のためのメモみたいなもの、かな？ http://shoda.tk/archives/2011/06/post_448.html http://shoda.tk/archives/2011/06/post_448.html FAQ Sun, 12 Jun 2011 19:40:22 +0900 今の大阪府警の警官募集ポスターが可笑しい。 ま・・・こういうポスターって、やっぱり大阪ならでは、なのかなぁ。東京ぢゃ顰蹙買うかもな（笑 ]]> http://shoda.tk/archives/2011/06/post_447.html http://shoda.tk/archives/2011/06/post_447.html 日常非日常 Sat, 11 Jun 2011 09:53:35 +0900 Windows XP以降の Windows には32bits版と64bits版が存在するが、64bits版の Windows で32bits アプリを動作させるには、色々と制限がある。所謂UAE（アラブ首長国連邦、、、ではない：ｗ）を引き起こす原因の一つである UAC（ユーザ・アカウント制御：User Account Control）がこれをさらに複雑に面倒にしてくれる。 UACはウィルスなどのマルウェア対策などのため（それだけではなく、本来のOSにはこういう、必要以上の機能はユーザに与えないという制限があるのがあたりまえ、と言う原則論の方が大きい、かも）に導入されたものだが、より大きな権限が必要な場合は確認ダイアログを出して、必要に応じて与えてしまう、と言う機能もあり、完全に制限しているわけではない。 ま、正直言ってお役所仕事みたいなもので（WindowsというかMicrosoftが）責任回避をするために、イチイチ確認を取る（ここから先はあんたの責任だぜ、いいね？ってなもん）だけみたいなもんで、肝心のマルウェア対策としてどれだけ実効があるか・・・神のみぞ知る、だ（マルウェア製作者は、そのあたりの平凡な技術者より数段優秀な人間が多いのので、たいていの回避策は心得ていると思われる）。 とはいえ、普通のアプリを制作する立場として、面倒だ、ややこしいのは嫌だなぁ、と言って避けるわけにもいかない。 前置きが長くなったが、UAC絡みで32bitsアプリを64bits版 Windows上で動作させるには、あれこれ対策を盛り込まないといけない。そのあたりをまとめてみると・・・ まず、64bits版 Windows にはWOW64（Windows 32-bit emulation On Windows 64-bit） という仕組みがあり、32bits アプリはこの一種の（簡易）仮想マシン上で動作させられる。 このWOW64上ではネイティブな64bitsアプリの動作環境と比べても、さらに多くの制限がある。 制限以前の問題として、そもそもシステムフォルダが64bits用と32bits用では異なるのだが、64bits 環境でも、システムプログラムの多くは 32bits時代からの実行ファイル名をそのまま引き継いでおり、まったく同じ名前のファイルが両方のフォルダに存在する。 つまり、アプリ上からはシステムプログラムの名前に違いはなく、32bits環境から実行すれば、32bits版が、64bits環境から実行すれば64bits版が実行される仕組みだ。謂わばこれを実現するためもあり、アプリ上からはシステムフォルダ名の違いなどが見えないようになっている。 具体的に言えば、ファイルシステム上では64bits用のシステムフォルダは \Windows\system32 で、32bits用は \Windows\SysWOW64 なのだが、32bitsアプリから \Windows\system32 を参照しても、実際に見えるのは SysWOW64 の方である。逆もまたしかり。 では32bitsアプリからは、この実体としての \Windows\system32 はまったく見えないのかというと、そうでもなくて、 \Windows\sysnative と言うフォルダを参照すると見ることが出来る。もちろん、実際のファイルシステム上には sysnative と言うフォルダは存在しないのだが。 逆に SysWOW64 を参照するにはその通りに指定すれば見える。 実際には、この名称は変更される可能性もあるため具体的な名称は UINT WINAPI GetSystemWow64Directory(LPTSTR lpBuffer,UINT uSize); と言うAPIを使用して得るのが正しい。 このあたりの仕組みは、「ファイルシステムリダイレクタ(File System Redirector)」と呼び、一時的に On/Off をコントロールすることも出来る。 そのためには、 BOOL WINAPI Wow64DisableWow64FsRedirection(PVOID* OldValue); BOOLEAN WINAPI Wow64EnableWow64FsRedirection(BOOLEAN Wow64FsEnableRedirection); BOOL WINAPI Wow64RevertWow64FsRedirection(PVOID OldValue); あたりのAPIを使用する。これらの効果はアプリ単位ではなく、スレッド単位である。 ・・・[未完] http://shoda.tk/archives/2011/06/32bits64bits.html http://shoda.tk/archives/2011/06/32bits64bits.html FAQ:Windows API Fri, 10 Jun 2011 15:28:17 +0900