投稿者: babalabo

「在庫1点ご注文はお早めに」という惹句に乗せられてアマゾンに注文を入れた．BUFFALOの1TB HDW-PD1.0U3の中古品，15,200円．その他，書籍１点と保温ポットで計３点．送料が無料になるというので，プレミアム会員の30日お試し期間を使う．1ヶ月500円という会費は経常的に無理なので，入荷したら速攻で解約することになりそうだが…ポットはすでに昨日のうちに発送されているが，それ以外は週明けになりそうだ．保温ポットはかなり迷ったが，ピーコックのWCI-12 1.2L を選択した．前使っていた象印のCH-CE10 1Lは蓋がねじ式でとても使い易かったのだが，再沸騰ができないという不満があった．

わたしはもともとケトル派なので，電気ケトルと保温ポットのどちらにするかというので相当迷った挙げ句の結論だ．というか，そのあと，IH卓上コンロというのが出てきたのでさらに迷いが深まった．確かに，卓上コンロというのは前々から欲しかったものだし，「お一人様」向けの製品がいろいろあり，これからの暮らしを考えると室内で煮炊きができるというのは画期的であるように思われたのだが，500W製品というのを見て，以前使っていた「ラーメンヒーター」を思い出した．もう使うこともないだろうと思って天袋に押し込んであったが，ガスが止まったとき，急遽K子ちゃんから送ってもらった唯一の熱源だ．100/220V共用で海外に買付けに出かけるとき携行していたものだという．

また，これを使ってみようかな～と思ったのだが，お湯が沸くまでの時間が掛かり過ぎる．200CCくらいの水量で20分も掛かる．いまのIH製品なら1分足らずで沸かしているのではないだろうか？電気代もかなり掛かりそうなので，これを使うという選択肢はないような気がする…という辺りでもう一度反転して保温ポットに落着したという次第だ．保温ポットはヨーグルトを作るときの保温熱源にも欠かせない．

象印の前に使っていた2Lのポットは普通の家庭用ポットで，明け方まだこちらが布団に入っている時間帯に「シュンシュン」と沸き始めるのがわたしには「朝ですよ～起きなさい～」と聞こえていた．そのあとの象印は無音で一度も再沸騰音というのを聞いたことがなかったが，最近になって（朝方冷え込みが厳しくなった関係だろうか？）朝の沸騰音が聞こえるようになってきたので，「ようやくうちの子になったね」と思っていた矢先，なんの前触れもなくコト切れてしまった．おそらくサーモが切れてしまったのだと思うが，分解できず蘇生を断念した．

昨日はスマホがなぜか発熱していたので，電源を切って早めに休んだ．電源に接続しているのにバッテリーが上がってしまうという事象があり，ケーブル不良かと思っていたが，むしろこれが原因だった可能性がある．朝チェックしてみたら100%になっていた．最近は充電率80%くらいで止まってしまうことが多かったので，100%という数字を見ただけで少しうれしくなってしまう．

なぜだろう？また，開発用フォルダ内の.vsフォルダサイズが1.56GBになってしまっている．再設定するしかない．[ツール]→[オプション]→[テキストエディター]→[C/C++]→[詳細]→[常にフォールバック位置を使用] という項目をTrueに変更し、[フォールバック位置] というところにフォルダ名を指定する．確か，つい最近VS2017を再インストールしたような気がする…

第一陣が届いた．ピーコックの電気ポットだ．思ったより大きかったが，サブノートをデスクトップに移動して長机が広く使えるようになっているので，まぁ，いいんじゃないかと思う．

手前にある取っ手付きのガラス容器はさっきダイソーから買ってきた茶こし（500円）だ．もらいモノの急須が壊れてからマグカップを急須代わりにお茶を淹れていた．マグカップは起き抜けのお茶を淹れるとき，茶殻を捨てて流しでパパパっと洗えるという利点があるが，湯呑に注ぐときどうしてもこぼれてしまい，すぐに拭いてもカップの底が卓面に粘り付いてしまうようになる．急須は洗う手間が掛かるので取っ手付きの片口のようなものを探していたのだが，ぴったりのモノを見つけた．

わたしは渋いお茶が好みなので茶こしの茶葉（200g195円の粉茶）をスプーンで押して絞り切るという流儀だが，なるほどうまいものを考えるものだ．電子レンジに掛けられないのはちょっと残念だが，実用的には不足はない．（カップをチンすればよい）ただ，これは一度で完璧に絞ってしまうので，二煎三煎というのは難しいかもしれない．

無線HDDと書籍の方はまだ届いていないが，ネットで取説を探して読んでみた．どうも，現物はわたしがイメージしていたのとはかけ離れたものだった可能性がある．かなり慎重にスペックを読んだつもりだが，「人の目は自分が見たいものしか見えない」のかもしれない．①初期設定ガイド，②仕様・詳細情報，③リファレンスガイド，④ヘルプ（Android）をすべて読んでみたが，どうもこの製品はファイルのバックアップ用というより，オーディオ・ビデオ機器でコンテンツを共有する（それもかなり不十分に）というのがそもそもの目的であるように読み取れる．つまり，最初から方向性が違う．

