PCの最近のブログ記事

容量の無駄ですが、秀丸メール以来の習慣として、メール送信時に自分宛Bccを追加していました。送信済フォルダからは送信メールが全て検索でき、またメールサーバーが付けたMessage-IDが見えることで、確実にツリー表示が繋がるという理由から。

Thunderbird 24.3.0で仕様が変わり、Bccで来たメールにはBcc相手に返事ができないようになったらしいのですが、その挙動というのが「返信時にBcc一括削除」で行なわれているらしく、アカウント設定で追加している自分宛Bccも消えてしまうのです。

「Bccで来たメール」の判定はToかCcに自分が含まれているかどうかのようで、つまりメーリングリストの類(グループアドレス)で来たメールでも、自分宛の追加Bccが消される現象が発生します。

グループアドレス宛のメールなら、Bccを追加すれば結果として2通になりますから削除は嬉しいとして、冒頭の目的で受信フォルダに入れるため、意図的に自分宛で送ったメールへの返信をする際にも消えるのは困ります。

Thunderbirdを使う限りにおいては、全文検索よりグローバル検索の方が使用頻度が圧倒的に高いため、送信控えを送信済フォルダでなく受信フォルダに指定し、「送信元のメッセージと同じフォルダに返信を保存」のチェックを入れておけば充分そうですが。

でもわざわざ追加しているBccまで消えるのは、意図と違った挙動に思います。特別に扱われるべきです。

"@"でIMEがONになる現象が解決しました!

2.25は"@"の判別自体がなくなっています。KeePass.Util.SendInputExt.SiEngineWin.TrySendCharByKeypressesが、2.24まででKeePass.Util.SendInputEx.OSSendKeysWindowsがしていた処理だろうと思うのですが。

どの環境で"@"をUnicodeで送る必要があったのか不明ですが...Neo配列とかいうエルゴノミクスキーボードへの対応が別処理になったことで必要なくなったのでしょうか?

ともあれ、これで少なくとも当分は公式リリースのままで使えます。

勤務先デスクトップをVistaから8.1へ。...まあ、やはりスタートメニューのアプリを入れないと話にならないですね。

スタートボタンで移動できる画面は公式名「アプリビュー」と呼ぶそうですが、これのどこがわかりやすいって言うんでしょうか？

少なくとも名前の省略はすべきではありませんし、できれば階層構造か折り畳みはできた方が良い。項目が多い場合に収拾が付きません。

しかも省略表示はポインタを乗せても表示されないことがあります。ギリギリの長さの場合のようです。

やがてはこの画面で済むようなアプリの時代になると思います。AppleのXcode 5がApplicationsフォルダに置くアイコンを一つにして、サブメニューを全て隠蔽したように、余計な項目は減っていくでしょう。

しかし、今がそうではないということです。インフラとして日常的に使っているので、前と同じに使えないと困るのです。特に、省略表示をしなくする設定がないと見分けが付かないのですが、これをどうしろと？

使いづらいとかいう次元でなく、実用になりません。操作が困難です。行く行くの理想はわかりましたが、今のユーザーのことを多少は考えてもらいたいものです。

ところでOS入れ替え前、4コアCPUでのVistaはまずまず快適でした。MicrosoftのVista想定環境(次期OSまでの中間期ぐらいのメインストリーム)は4コア(又は2コアのハイパースレッディング)だったのかもしれないですね。

勤務先のDELL Dimension 9200CにCore 2 Quad Q6600を入れました。組み込み向けコンパイラでさえ2コアは使う(→3コア以上でないと他の作業が遅くなる)時代になっていたため。

BIOSは2.2.1です。説明が正しければ2.3.2は新型(当時)カードリーダー対応だけですから、わざわざ更新する必要もないかと。根幹部分の更新は必要最小限に。

自作PCをやっていた頃はALi/ULi派でしたから、最後に組んだIntel CPUはSocket 478のPX848 Like Proでした。LGA 775は今回初めて触ります。

Prescottの頃の風の噂によると、確かピンがソケット側に付いているとか何とか。それで「ピン曲げたらマザー買い換えってリスク高すぎんだろオォン！？」って批判があったのを覚えています。

サービスマニュアルを参照してヒートシンクを外すと...ナニこの分厚い鉄板のカバー。そういえばヒートシンクごとCPUがもげる事故を防ぐとか読んだような。理に適っていますが、すごい力がかかるものらしいですね。

