shoda T.的うぇぶログ

リハビリは続く :-)
とりあえずのβテストです。

『Gismo MemFreshener：めむ・フレッシュ』は、メモリーを活性化させ、メモリー使用率が高くなった場合のアプリの実効速度の低下を改善することで、Windowsの動作をスムーズにさせるツールです（常駐型）。

というわけで、どこまで効果あるのか・・・と思うでしょ。
ま、、、、なんです（ｗ
種々の事情（笑）によりシェアウェアです。どっちみちフリーでも評価なんかしてもらえないしね(-_-;)

めむ・フレッシュ Ver 1.50β

15日、東京地裁は、ロス疑惑の容疑者として2008年に逮捕され拘留されたロサンゼルス市警の留置場で自殺した三浦和義さんの妻が、産経新聞とヤフーを相手取って名誉棄損で訴えていた訴訟について、原告側の主張の一部を認め、両社に対して計66万円の支払いを命じた。

訴訟は2008年に YAHOO!JAPAN に掲載した写真（1985年当時の手錠姿の三浦氏）や同記事で名誉を傷つけられたとして計660万円の損害賠償を求めたもの。ヤフーは産経の記事と写真を無批判に転載したことで同罪を問われた。

松並裁判長は「記事の内容から、（手錠姿の）写真を公表する必要性は乏しい」として写真について名誉棄損を認めた。一方、記事の掲載は不法行為にあたらないとして訴えを退けた。

産経新聞はともかくとして、契約に基づいて転載したヤフーに対しても名誉棄損を認めた判決は初めてで、もしこのまま判決が確定すれば、自動的に、あるいは契約上取捨選択権なしで転載しているサイトなどにも影響が及ぶとみられる。
ヤフー側は訴訟で「記事などが第三者の権利を侵害するものではないと配信元が保証している」と免責を主張したが、認められなかった。

別件だが、今年4月に最高裁は、共同通信社が配信した記事の掲載による賠償責任をめぐる訴訟で、配信元が真実と信じる相当の理由があれば、掲載した加盟社も名誉棄損の不法行為責任を負わない」との判決を下している。どちらの判決が優勢になるか、注目していく必要はあるだろう。

14日、BCNはパソコンなどデジタル機器の市場動向に関する説明会を開催。
パソコンの販売台数は前年同月比で4月が119.6％(金額ベースで104.2％)、5月が118.5％(同104.5％)と2ヶ月連続で2ケタ増となったと発表した。
同社は全国の大手家電販売店のPOSデータを基にデジタル機器の販売台数や金額情報を集計・提供している。

3月は東日本大震災の影響ばかりでなく、米インテルの新型チップセットに不具合が見つかり春モデルの出荷が遅れたことなどが影響して、販売台数ベースで95.5％（販売金額ベースで88.2％）まで落ち込んでいた。

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分になってようやく規制解除を行って正常状態に戻した。

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 に実装されているようだ。

と言うより、自分自身のためのメモみたいなもの、かな？

今の大阪府警の警官募集ポスターが可笑しい。
ま・・・こういうポスターって、やっぱり大阪ならでは、なのかなぁ。東京ぢゃ顰蹙買うかもな（笑

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を使用する。これらの効果はアプリ単位ではなく、スレッド単位である。

・・・[未完]

8日午前9時（日本時間）から始まった世界規模のIPv6実証実験「World IPv6 Day」は、目立った大きなトラブルもなく、9日9時に終了した。

詳細は各参加企業のリポート待ちだが、一部の参加企業のサイトでDNSサーバ等にIPv6アクセス用の設定を忘れるなどの初期トラブルや、事前に告知されていたように、NTTフレッツ光ネクストなど一部のネットワーク環境と OperaやOutlookなどの組み合わせでアクセス出来ないケースなどが確認された（かなり限定されたケースのようだ）などの報道はなされているが、これと云った大きなトラブルはなかったようだ。

今回の実証テストには、世界中から430を超える企業や組織が参加した。
期間中はIPv6通信のトラフィックが通常の数倍～数十倍に急増するなど、実証テストとしては十分なものであったことを伺わせ、今後の IPv6 への全面的な以降にもはずみがつきそうだ。

歴史は繰り返すというけれど、それは物事のごく一部、それも一面的に見た場合の話であって、正確には繰り返すわけではない。
ある歴史家は、歴史は螺旋の如く彷徨う、と云ったが、同じ道を辿っているかに見えるだけで、多次元空間ではまったく異なる道なのだ。

次期Windowsとして Windows8 の概要が現れつつあるが、基本UIとしてタッチUIが前面へと出てくるようだ。標準で現在のオーバーラップウィンドウではなく、タイルウィンドウになるとも謂われているが、これもタッチUIを前提とするからだろう。
ようやく実用期を迎えたスマートフォンの多くがタッチUIを採用しており、それはAppleのiPhoneも例外ではない。しかしタッチUI、そしてあの小さな画面ではオーバーラップウィンドウは使いづらいのは明白で、必然的に単純なタイルウィンドウにならざるを得ないのだろう。
Windows8が、スマートフォンやタブレット（スレート）型PCをターゲットの中心として捉えるのであれば、タッチUIを標準に考えざるを得ないのも、また時代の流れか。

ただ、どうだろう？ほんとうに Windows8 はスマートフォン向けのOSといえるのか？
ノート型やデスクトップPCを切り捨てていいのだろうか？
結局のところ、タブレット型にしても、タッチUIにしても、用途の大半をブラウザによるブラウジングと見ているからこそのインターフェースであって、まだまだPCの用途はそんな限定的なものではないと思うのだ。

確かにブラウジングするには現在のタッチUIには優れた面も多いが、たとえばエクセルの操作を同様に出来るだろうか？たとえばセル入力は？複数セルへの連続フィルは？etc.etc.と考えただけでも、まだまだ無理があるのは明白だ。
そのあたりを解決するには、まだまだ時と経験が必要だろうし・・・と考えれば、Windows が　1,2,3・・・と来て、2000やXpあたりになってようやく十分な実用性と操作性を得た歴史を、また繰り返すのか、という気がしなくもない。

ところでタイルウィンドウといえば、かつて Windows がまだ Ver 1 とか 2 であったころを彷彿とさせるが、もちろんあの頃のタイルウィンドウとは似て非なるものである。これもまた螺旋の・・・
あの頃、最初の実用的なマルチウィンドウベースのGUIシステムとしてのAlto（Xerox PARC)の資産（そして技術者）を引き継いだAppleが、オーバーラップ型のマルチウィンドウシステム独占を目論んだため、ひと足遅れをとったMicrosoftは苦肉の策としてタイル型ウィンドウシステムを選んだわけだが・・・今、タッチUIベースの iPhone などがタイルウィンドウを使ってる（使わざるを得ない）のは歴史の皮肉なのかもしれない(笑