USBでPCと接続した場合には多分通常のドライブのように見えるのではないかと思われるが，USB接続と無線接続を併用することはできない．無線接続でルーターに接続し，複数デバイスとデータを共有することは可能だが，「再生可能」なファイルは画像や動画などに限られているようだ．何がどこまでできるのか，実際に接続してみないことには本当のところはわからないが，どうも，またしても選択に失敗したような気がする…USB HDDとして使うのなら，もっと容量の大きなものが同じ価格帯で手に入った可能性はあるし，ルーター接続が必須というのならNASに特化したHDDの方がよかったかもしれない．無線接続しながら充電していると発熱することがあるなど怖いことも書いてある…

無線HDDを店頭で購入しようと思ってヤマダ電機まで出かけたが？手ぶらで帰ってきた．店員に聞いても「なんですか，それ？」という感じで，「取り寄せ」は可能ということにはなったが，ネットで探した方が早い．しかし，部屋に戻ってからネット情報を探しまくったが，結局，これというものを見つけることができなかった．まず，第一に「品薄」という予期しない状況があった．これこれと思うような製品はほとんど「在庫なし」か「販売終了」になっている．無線HDDというのがどういうデバイスなのか，わたし自身よく把握していなかったという面もある．わたしのイメージでは無線HDDというのは，買ってきて電源を入れるだけでただちにWiFi子機（PC）から使えるようになるという感じなのだが，ほとんどの製品はWiFiルータに有線LANケーブルで接続するという仕様になっていう．WiFiルータは持っているが，もともとインターネット接続用のアダプターでLANのコネクタは付属していない．

いくつかイメージに近い製品はあったが，入手可能な製品はバカ高いものばかり．東芝のCavio Aero Cast 1TBはAmazonで80,927円，Kobakoでは161,516円！楽天ではなぜか同じ製品に27,870円という破格の値札が付いていたが，「売り切れ」だ．「USB HDDをWiFiHDDに変換するアダプタ」というユニークな製品がセンチュリーダイレクトというところにあった．4,937円と価格もお手頃なので，これにUSB HDDを追加するというのも悪くないと考えたが，やはり「在庫なし」．

すっかり忘れていたが，2020年の今ごろ，ウェスタンデジタル社のWD NAS 2TB WD Cloud WDBAGX0020HWT-JESN/ホワイト/スマホ対応/タイムマシン対応/ファンレス/iphone7対応というのをアマゾンから購入して返品している．これはクラウドを経由してリモートアクセスするという，わたしのイメージとは真逆の製品だった．価格は10,598円．同じ失敗を繰り返す訳にはゆかない．

予算は1万5千円以内で3TBくらいという心積もりだが，WiFiルータとの組み合わせでそれに近いものを構成することは可能かもしれない．現在作業用PC3機はスマホをアクセスポイントにして無線LAN(WiFi)を組んでいるが，それにHDDを載せるというのがわたしの目論見だ．このイメージに近いもので現在入手可能な製品はあるだろうか？たとえば，バッファローのHDW-PDU3-Cはこれに近い．WiFiルータとはWiFiで接続，PCとはUSB接続もできるのでドンピシャと言ってもいい．残念ながらこれは，販売終了になっている．

後継機ないし売れ残りはどこかにあるだろうか？LaCie HDD ポータブル ワイヤレスハードディスク Wi-Fi接続 NAS 1TB USB3.0 AirPlay 5台同時接続 FUEL 9000436KUAというのもあるが，これも在庫切れ．⇒楽天には在庫がある．10,800円．有線LANでルーターに接続するタイプなら，BUFFALO NAS スマホ/タブレット/PC対応 ネットワークHDD 3TB LS210D0301G というのがある．3TBで13,455円．

アマゾンにHDW-PDU3-Cシリーズで1TBというのがあった．在庫1点ご注文はお早めにとある．価格は15,200円．容量的にはちょっと…だが，「買い」かもしれない．価格の表示はないが，別のページには1TB HDW-PD1.0U3は「現在在庫切れ」となっていた．東芝のAeroCast は1TBで8万円もするのだから，これを買うしかないのではないだろうか？というか，もたもたしているうちに，売れてしまうかも…これは中古品だが，いまのところ，これしかないような気がする．

かなり環境が整ってきた．デスクトップ上にPCを集めて，椅子を動かさなくてもすべての作業をシームレスに実行できるようにした．中央のモニターにはビデオ切り替え機のボタン一つで，３機すべての画面を表示できる．キーボードとマウスはMouth Without Bordersで共有しているので，多少時間の掛かる処理を行うときは，正面のキーボードを使う．

快適だ！あと欲しいのは無線HDDだけだ．３TBくらいのHDDが手に入れば，バックアップをすべてこのHDDに移し，負荷を軽くした状態で常時完全スキャンが実施できるようになる．この無線HDDは言ってみれば，クラウドの代用のようなものだ．これができれば，万全と言ってよいのではないかと思う．いま悩んでいるのは，ポットを購入したものかどうか？という些細なことだ．現在はポットの代わりに炊飯器で代替しているが，それほど不便は感じていない．場合によっては，昔のようにヤカンでお湯を沸かすようにしてもいいかな？とも考えている．

