PCの最近のブログ記事

3GBと4GBなんて違わないだろう、と64ビットWindowsの出始めの頃には思っていましたさ。当時はXPメインの時代、画像や動画を扱わなければ2GBで余裕でしたから。

しかしOSとアプリがメモリを食い尽くした後の余力ですから、そうした状況がひとたび発生すれば、スワップ(残量0)と1GBの比であって、倍率は計算不能のゼロ除算となります。

私とMacBookをそこに追い詰めたのはVisual Studio 2010でした。というわけでVS2010の使用頻度が上がったため、OSとHDDを強化しました。

Vista x86から7 x64へ。せっかく延命されたばかりでしたが、OS上のプログラムも多い立場なので、遅すぎたぐらいです。もう8がリリース間際、経費節減といっても自粛しすぎはダメですね。

250GB/5400rpmから750GBハイブリッド/7200rpmへ。出たばかりのSeagateのハイブリッドです。Mac側は120GBから160GBの微増としました。

使い物にならないレベルだったVS2010が、かなりまともになりました。次期版(2012?)ではもう一歩の高速化を期待したいところです。

電源投入からログオン画面までもかなり速くなったのですが、ログオン後が嘘みたいな速さです。ひょっとしたら64ビット版ウイルスバスターが速い、なんてこともあるかもしれません。

しかし、そうなるとまたタイミング問題が出るわけです。ログオン時タスクからのShell_NotifyIconで、FALSEなのにERROR_SUCCESS、何の関係があるのか不明なERROR_NO_TOKEN、この2パターンが新たに出現しました。

前者はともかく後者は何なのか。GetLastErrorの戻り値は判別せず、回数を制限してリトライするのが無難に思えてきました。

環境依存であるタイムアウトや回数制限を避けるとすれば、通知領域へのアイコン登録は後回しにして、登録できるまでウィンドウを表示してしまう(消すと終了できないため)ことになります。

真っ白ウィンドウでは格好が悪いので、いっその事スプラッシュウィンドウを登録できるまで常時表示するようにするのが、UIとしての妥協点でしょうか。

Windows 7でslnを「プログラムから開く」でVisual C++ 2005 Expressに噛ませたところ、以後VC++2005からしか開かなくなってしまいました。

何度「プログラムから開く」でVisual Studio 2008を指定しても、ダブルクリックするとVC++2005に行ってしまうのです。コントロールパネルの「関連付けを設定する」でも効果無し。

そういえばUACを求められなかったことを思い出し、HKEY_CURRENT_USERを探したところ、関連付け情報がありました。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

ここの.slnを削除したところ、無事に元に戻りました。恐らくVistaも同様の操作でしょう。

メールアドレスがgmailからHotmailに変わりました。無線APの_nomap騒動がちょっと癇に触りまして。

それでCERTUMのオープンソース開発者向けAuthenticode証明書を、少し繰り上げて発行してもらいました。

どうもシステムが改良されたようで、相変わらず最初のフォームはポーランド語なのですが、アンケート的なその最初さえ入力してしまえば、後は何とかなるようになりました。

名前、メールアドレス、電話番号、種別。その次がよくわからないのですが、業種でしょうか。そこから下はアンケートで、他に興味があるもの、どこでCERTUMを知りましたか、個人情報の使用に合意しますチェック、です。

最初の連絡メールもポーランド語ですが、そこには受付番号と入力の注意点(CNにOpen Source Developerが追加される、OにOpen Source Developerと入れること)があるぐらいで、本番の入力フォームは英語でできます。

次のメールにパスポートのスキャン画像を返信すれば万事完了です。

知りませんでしたが、考えてみれば当然です。OSがWPA2に対応しても、ドライバが非対応なら、接続はできないのでした。

先代サーバーであるFMV-610MG2を母用にセットアップしています。メモリが768MBなのでXPですが、SP3だからWPA2対応だとばかり思っていました。

無線LANカードはエレコムLD-WL54G/CB。アクセスポイントをWPA2と認識しているのに、一向に接続できません。どうもWPA2のAESはWPA時代のAESと少し違うのだとか。

ドライバを更新しようにもWPA2登場以前のものが最新です。そこで使えそうなドライバを捜してみました。Vendor IDが168Ch、Device IDが13hなので、チップはAtheros AR5213です。

チップ型番から検索すると非公式ドライバの配布サイトがあり、これを使うことで無事にWPA2でも使えるようになりました。

私が小さい頃、まだ蛍光管の電卓が現役でした。シャープのもので、メモリーの使い方が今と違うものでした。演算結果の総和を表示する"T"というキーがあったのみだと記憶しています。

さて、Windows 7で電卓が改良されたことが好評らしいのですが、私にはどうも合いませんでした。

16進も小数も頻度が変わらないものですから、関数とプログラマを分けられては面倒くさいのです。しかも切り替えがAlt+1などキー2つですし。

自宅ではあまり使わないので、会社MacBookがVistaの間は気にしなかったのですが、あっちも7になったので、何とかしてみました。

Vistaのcalc.exeは持ってくるのに注意が必要で、ja-JPフォルダ作り、その中にcalc.exe.muiを置かなければなりません。XPのcalc.exeは単体で動きました。

余談ですが、そういえばWindows 3.1の電卓にはバグがありましたっけ。パソコン通信で配布されたアップデートも懐かしい思い出です。

DeltaEndの改良も一段落というところで、後はNT4.0での動作確認をするのみです。

そういえば95/NT4.0にはシェル統合というものがありました。これをしないとShell32.dllが古いまま。しかしそのためにはIE4が必要で、さすがにネット上にはどこにも残っていないのです。

ところが収集癖が幸いし、手元に色々残っていることがわかりました。