E6400を外しQ6600を載せてレバーを倒...ガッチンとかすごい手応えがありました。775本のピンが一度に押し下げられた衝撃でしょうが、心臓に悪いことこの上ない。無事に動作しましたが。

9200Cは私の入社時に支給されたもので、この春で丸7年になります。近々Vistaから8.1にする予定ですが、まだ使えてしまいますね。

P.S.
よく見たら起動時にAHCI画面の下に「非対応CPUでっせ」とのメッセージ(※)がありまして、試しに米DELLのBIOS 2.4.0にしたら消えました。2.3.2は試していません。
※System does not support the installed Processor. Please consult your computer documentation for more information.

たまーにWindowsフォトビューアーで正常に表示できないJPEGファイルに遭遇することがあります。でもInternet Explorerを含めて他のソフトでは表示できます。

JpegAnalyzer Plusにかけてみたところ、縦横比が間違っていることがわかりました。APP0マーカーに縦と横の密度(単位はdpiとは限らない)がありまして、その片方が1になっていました。

Windowsフォトビューアーはアスペクト比を律儀に守るため、縦線のようになってしまったりするようです。スキャン画像などでは密度は重要なので、印刷した際に原寸通りになって嬉しいのですが。

さて、これを修正するアルゴリズムとしては...単位指定は維持して、1になっている方を大きい数字に合わせる、あたりが安全なところでしょうか。滅多にないでしょうが、意図的に縦横比が変えてある画像もないとは言えませんから(可能性としてはDVD画面のキャプチャとか)。

Windows RTがラインアップから消滅する可能性があるとか何とか。

思えば...Windows NTは元々マルチプラットフォームでしたね。x86の他にMIPS、PowerPC、Alpha、Itanium。CHRPに心の底から期待した学生時代を思い出します。

Windows RTはその流れからは異端児でも何でもありませんでしたが、以前のx86とそれ以外の関係とは大きく異なりました、低性能・低消費電力・パーソナル向けということです。

でも結局、Windowsのいいところはカオスにも近い裾野の広がりなので、動作バイナリが制限されるのでは魅力半減なのです。x86以外のNTはx86エミュレータを使うこともできましたが、アーキテクチャ自体が違うとやはり遅い。

そしてWindows RTはエミュレータもありませんでした。性能的に劣るところにエミュレータなんか載せたら、実用にならないという判断もあったのでしょうが、お仕着せのものしか動かないならiPadでもいいし、Androidに劣ります。

MS-IMEとMicrosoft Officeだけで良ければ今でも価値があると思うので、確保するのも一興でしょう。Surface 2なら解像度も高いので、PDFリーダーとしてだけでも価値があります。個人的には叩き売られていたらという条件付きで。

まあ成功も失敗もあるということですが、それでも一言だけ言わせてもらうと、WinRTと紛らわしい名前を付けないでほしかった。Microsoftはネーミングをもっと社内で事前協議すべきです。

空行で異様に隙間が空いてしまうのは新しいエディタの仕様らしいですが、そのpタグの代わりにbrタグを入れる方法が公式(ですよね)で公開されていました。

EnterBrForTinyMCE

要するにそこの"id: EnterBrForTinyMCE"で始まるpreタグの中身をconfig.yamlというファイル名で保存して、MovableTypeのcgi本体(mt-staticでない方)の下に配置すれば良い、というわけです。

場所は例えば
/cgi-bin/mt/plugins/EnterBrForTinyMCE
となります。

本体も引用しておきます。

id: EnterBrForTinyMCE
name: EnterBrForTinyMCE
version: 1.00

editors:
  tinymce:
    config:
      force_br_newlines: true
      force_p_newlines: ~
      forced_root_block: ''

マンションなのでルーターは納戸に入れなければなりません。そこに屋内LANのハブがあるためです。鉄筋の狭い部屋に押し込んでは無線の飛びにとても不利です。

# 結局Professional Firmwareで無線使ったのかと

そこで別のルーターにDD-WRTを入れ、WZR-HP-AG300Hは無線APとして使用することにしました。

新宿をうろついているとWHR-G300Nを発見しまして、これに決定。無線の安定度が芳しくない不人気機種らしいですが、用途が有線専用ですから問題ありません。

Mac OS XのtftpでDD-WRTを流し込み、設定を手作業でコピーして無事に移行完了。