横書き機能もだいぶ整ってきたが，まだメモリ描画環境に切り替えると描画できなくなるという不具合が残っている．⇒ビットマップ生成の問題というより，再描画の問題なのではないか？そもそも，メモリ描画環境は論理座標系なのか物理座標系なのか？ビットマップにはピクセル単位で描画しているはずだから，当然物理座標系と考えられるが，そうなっているだろうか？少し頭を冷やして考えた方がよい．メモリ描画環境の内容をJPGファイルに保存してみた．下図のようになっている．

　

つまり，メモリ描画環境ができ損なっているということだろう．これができていなければ話にならない．⇒メモリ描画環境生成時，Refreshに渡す引数のrcBoundsを空にして描画できた↑．ただし，背景は塗りつぶししていないため，真っ黒だ．⇒ようやく描画できるようになった．

この論理で正しいということを確認しておこう．通常，座標系は論理座標系と物理座標系に大別されるが，このシステムではそれに加えて第三の座標系とも呼ぶべき「直交座標系」が使われている．通常，論理座標系と物理座標系の変換は，主に座標のスケールと向き，および原点位置に限定され，X軸とY軸の交換までは実施しない．直交変換は図形データが描画プリミティブに渡される直前でXY座標の反転を実施，上位関数からは隠蔽される仕組みになっている．

この仕掛は概ね動作していると言ってよいと思われるが，ビットマップ描画環境では多少話が変わってくる．ビットマップメモリはそれ自体1個の描画デバイスコンテキストだが，書き込みと読み出しの両面で座標変換が必要になる．現行ではこれを以下のように処理している．

1. メモリビットマップのCImageは物理座標系として扱う
2. TREEVIEW::BuildBitMapでは，_CDC::LPtoDPで直交座標変換する
3. TREEVIEW::buildBitMapでは，その逆変換を行って，描画を実行する
4. ビットマップからスクリーンへの転送 BitBltでは座標変換は行わない

これでよいと思う．

今月は povo 1.0 の20GBを一週間足らずで使い切ってしまった．通常20日過ぎくらいまでは間に合っていたのだが…しかも，上限オーバーしてからがいきなり遅い．公称では最大1MBでこれまでは少なくとも700KBくらいはあったのだが…特に上りが異常に遅くなっている．常時三台テザリング接続するようにしているのが効いたのだろうか？三台と言っても，ネットにアクセスしている延べ時間はこれまでとほとんど変わらないはずなのだが…テザリングは所内LAN（WiFi）としても使っているので，それまでカウントすればかなりの通信量になるかもしれないが，それは計算には入っていないはず…1日使い放題220円というのは悪くないと思うが，追加1GB550円では手が出ない．

横書き系図をサポートするために座標軸のXY転換を実装しているところだが，なかなか思ったように進まない．90点程度の小さいサンプルは問題なく表示できているが，500点くらいの規模になるとまったく描画できなくなる．上の方の一部だけは正常表示されているが，下の方になるとまったく描画できていない．

VS2017の更新後，検索がまったく効かない状態になった．最初開発環境からインストールしていたが，いつまで経っても終わらないので（povo 1.0の1日使い放題でダウンロードは完了している）VSインストーラを起動して別途更新を実行し，一応完了したように思われたが，フォルダの全文検索がまったく動作」しないようになってしまった．とりあえず，VSのインストーラで「修復」を試みることにする．⇒回復した．再起動したら，カスペルスキーからまた「脅威」の報告．対象はD:\ZELKOVA 2022-03-02\debug\app.publish\ZelkovaTree2022.exeでハッシュを再計算すると，

066B292370D40C40CBD5B36FA2E0E0C98BA52889BF02CA462F6CEDBFB3D482A8

前回とまったく変化していない．ということはカスペルスキーはハッシュ値をまったく無視しているということになる．除外リストへの登録画面では「オブジェクト名」という項目があり，そこにはウィルスの類別コードが入っているので，その項目を空欄にして再登録してみた．

サブ機でWordPressにログインしようとするときの動作もおかしい．メアドとパスワードを入力しただけで弾かれてしまう．カスペルスキーのパスワードマネージャを使わずに手入力すればログインはできる．パスワードマネージャが壊れているのだろうか？入力したとたんに首を左右に振ってイヤイヤのあとボックスの中身が消えてしまう．⇒パスワードにあまり使われない特殊文字が入っているためではないだろうか？パスワードマネージャからパスワードを直接コピーして入力すれば通る．

メモリ描画環境を使わないという設定ですべてのカードが表示できるようになった．ここまで来ればあと一息だ．

▲ZView.vbを開いて，COUPLING::GetUserFont:フォントサイズゼロエラーが起きる．これはZELファイルのアイコンをダブルクリックしてオープンしようとするときに出るエラーと同じだ．シューティングはかかり難しい．ZView.vbのオープンはデバッグを開始することには当たらないので，デバッガが作動していないから，ブレークポイントなどを仕掛けても止めることができないため，ほとんど状況が掴めない．