まず、月刊I/O 1999年10月号付属のCD-ROM。Windows 98 SP1のために残しておいたものですが、これにIE4.01SP2が入っていました。この手の付録に付けるものは得てしてフルパッケージなので、これもNT4.0用が含まれています。

それと別に、2001年10月に配布されたMicrosoft Security Tool KitのCD-ROM。Nimdaが猛威をふるっていた頃のものですね。NT4.0 SP6aも入っていました。

他、FDメディアをMOに保存して一括インストールしていたことがあったのですが、それがPDになり、さらに5年前にCD-Rにコピーしたものもありました。
AmiPro R3.0Jとか、DOS6.2やWin3.1の98版・AT(/V)版、DFJ2/WIN 1.5、Win32s 1.25など。

素晴らしい。

その後Windows 7 x64環境で確認したところ、x86バイナリ・x64バイナリ共に再現せず。OSの違いなのか何なのか、と謎が深まってしまいました。

Visual Studioのデバッガにモジュールの一覧表示があったのに気付き、Vista x86で表示させたところ、shimeng.dllのアドレス範囲となっていました。Windows互換性テクノロジの中の人だそうな。

色々試した結果、slnファイルをUAC昇格して開くための自作ツールが原因だと判明しました。といっても、requireAdministratorなmanifestを持たせ、ShellExecuteExするだけの小さな小さなものなのですが。Vista環境でのみ、Send Toに入れて使っていたのです。

ファイル名に"launch"を含んでいると、問答無用で互換性テクノロジの餌食となるようです。互換性レイヤーを示す環境変数__COMPAT_LAYER=ElevateCreateProcessとありましたが、GetProcAddressに介入するのはWRPDllRegisterとかいうものだけではないのでしょうか。

インストーラー検出のinstall,setup,update,etc.とは異なり(他にpatchも)、今のところファイル名にlaunchを含むx86バイナリのみですが、Vista/7共にOSはx86/x64両方で再現しています。

asInvokerの中ILでも互換性レイヤーが入り込み、GetProcAddressをshimeng.dllに取られます。requestedPrivilegesがあってもダメということは、Vista以降用として作っても回避できない、ということです。

こんなテストコードを作りました。実行ファイル名を変えるとアドレスが変わることがあるのがわかります。
GetProcAddress.zip

昇格ランチャーのファイル名変更で回避できたのですが、真正面から行く場合、GetModuleInformationでkernel32.dllの範囲を取得し、その中にあるかどうかを確認して、外れていればLdrGetProcedureAddressする、という方法になるでしょうか。

GetProcAddressはGetProcAddress自身のアドレスを正しく取得できないことがあるようです。どうもUACで高ILにしたデバッガー下だと違うアドレスが返っています。

どうしてCreateRemoteThreadがロジックボムになるのかと思ったら、なんという罠でしょうか。

環境はVista x86、Visual Studio 2008 SP1。

関係あるのかないのか、ntdll.dllのUndocumentedなLdrGetProcedureAddressだと正しく取得できるという情報があり、試してみるとその通りでした。

単独で実行させる限り大丈夫なら、UndocumentedなAPIに手を出すこともありませんが、常時正しく動いてほしいのが本音です。

C文字列ではなくANSI_STRING構造体でAPI名を渡すので、RtlInitAnsiString/RtlFreeAnsiStringも使う必要があります。モジュールハンドルはLdrLoadDLLではなくLoadLibraryのもので大丈夫のようです。

ダミーウィンドウを作らせるだけですから、GetModuleHandleでuser32.dllの存在を確認した上で、DllMainから作ってしまうのが楽ではあります。

しかし「のどか」にて、これは共用メモリの話ですが、Adobe Readerという全くのGUIアプリでエラーが発生したことを考えると、ロードされていてもDllMainからuser32.dllのAPIを呼ぶのは危険かもしれません。

Windows Vistaおよび7のHome系製品が延長サポート対象になったようです。

Windows Vistaサポートライフサイクル
Windows 7サポートライフサイクル

Vistaの残り2ヶ月足らずで突然の方針転換。粘っていた人は嬉しいでしょうが、既に更新した人は恨むでしょう。今やPCはただの道具であって、維持費はかけたくないのです。

そういえばXPのサポート切れをカウントダウンするガジェットなんてものが昨年4月にリリースされましたが、ガジェットというカジュアルな手段(しかもXP非対応)に訴えるなら、Vistaの方が先ではないかと思ったものです。

この延命はいつ頃から確定路線だったのか、と勘ぐってしまいます。

私の仕事PC(MacBook MB062J/B)はVista Ultimateなので救済されましたが、Visual Studio 2010には非力なので、できれば本体ごと新しくしてほしいなあ...。

AMFMラジオ録音さんのlame MP3で、再生ピッチが一定しないような感じがしたので(細かい音飛び？)、試しにaac Pipeに切り替えたのです。まあ、録音時のハードウェアの問題でしょうが。

ところがこれは生AACなので、iTunesやiPhoneで再生できないのですね。

そこでMP4Boxでm4aに変換したところ、QuickTime Playerで「不正なサンプル記述」というエラーが出てしまいました。Windows Media Playerは通りますがiPhoneではやはり再生できません。

iOSは中にQuickTimeと同じものが入っているので、QuickTime Playerはテスト環境として有用です。どうやらMPEG-2扱いされたのが問題だったようで、MPEG-4に強制することで回避できました。

mp4box -add <input.aac>:mpeg4 <output.m4a>

faacにオプション-wを追加して直接出力させたm4aは、QuickTime Playerでも再生できたので、録音時に使うならこちらでしょうか。

しかしいずれも音飛びは悪化してしまいました。そういえばHandBrakeの時にも音飛びしていました。faacは音質以前に音飛びが問題です。