PCの最近のブログ記事

どうもThinkPad X61t (Vista x64)でのビデオキャプチャで次第にドロップフレームによる失敗が増えている気がしたので、デフラグしてみました。見事に細切れでした。

一方MacBook Pro (Win7 x64)は性能が高いから平気なのかと思ってみたら、HDDが至って綺麗なことが判明。こちらの方が常用環境ですから、小さなファイルの増減が大量にあるにもかかわらず、です。

こんな綺麗なHDDを見たの初めて、というぐらい綺麗でした。「NTFSはデフラグ不要」というのがWin7に至って初めて本当に実現したか、Vistaでは効果が皆無だった標準デフラグがちゃんと働くようになったか。

いずれにせよ地味ですが嬉しい改良でした。

木曜に夜にサーバーのHDDランプが点灯しっぱなしでした。しかし見逃しました。というのはWindows Updateの頃合いだったからです。

翌朝、まだ点灯していました。変かもしれないとログオンして様子を見てみると、2TBのデータドライブ(WD20EADS)にアクセスできませんでした。異音はありませんでしたが、シャットダウンできず電源ボタン長押しOFF。BIOSからは認識されるも起動が進まず。とりあえず電源を落として出勤。

夜、HDDを取り出して外付けケースに入れ、MacBook Pro (Boot CampのWin7 x64)、ThinkPad X61t (Vista x64)と接続するも同様にアクセスできず。この時点でサーバーのハード不調の線は消えました。

回転音は聞こえ、アクセス音すら聞こえているので、中身は物理的には大丈夫なんじゃなかろうか。BIOSから認識されるのだから、コントローラもATA側は生きているんじゃなかろうか。ヘッドかコントローラ間に異常があるんだろうか。だとしたら基板交換だろうか、しかしそのためには同一ロットを探さなければならないはず...。

ちなみにデータ復旧業者はテラバイト級のものを依頼すると、費用が6桁コースです。しかも悪徳業者が横行しているとか何とか。それなら諦めるべきなのか...幸いパソ通その他の貴重なデータは他のHDDにも残っていることですし。

というところまで考えたあたりで、別のOSを試す価値があるだろうと思い当たり、MacBook ProのSnow Leopardで読んでみたところ、正常にマウントしました。内蔵HDDと余ったHDDを集めて容量を確保し、コピー開始。

翌日つまり3連休の初日、交換とバックアップRAID構築の買い出しをし、作業続行。ファイルの破損は1つのみで救出に成功しました。NTFSなのにWindowsでなくMacからしか読めない状態って何なのでしょうね。

さて、MacからNTFSのデータを吸い出したとなると、Unicodeファイル名の正規化の違いが出てきます。濁点や半濁点をMacでは独立して扱っているのです。若干の違いがありますが、Macの正規化はUnicodeの正規化形式Dにほぼ相当します。Windowsは形式C。

Macはファイル名を内部でDに変換して扱います。形式CをコピーするとDになるのです。Windowsは原則Cですが変換はしないため、Dのファイル名はDのままです。非Unicodeアプリから見ると、濁点半濁点が"?"に化けて見えます。

というわけで、一括修正するアプリをC#で作ってみました。フォルダ・ファイルの再帰検索をして、名前が正規化前後で不一致なら、リネームをかけるというものです。Directory.Moveメソッドが正規化の違いを無視するため、フォルダ名は一度乱数を追加した別名を経由しています。
Mac2WinFN01.zip

それにしても、2年で壊れましたねWestern Digital。元々個人的な印象があまり良くないメーカーですから、こんな事態には備えるべきだったのですが、背伸びはすべきじゃないとも思いました。つまり、普及価格帯でない容量に手を出すと、経済的にバックアップをしにくくなるということです。

バックアップを用意せずにデータだけ増やすのが無謀なのはもちろんですが、大事であればあるほど、手頃なところで回すようにしないと後が大変。それが今回の教訓でした。

Vistaのデスクトップアイコンにチェックボックスを表示できますが、似たような操作性のものを作ってみました。