障害はCOUPLING::GetUserFontでScaleFontSizeがゼロを返しているために起きている．このあと，MakeSolidFontを実行したあと，GetUserFontを再帰実行して復帰しているが，ループしてしまう．ScaleFontSizeの値がゼロとなる理由として考えられるのは，PNTPERLOGがゼロであるためと考えられるので，この値に初期値1.0を与えるようにしたところ，今度はMAPPINGのズーム倍率がゼロになるという不良が発生するようになった．前門の虎，後門の狼という状況だ．しばらくデバッグというのをやっていないので，SearchWrongObjectなどデバッグ用ツールの錆落としから始めなくてはならない．

TREEVIEW::mapping.zoom_normalがゼロとなっている理由は，TREEVIEWのコンストラクタで固有データ部をゼロクリアしているためだ．それをやっているのはsetpidだが，この関数は共有関数なので広く使われている．MAPPINGのコンストラクタはzoom_normalなどのメンバー変数を初期化しているが，それを上書きしている．廃棄オブジェクトのリサイクルでも同種の問題があり，TRASHCAN::ReuseWasteから呼び出されるdoCleanではメモリを全クリアする前に維持する必要のある変数を保全するようになっている．operator newではメモリを全クリアしているので，setpidで固有データ部を全クリアする必要はないのではないだろうか？この修正の影響範囲はかなり広いとは思われるが，setpidでメモリ全クリアを実施しないようにしてみよう．

まだ，どこかでクリアしているところがある．ファイルをオープンする前に一旦クローズしているが，そこで実行されるEraseTreeViewでクリアしているのではないか？いや，CleanSlotではそこまでやっていないはずだ．EraseTreeViewのあと，COUPLING::Clean→ TREEVIEW::Clean→ doCleanが実行される．この設計はあまりよくないような気がする．オブジェクトを温存させたままクリーニングするより，一度delete してから作り直した方がわかり易かったのではないか？とりあえず，ここではMAPPINGのコンストラクタでやっている処理をclean(void)としてくくり出し，doCleanから呼び出すことにする．

開発機の完全スキャンが完了したが，まだ5件の脅威が検出されている．

これらはとっくの昔に除外リストに登録されているはずなのだが…というか，ハッシュ値を計算しているので除外リストへの登録にはなっていないのだが…ハッシュ値が変化しているとすれば相当な問題だ．ハッシュ値の計算値を記録してみよう．

1. D:\ZELKOVA 2022-03-08\ZekovaVB\obj\Debug\ZelkovaTree2022.exe　80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
2. D:\ZELKOVA 2022-03-08\debug\app.publish\ZelkovaTree2022.exe　80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
3. D:\ZELKOVA 2022-03-08\debug\ZelkovaTree2022.exe　80BFC63F34A43E1A4F0E5B321A2EC3BDED3911AA65984765D06B4E30A00C63AC
4. D:\ZELKOVA 2022-03-02\ZekovaVB\obj\Debug\ZelkovaTree2022.exe　066B292370D40C40CBD5B36FA2E0E0C98BA52889BF02CA462F6CEDBFB3D482A8
5. D:\ZELKOVA 2022-03-02\debug\app.publish\ZelkovaTree2022.exe　066B292370D40C40CBD5B36FA2E0E0C98BA52889BF02CA462F6CEDBFB3D482A8

とりあえず，MAPPINGのズーム倍率がゼロになる問題は解消したものと思われるが，ZView.vbを開いたときのエラーはまだ残っている．

ソースコードの修正が動作に反映しない．⇒Program Files (x86)のbabalaboフォルダに入っているOCXを参照している．アプリをアンインストール→リビルドで動作したが，別のエラーが発生している．基準ノード番号がゼロというエラーだが，無視でファイルをオープンできた．

ファイルをクローズしたときにもエラーが出たが，その後はオープン・クローズを繰り返しても何も出ないようになった．

昔々，OCXを任意のVBアプリに挿入して直ちに動作するような作りを試していたころがあったので，その名残りではないかと思うが，デバッグできないのでどういうフローになっているのか？ほとんど見当もつかない．多分この修正で，ZELファイルのアイコンをクリックして表示されるエラーも解消しているのではないかと思う．しかし，スクロールバーの問題はまったく解決していない．というか，スクロールバーがまったく出なくなってしまった．なぜだろう？

コントロールサイズはOCXのMoveControlイベントで引き渡される．この値が逆転している．現状ではW=1531, H=713となっている．⇒TREEVIEW::GetScrollValueでコントロールサイズを返している．この関数ではGetViewSizeで値を取り出し，LPtoDPで物理単位に変換している．この関数をオーバーライドしてみよう．⇒確かにこの修正は正しいようだ．縦スクロールバーが表示されている．ただし，スクロールバーをドラッグしてもうまくスクロールできない．また，リールを回すとスクロールバー自体が消えてしまう．

LPtoDPは34箇所に出現する．おそらくこれらすべてを書き換える必要があるだろう．⇒とりあえず，引数がtagSIZEであるような箇所だけ修正してみた．これでスクロールバーの操作はリールを含めてできるようになったが，内容は同じだ．つまり，スクロールできていない．これに対処するにはおそらく，引数が矩形の場合と点座標の場合のすべてに対応する必要があるだろう．⇒対処した．完全に動作するようになった．