で、WHR-HP-AG300Hです。やはり建前は守らないといけませんから、純正へ。送信出力は何とかなっても、5GHz帯で使えるチャンネルが2.4GHz帯と違い複雑に異なるので、きちんと日本対応の製品でないとまずいのです。チャンネル固定という手はなくもないですが。

しかしProfessional Firmwareの管理画面から元々のファームに書き戻せません。検索すると、書き換えられる純正改造ファームがあるというのですが、うっかりWZR-HP-G300NHで普通のDD-WRTから書き戻す話題だったことに気付かず文鎮へ。

DIAGが2回点滅、フラッシュ異常だそうです。しかしMacでarp併用のtftpから無事に復旧できました。やはりこういう作業はUNIX系が良いです。ちなみに完了後、ARPのテーブルは削除しないと192.168.11.1へアクセスできなくなります。

途中、Unsupport REGIONとか出てしまいました。調べるとルーター側が出しているメッセージだとわかりましたので、Professional Firmwareを導入する際に地域をUSにしていたためと理解。

そこで一度アメリカ版1.78を入れてデバッグ画面でJPに戻し、引き続き日本版を入れることができました。設置ですが、ハシゴ状の棚の足に紐で結びつけています。左側には壁掛けできないものですから。

後から推測したこと

• Professional Firmwareから入れられたのはアメリカ版だったような気がする
• 事前にわけもわからずaccept_open_rt_fmt 1していなければtftpでの復旧は無理だった気がする

DD-WRTはよく「tftpのタイミング」が一つの壁として話題になりますが、arpを併用するとすんなり通ってしまうようです。MACアドレスもubootenv listでわかるので、デバッグ画面で事前に情報収集しておくと良いのでしょう。

P.S.
無線LANチャンネルの件は、Professional Firmwareで管理画面のコマンド実行からubootenvで地域をJPにする手があったようです。その後なら日本版純正ファームも入ったかもしれません。

Outlook.comがIMAP対応なんてニュースが飛び込んできたので、早速Thunderbirdの設定変更とフォルダのコピーをしました。

Microsoft的にIMAPのノウハウはいつの実戦投入可能と判断したのでしょう。Office 365が先行していましたが、同じ実装なのかに少し興味があったりします。

また、大陸からサイバー攻撃の可能性ありなんてニュースがあったものですから、MovableTypeを最近サポートが切れたオープンソース版4.38から5.2.7に更新しました。

テンプレートやプラグインで修正が必要なら面倒だなあ、と4.292からオープンソース版に切り替えていたのですが、特に問題なく移行できてしまいました。念のためVMWare上で構築して試したりもしましたが、拍子抜けしたぐらいでした。

元々MT5対応の4.3.8だったPageButeを、一応更新しておきましたが、その程度。

さらにMariaDBとApacheも更新しました。標的になりそうなこともほとんどありませんが、加害者にさせられては困るので一通り。

Apacheは2.2に移行した時にServerTokensとServerSignatureを設定し損ねていたのですが、Include conf/extra/httpd-default.confのコメントを外した上でそのhttpd-default.confの中を弄れば良いということで、久々に元に戻りました。でも2.4への移行準備もしないといけない時期なのでした。

いきなりIndex 0EEhでString Descriptorを取得に来ることで悪名高いMicrosoft OS Descriptorですが、xHCIだと読みに来るものが限られるようです。

どうもUSBスタック(正確にはハブクラスドライバ?)が主体的に行なうものらしく、Windows 8以降のMicrosoftスタックだと読みに来ますが、少なくともルネサスのスタックだとOSに関わらず、Extended Propertiesを読みません。Extended Compat IDは読みます。

他のメーカーは不明ですが、基本的にルネサスはEHCIスタックをベースに開発したのでしょうから、Windows XP初期に実装されたものだけが引き継がれ、結果として制限事項になったと推測しています。

ということは、例えば.inf無しでWinUSBを読み込ませる企ては、限定的にしか実現されないことになります。DeviceInterfaceGUIDが書き込まれないためWinUSBのAPIから接続できません。

ただしWinUSB.sys/.dllの読み込みまではできるので、Device ParametersにDeviceInterfaceGUIDを書き込めば(通常の管理者権限で可能)何とかなります。個人使用ならこれで充分でしょう。

まとめると、回避法は以下になります。

• Windows 8以降でMicrosoftスタックを使用
• xHCIポートを使わない
• HCKにinfを申請し署名入り.catファイル発行(有償)
• DeviceInterfaceGUIDを手動で書き込み
• 自己署名とテストモード
• 32ビット版WindowsやXP x64