つまり、チェックボックスでも、Ctrlクリックでも複数選択ができるというものです。

Ctrlキーの状態によってチェックボックスへの反映を止めているのがポイントで、これをしないとCtrl+スペースが押された時に選択できなくなります。

WM_NOTIFY処理の抜粋

case LVN_ITEMCHANGED:
  pnmlist = (LPNMLISTVIEW)lParam;
  if ( ( pnmlist->uNewState & LVIS_STATEIMAGEMASK ) == 0 ) {
    SHORT ctrlState = GetKeyState( VK_CONTROL );
    if ( ListView_GetItemState( hList, pnmlist->iItem, LVIS_SELECTED ) ) {
      if ( ( ctrlState >= 0 ) ||
        ( ( ctrlState < 0 ) && ( !ListView_GetItemState( hList, pnmlist->iItem, LVIS_FOCUSED ) ) ) ) {
        ListView_SetCheckState( hList, pnmlist->iItem, TRUE );
      }
    }
    else {
      if ( ( ctrlState >= 0 ) ||
        ( ( ctrlState < 0 ) && ( !ListView_GetItemState( hList, pnmlist->iItem, LVIS_FOCUSED ) ) ) ) {
        ListView_SetCheckState( hList, pnmlist->iItem, FALSE );
      }
    }
  }
  else {
    if ( ( pnmlist->uNewState & LVIS_STATEIMAGEMASK ) == INDEXTOSTATEIMAGEMASK(2) ) {
      ListView_SetItemState( hList, pnmlist->iItem, LVIS_SELECTED, LVIS_SELECTED );
    }
    else {
      ListView_SetItemState( hList, pnmlist->iItem, 0, LVIS_SELECTED );
    }
  }
  break;

CryptAPIでハッシュを計算させようとすると、巷に多いサンプルコードではCryptAcquireContextでPROV_RSA_FULLを渡していますが、これだとSHA-2に対応していません。

MSDNのブログにも書かれていますが、PROV_RSA_AESを渡せばCALG_SHA_256等が通るようになります。XP SP3以降に限定されますが。

エラーチェック無しでこんな感じです。

CryptAcquireContext( &hProv, NULL, NULL, PROV_RSA_AES, 0 );
CryptCreateHash( hProv, CALG_SHA_256, 0, 0, &hHash );
CryptHashData( hHash, src, 1024, 0 );
len = 32;
CryptGetHashParam( hHash, HP_HASHVAL, hash, &len, 0 );
CryptDestroyHash( hHash );
CryptReleaseContext( hProv, 0 );

Flash Player 11.3にしたところ、固まるとか当初の致命的な問題は有名なのでさておいて、Firefoxがフォーカスを失う現象が起こるようなりました。

これも他の現象と同様、mms.cfgに下記の行を追加して、保護モードを無効にすることで回避できます。

ProtectedMode=0

もちろんセキュリティレベルが落ちます。

Reader Xにも、PDFをダブルクリックで開くと、新しいウィンドウが前面に来ない現象があります。これもまた環境設定の「一般」で保護モードを無効にすると回避できます。もちろん(以下略)。

どうやらAdobeのフレームワークに問題があるようです。

私にとってはキーボードの店だったクレバリーが倒産してしまいました。

残念ではあるのですが...我が身を省みると、自作PCから引退して久しく、ALi/ULiと一蓮托生でしたから、パーツらしいパーツも5年は買っていませんでした。

このサーバーがAMD E-350自作機ですが、CPUもマザー直付け、拡張スロットも使わずだと自作というよりキットみたいで、組んだ実感がないところ。

ノートPCでビデオキャプチャから何からできており、私の中で自作PCが既に趣味として終わっていることを実感します。

1999年に新卒で就職した愛知の某周辺機器メーカーで、割り当てられた486マシンが遅すぎ、勝手にASUS P5A-Bに入れ替えたのが最初の自作機でした。