▲リール操作中，ZView.vbのMoveControlで停止した．AutoPosition.Yが負値になっている．この値は，OCXからMoveControlイベントで渡されたものだ．FramePositionの呼び出しはモードにより，

1. SETFRAME_SCROLLCONTROL
2. SETFRAME_CONTROLSIZE
3. SETFRAME_MOUSEWHEEL
4. SETFRAME_SCROLLBAR
5. SETFRAME_MOVECONTROL

の別があるが，このうちMoveControlSubを実行しているのは，SETFRAME_MOUSEWHEELの場合だけで，それ以外ではInvalidateControl(NULL, false)を実行しているだけだ．しかも，SETFRAME_MOUSEWHEELの場合はInvalidateControlを止めてもスクロール動作になっている．これは前段で実行しているCtrlFramePositionだけで処理をカバーしているということなのではないだろうか？後段を完全に削除しても動作しているので，これでしばらく運用してみることにする．こんな↓感じになった．

なかなかいい感じだ．

▲別のもう少し大きいファイルを開いたら，一部を残して画面が真っ黒になってしまった．カードの位置は正しいが，テキストは出ていない．

生描画に切り替えたら，PrintImpositionで「印刷用紙が小さ過ぎます」というエラーになった．PrintImpositionを止めたら，画面が真っ黒になる現象は止まったが，ある領域から下は描画されない状態になった．つまり，上記と同じ状態と見られる．いや，メモリ描画環境を使うように設定し直したら，やはり真っ黒になる．⇒COUPLING::SetTitleBoxで「タイトル枠描画パラメータを設定し系図外枠矩形領域を最終決定する」ということをやっているので，見てみよう．

論理座標系では系図枠は11458 x 782になっている．物理座標系では親ウィンドウサイズは999 x 697だ．これを論理座標系に換算すると，1146 x 1149になる．TREEVIEW::BuildBitMapでは，描画領域は論理単位では」11518 x 842でこれをLPtoDPで物理単位に換算して，511 x 6989になる．ビットマップはこのサイズに作られる．buildBitMapではLPtoDPの逆演算DPtoLPが実行されている．draw.Size()という計算で1531 x 6989という矩形のサイズ（横幅は現物に合わせている）が，2523 x 11521になっている．

選択枠のドラッグ操作は動作するようになったが，選択枠の中のカードが選択状態にならない．カードをクリックしても選択状態にならない．もう少し調整が必要なようだ．⇒完全に動作するようになった．一覧画面上での操作もチェックしておこう．一覧画面ではクリックによる選択は動作していない．クリックではカード画面上のカードが切り替わるだけで選択状態は変化しない．ダブルクリックするとそのカードが選択状態になる．一覧画面上の操作で選択状態が変化しないという動作が望ましい場合もあるのかもしれないが，ドラッグないしコントロールキー押下による拡張選択もできないというのは少し不便になのではないか？とりあえず，このまま進めよう．

結婚連結線の状態も不良だが，コラッツ木では有配偶者ノードというのは存在しないので，後日対応とする．コラッツ木のサンプルを読んでみよう．⇒読み込みは可能だが，スクロールバーが逆転している．⇒スクロールバーのサイズはフォームが抱えている描画オブジェクトのサイズによって自動的に決定するものではなかったろうか？だとすれば，OCXとVBのインタフェースで整合していないところがあるということになる．この辺りには結構ややこしいやり取りがあったような気がする．

▲ZView.vbを開いて，COUPLING::GetUserFont:フォントサイズゼロエラーが起きる．これはZELファイルのアイコンをダブルクリックしてオープンしようとするときに出るエラーと同じだ．

カスペルスキーが完全テストの度に検出してくる「ユーザーに損害を与える目的で悪用される可能性がある正規のソフトウェア」問題が大体見えてきたので，今後は対処できるだろう．今朝も完全スキャンは複数のEXEを摘発してきたが，すべて除外リスト/ハッシュ値の計算で対処した．これで一件落着としたいところだが，それより重大事態が発生している．ThunderBirdのデータがまるごと消えてしまっている．

考えられる要因としては，①カスペルスキーの認証局証明書をThunderBirdに登録したこと，②FakeTC.cm騒動の原因となったアカウントからのメールをフォルダごと外部に移管したことの2つくらいだが，①の手続きは前にも一度やったことがあるので，それが原因であるとは考え辛い．確かに②は少し荒っぽいような気もするが，登録されているすべてのアカウントに影響が出るほど致命的なものとは思われない…

データフォルダの中身は無傷で残っているようなので，リンクを取り直せば復活するのではないかとは思われるが，なぜこんなことになっているのか？その理由が知りたい．アカウントのサーバー設定を開いて確認すると，フォルダは従来通りの場所にリンクされているが，別のアカウントに移ろうとしたら，以下のメッセージが出た．

原因はわかった．SDドライブがEになっている．確かに以前にもこのようなことが発生して対処したことがある．つまり，ドライブ名が変化しているためだ．これはドライブのプロパティかなにかで変更できたはずだ．ログが残っているはずだが，見つからなかった．ネットで「ドライブ名の変更」で検索して記事がヒットした．スタートメニュー→ディスクの管理だ．ディスクの管理画面でパーテイションを選択して右クリックで「ドライブ文字とパスの変更」ができる．再起動しないと有効にならないので，完全スキャン中だが再起動．⇒復活した！完全スキャンは停止してまた1%からやり直しだ．

さて，ようやく仕事に戻れる．すでに人名枠と系線は横書き対応になっている．対応が遅れているのは，テキストの表示と選択枠だ．この二つが揃うと大体使えるようになる．テキスト描画にはCDC::TextOutとExtTextOutが使われている．この2つを拡張して_CDCクラスから呼び出すようにしてみよう．⇒一応できたが，うまく動作しない．クリップリージョンまで手当する必要があるようだ．⇒暫定的につねにクリッピングを外すようにして描画できた．

縦書きでも横倒しになっているのに，横書きにしても寝たままというのはかなりひねくれている．どこを調整すればよいのか？SetFontOrientationという関数がある．⇒強制的に横書きするように仮修正した．だいぶそれらしくなってきた．

下の方にあるドットは兄弟連結点だ．この点が収まると大体描画できたことになる．各種の連結点はDrawJointという関数で描画している．とりあえず，Ellipseという関数をオーバーライドしてみよう．⇒できたようだ．さて，問題は選択枠だ．下図のような状態になっている．

選択状態は完全に一致するようになったが，選択枠はまだ同期していない．

また，カードをクリックしても応答しない．LButtonDownで渡される座標は物理座標なのでそれを座標変換するとおかしなことになってしまう．SelectFrameXorはDrawFrameRectを使っているが，この関数で直交変換をやっている．

カスペルスキーの「行動原理」が大体飲み込めた．およそ，以下のようなルールで動いているように思われる．

1. 除外リストに登録されたフォルダ内のEXEはスキャンの対象としない
2. EXEの入ったフォルダがコピーされた場合には，マークを付けて監視対象とする
3. 完全スキャンでこのようなマーク付きEXEを発見したときには，削除対象とする
4. フォルダのリネームは（多分）この監視の対象とはしない　ただし，マーク付きのEXEは引き続きトラッキングの対象となる
5. 削除対象EXEは除外リストに追加するか，ハッシュ値を計算することで監視対象から外れる
6. 監視対象EXEが実行されるなどの異変が検出されたときには，完全スキャンを停止する（警告が出る場合もあり出ない場合もある）

従って，このような誤検出（ユーザ的見地からはどう見ても過剰反応のように感じる）を防止するためには，開発フォルダのコピー先をあらかじめ除外リストに登録しておく必要がある．また，除外リストの登録項目を無闇に増やさないためには，手操作で（と言っても計算は自動でやってくれるが）ハッシュ値の計算を実行しなくてはならない．

前日の「UDS:Trojan.Win32.FakeTC.cm」に関しては，おそらくカスペルスキーの過剰反応と見て間違いないものと思われるが，念のためこれに関わるすべての添付ファイルを削除した．というか，それも手が掛かり過ぎるので一部を除きThunderBirdの過去のバックアップをまとめて廃棄処分した．オリジナルのメールに残っている添付ファイルは，分離して別の場所に保管するようにしてみたが，警告がどうしても消えないので，そのアカウントのデータをまるごと外部に移管して対処した．

これで一応このところずっと尾を引いていた問題は基本的に解決したのではないかと思うが，なおしばらくは毎日完全スキャンするのを日課とするということにしておく．横書き対応に関してはとりあえず，以下のようなところまでは動いているので，なんとかなるだろう．

作業効率上の観点から，最近になって開発機をネットに常時接続するようにしているが，その代わりカスペルスキーの完全スキャンを毎日実施している．そして，カスペルスキーは毎日のようにと言うより，毎日，数件の削除する必要のあるオブジェクトを検出している．これらはすべてゼルコバの木のEXEで，つい最近バックアップを取ったものだ．開発フォルダそれ自体は「除外リスト」に登録してあるが，バックアップフォルダ名は毎日変わるので登録していない．これらのEXEは「ユーザーに損害を与える目的で悪用される可能性がある正規のソフトウェア」と認定されている．

これらのEXEが何らかの手段で改ざんされているものであるとすれば，それは真の脅威と言えるが，単なるコピーにカスペルスキーが過剰反応している可能性もある．どういうロジックでこのような判定になっているのかがよく飲み込めていないため，「完全スキャンを毎日実施する」ということの中には「カスペルスキーの挙動を観察する」という項目が含まれている．このような警告は通常完全スキャンが完了したあとに「通知センター」に表示されるようになっている．昨日は完全スキャンを開始してほどなく，以下のパネルが表示されたが，そのまま完全スキャンを続行した．

今日の始業時にはまだ完全スキャンは完了していなかったが（スリープ中は中断されている？），１時間程度で完了し，「21個のオブジェクトが処理されていません」という結果を報告してきた．内容は以下のようなもので，21個のうち，13個がウィルスとしてマークされている．