Cx6x86MX/MIIからCeleron、Pentium 3、Athlon、Pentium 4、Athlon 64、Athlon 64 X2となり、MSI K9NU Neo-Vが実質最後となりました。ThinkPad X61 Tabletを購入した2008年まで、約10年間。

10年間、秋葉原も大きく変わってしまいました。ジャンク、無線、PCとジャンルこそ変われど電気街であったのが、今やマンガ・アニメ文化が幅を利かせています。

紙と電子情報、一括りにすれば共通項はソフトウェアになるでしょうか。電気街時代をハードウェアの街だとすれば、これもパラダイムシフトだったのです。

電子部品関係の店には残っていてほしいのですが、再開発で一気に消えてしまうのかもしれません。秋葉原なんか小綺麗にしたって場違いだと思うのですが。

少し前にはエフ商会も消えてしまいました。かつて馴染みの店が消える度に、自分の足が遠のいていたのを実感し、切ない思いに駆られます。

無常。自分の思い出が過去の世界になりつつあると感じて寂しく思うのです。そして或いは自分もが。

Windows XPの脆弱性MS12-034への更新KB2686509が入りませんでした。

要するにキー入れ替えのレジストリ(Scancode Map)を入れているとエラーになってしまうとのことで、一時的に削除して、更新後に戻すと回避できました。

説明を見る限り、キーボードのレイアウトドライバの全チェックをかける過程で、Scancode Mapエントリもその一つとして扱われるためにエラー、という感じでしょうか。

マイクロソフト自身も情報を提供しているレジストリエントリぐらい考慮すべきと思います。

BUG: 未処理の例外フィルターがデバッガー内呼び出されますされません。

いくら機械翻訳といってもこれは酷くないでしょうか。

原語は「BUG: Unhandled exception filter not called inside debugger」で、見出しなのでbe動詞が省略、「未処理例外フィルターがデバッガー内で呼ばれない」となります。

「英語を並べて表示英語と日本語を並べて表示する」をクリックすると、最新版Bing翻訳による表示がされるようで、こちらは「BUG: デバッガー内呼び出されない例外フィルター」と、現時点でそれなりに意味が通る訳になっています。

後置修飾扱いなのは仕方ないとして、最初は正しく訳されていたUnhandledはどこ行ったとか、まだツッコミ所はありますが。

このKB自体はWin9xのものですが、他にも昔の翻訳エンジンで訳したままのページが大量にあります。意味不明な日本語にしておくぐらいなら、英語のままにしておき任意で「並べて表示」ボタンを押させるのが良いように思うのですが。

# 某国総理と違って文法の誤りだけで済むのがマシではあります

技術情報は英語で読む人も多いでしょうから、現状では却って二度手間になっているのです。「たまには機械翻訳済みページを更新してあげたらどうか」とフィードバックに入れましたが、反映されるのはいつのことか。

日本語のページは本文中のAPI名や構造体名が消えているとか、あまりにも状態が酷いので見ない方が良いのですが、ネットで調べ物をしている最中はそのままオンラインで見ることが多く、困ってしまいます。

自作のダイアログベースのプログラムが、英語版Windows XPでのみ動かない現象が発生したので調べてみました。

リソースをあれこれいじりましたが、コモンコントロールの初期化を忘れていたのが原因でした。


このおまじないは「コモンコントロールを使う場合は必要」と方々で注意されているのですが、日本語版Windowsでは2000以来ずっと、なくても動いていたので記憶に残らなかったのです。

しかしこうして現実に、英語版にて問題が発生したのでした。建前は偉大です。英語版Vista(Ultimateの言語切り替えではなく英語版)でも試してみましたが、こちらは大丈夫でした。


現象の詳細としては、CreateDialogが失敗、GetLastErrorが6を返します。ERROR_INVALID_HANDLEです。

WM_CREATEは来るのですが、その後WM_SETFONTの直後にWM_DESTROYが来てしまう、という流れでした。WM_INITDIALOGの前に終了します。

日本語版Windowsはどうして問題ないのか謎ですが、お約束は忘れると怖いという話でした。