これらは2006年1月30日にある人物から送られてきたメールに添付されたZIPの中のEXEだ．メールは何度もバックアップを繰り返しているので，これらはすべてそのコピーと考えられる．疑問点はいくつかある．①16年も前のメールの添付ファイルに入っていたEXEが今頃になって初めて検出されたのはなぜか？②メールの送受はサブ機のThunderBirdで行っている．サブ機にもカスペルスキーが常駐しているが，検出されていないのはなぜか？ただし，サブ機では通常の検査しかしていない．

ともかく，まず，サブ機で完全スキャンを実施してその結果を見ることにする．サブ機でウィルスが検出されればよいが，そうでないときはサブ機のファイルと開発機のファイルをバイナリで比較してみる必要が出てくる．もし，不一致があるとすれば，開発機の中のEXEが改ざんされている可能性が出てくる．もし，一致しているのにサブ機の完全スキャンで検出されないとすれば，カスペルスキーの動作そのものがやや疑わしいものになってくる．最近になってカスペルスキーは「個人情報の商用利用の許諾」を求めてきていることから，カスペルスキーに対するわたしの絶対的信頼もやや揺らぎ始めている．

「UDS:Trojan.Win32.FakeTC.cm」をネット検索してみたが，ヒットしない．「FakeTC」で検索したら情報が出てきた．⇒いままで検出されなかったのは，監視条件を厳格化したことが関係しているかもしれない．これまではセキュリティレベルを中間レベルの「最適」に設定していたものを，昨日から最高度の「最大」に切り替えている．サブ機の方も「最大」に設定変更してもう一度走らせることにしよう．

https://www.enigmasoftware.com/faketc-removal/ の記事によると，FakeTCはバックドアトロージャンで活動開始は2011年，セキュリティ関連企業で認知されたのは2015年となっている．FakeTCはアルメニア，ウクライナ，ジョージア，ベラルーシなどで発見されている．開発元はthe Sandworm APT (Advanced Persistent Threat) group (also seen as Quedagh)となっているが，国籍は分からない⇒イランと目されているようだ．このウィルスは主に政府機関や軍事施設に向けたもので，その国のトップレベルの政府要人にSMSメッセージでURLを送りつけ，そのプログラムを自ら実行するように仕向ける．

上記URLはEnigmaSoftという会社のもので，スパイハンターというウィルス駆除ソフトを持っている．15日間の試用版というのもあるので，あとで試してみることにしよう．メールに添付されているEXEはTrueCrypt Format.exeだ．TrueCryptは今でも流通しているフリーソフトで「暗号化された仮想ドライブを作成するツール。仮想ボリュームをドライブとしてマウントするときにパスワードチェックを行うと、以後は自動的に暗号化・復号化をが行われるため、ファイルを利用するたびに暗号化・復号化する必要がない。復号化はメモリ上で行われ、ファイルを残さないので安全。」という内容のものだ．

このメールには発行元のURLとともに「ここが本家です。凄い速度で進化してはいるのですが、根本的な弱点は未解決の様です。 ちなみに、数ヶ月前までは日本語のサイトもあったのですが、現在は跡形もないですね。 」とあり，バグがあることはその当時から知られていたようだ．

FakeTCのオリジナルはこのTrueCryptの弱点を突くものだったようだが，現在生き残っているのはそこから進化して多分TrueCryptとは繋がりのないものになっているのではないかと思う．カスペルスキーはこの「できの悪いTrueCryptのEXE」を潜在的な脅威とみなす判定を行ったのではないだろうか？いずれにしても，これは単純に「削除」でよいと思う．EnigmaSoftのウィルスソフトがこれをどう判定するかを見てみたい気もするが，あとで解約するのも面倒なのでパスしておこう．

自然数を四進数表示すると，フルヌードのビーナス像が現れる．ウソだと思ったら自分の目で確かめてみるとよい．ネット上にはN進数表示のためのツールがごろごろしているから，コラッツ木上の隣り合った数字をいくつか比較してみればホントだってことが分かるだろう．君の目の前にあるのは「整った美の完成型」だ．乱雑でカオス的なコラッツ数列の渦の中にこんな「秘密」が隠されていたなんて信じられるだろうか？

これを見たら夜も寝られなくなる人が続出するかもしれない．実際，昨日からこのブログへのアクセスが急増して一日の訪問者数が100を突破している．ともかく，コラッツ完全木ツールをリリースするまでは全力疾走するしかないね．「コラッツの秘密」が開示される日は近い．

もう少し突っ込んで解析したいのだが，そのためにはゼルコバの木で横書き系図を表示できるようにしたい．それができれば一々PDFに落として，云々の手間が省けるのだが…原理的にはそれほど難しくはないが，かなりの手間が掛かりそうだ．コラッツ三本桜の復活とどちらを先に手掛けたらよいか？コラッツ三本桜の復活は「コラッツ完全木」の完成を意味するが，一度仕事に掛かったらA面・B面の5機能すべてに対応しなくてはならないから，かなりの時間を要することになる．むしろ，思い切ってここでゼルコバの木に横書き系図を導入してしまった方が早いのではないか？ゼルコバの木の座標系は現在，X軸は右から左，Y軸は上から下というオリエンテーションになっているが，横書き対応というのは，X軸とY軸を入れ替えることに相当する．X→Y’，Y→X’とすると，X’は左から右，Y’は上から下に描画されなくてはならない．かなり厄介そうな話だが，やってみよう．

内部の計算は完全に温存されるものとし，座標変換は描画関数で直接実行する．ゼルコバの木系図図面に出力される図形には，①人名枠，②人名枠内のテキスト，③親子連結線，④兄弟連結線，⑤人名枠頭部垂線などがある．描画関数はDrawTreeView.cppとDrawTree.cppに入っているとみてよいだろう．可能ならば，最下位の関数で対応するというのがベストなのだが…切り分けができるだろうか？最下位の関数ということは，WindowsのAPIを直接呼び出している関数ということになる．DrawingObject.cppという未使用のCPPファイルがある．内容は「描画要素オブジェクトクラス」となっているが，これは将来，描画要素をオブジェクトとして扱えるようになったときのためにリザーブしておいたものだ．今回の修正は趣旨はまったく異なるが，とりあえず，ここに修正を要する関数を集めてみることにしよう．まず，使われているWindows APIを特定してみよう．デバイスコンテキストクラスの関数がそれに該当する．ざっと拾い出したところ42個あった．

1. Arc
2. BitBlt
3. DPtoLP
4. Ellipse
5. EndDoc
6. EndPage
7. ExtTextOut
8. FillRect　●
9. FillSolidRect　●
10. GetClipBox
11. GetDeviceCaps
12. GetMapMode
13. GetSafeHdc
14. GetTextColor
15. GetTextFace
16. GetTextMetrics
17. GetTextExtent
18. GetOutputTextExtent
19. LineTo　●
20. LPtoDP
21. MoveTo　●
22. PatBlt
23. Polygon
24. RestoreDC
25. SaveDC
26. SelectClipRgn
27. SelectObject
28. SetBkColor
29. SetBkMode
30. SetMapMode
31. SetPixel
32. SetROP2
33. SetTextAlign
34. SetTextColor
35. SetStretchBltMode
36. SetViewportExt
37. SetWindowExt
38. SetWindowOrg
39. StartDoc
40. StartPage
41. StretchBlt
42. TextOut
    

ただし，これらの関数でも座標に関わりがないものは対応不要と考えられるので，実際の数はかなり限られていると思う．まず，ともかく矩形と直線の描画に関わるものを対象として修正を試みる．対応が必要な関数は上記リストで●をマークしたFillRect，FillSolidRect，LineTo，MoveToの4関数だけだ．これらはCDCクラスの関数だが，CDCクラスをオーバーライドすることは可能だろうか？⇒できそうだ．_CDCという拡張クラスを新設し，以下の関数をDrawingObject.cppに移動した．

1. Bobject::DrawYlist
2. Bobject::DrawParentPath
3. TRIBEBOX::DrawTlist
4. Bobject::DrawLine
5. BRect::DrawFrameRect
6. printtombo
7. printtombo_yoko
8. printtombo_tate
9. Bobject::CallFillRect
10. TREEVIEW::PaintBackGround
11. Bobject::FillSolidRect

一応修正は入ったので，走らせてみたが… どうも，これはかなり手強い．画面はほとんど真っ黒で一部描画されている部分もまったく座標変換になっていない…新規ファイルにすると，こんな感じだ．

ちょっと頭を冷やして考えなくてはならない… 現行ではデバイスのマッピングモードをMM_ANISOTROPICに設定している．これは座標単位と座標軸の向きを任意に設定できるという便利なものだが，X・Y軸を入れ替えるとしたら，少なくともSetWindowExtExとSetViewportExtExで軸の向きを変更しなくてはならない．ゼルコバの木は画面出力とプリント出力をまったく同じ関数で実行しているので，印刷の方も手当しなくてはならないが，ここのところは暫定的にパスしておくことにしよう．⇒少し状況が変わった．画面にはまだブラックなところが残っているが，人名枠が横書きで表示されている！これはいい傾向だ．

おそらく，スケールと軸の向きはこれで正しくなったと思われるが，座標原点の位置が悪いのではないだろうか？SetWindowOrgを呼び出している箇所には修正を入れてみたが，まったく変わらない．なんとか横書きしようとしているのは確かだが…

座標がからんでいる関数は上記のリストの中にまだどっさり残っているが，DPtoLP, LPtoDPが動作しないとまずいのではないだろうか？現行では論理座標と物理座標は等スケールになっているはずだが，GetClientRectなどで取得した矩形領域は論理座標系とは反転したものになっているはずだ．CWndの関数もチェックしておく必要がある．座標に関わりがあるのは多分GetClientRectだけだと思う．mmm… だいぶよくなった！

▲上下カーソルでカードが移動してしまう．おそらくこれは一覧画面での動作だが，カード画面にフォーカスがあるときは無用な動きだ．

枠線や系線がまったく出ないのはなぜだろう？