早朝tamo2さんからメールが入っていた．babalabos@outlook.jp アカウントはわたしの公式アカウトとして「テント村」に表示してあるものだが，これはマイクロソフトアカウントでもあるのでほとんどチェックしていなかった．今回Thunderbirdを整理したついでにサブ機でも受信できるようにしたので受け取れたが，危うくのところだった．現在の作業に関わるテクニカルな内容なのでログ上に転記しておくことにする．

tamo2氏からのメール本文：

VAIOのWindows7、Windows8 及びエイサーのWindows7の機種についてはWindows10にアップデートすればゼルコバの木がインストール可能でした。但しWindows10をクリーンインストールしたら、インストール不可能。私が考えるにはVAIOのPCには古い　.net 2.0 VisualStadioが温存されているのでは推測してます。以前にWindows10 の機種でゼルコバの木をインストールしようとして.net2.0をインストールして下さいのエラーなった記憶があります。又エイサーのタブレットでWindows10にインストールしていたがSSDの容量少なくVisualStadioをアンインストールしたら動かなくなった。

こちらからの返信：（tamo2氏から送られてきた VAIO にはゼルコバの木ベータ2がインストールされている）

tamo2 さま

お世話になります．

tamo2さんの推理のポイントは .NET 2.0の有無というところですね！？大いに考えられます．

＞VAIOのWindows7、Windows8 及びエイサーのWindows7の機種については Windows10にアップデートすればゼルコバの木がインストール可能でした。

Windows 10以前は.NETはオプションだったが，10以降は必須になったためというご理解ですね？

＞但しWindows10をクリーンインストールしたら、インストール不可能。

この現象は他のユーザからも報告があります．→新しいバージョンのWindows 10にはもはや .NET 2.0は常備されていないためというお考えですね．

＞私が考えるにはVAIOのPCには古い　.net 2.0 Visual Studioが温存されているのでは推測してます。

お送り頂いたVAIOで新規ユーザ名でゼルコバの木を実行しようとするとエラーになります．アンインストールすればインストールできる可能性はありますが，アンインストールしてしまうと折角の「ゼルコバの木ベータが根付いている64ビット機」が失われてしまう可能性があるので，いまのところペンディングしています．ただし，インストールが失敗したときの代替手段として，「EXEを直接実行することは可能」ということが分かりましたので，思い切ってやってみようと思います．

＞以前にWindows10 の機種でゼルコバの木をインストールしようとして .net2.0をインストールして下さいのエラーなった記憶があります。

.NET 2.0をインストールしてくださいというメッセージは.NETがすでにインストールされているPCでも起こることがあります．これは環境設定で.NETが無効化されている場合に起きますが，「Windowsの機能」というところで有効化できます．検索ボックスなどで「Windows Features」と入力してエンターキーを押すとWindowsの機能パネルが開きます．また，それと反対に，すでに .NET 2.0以上がインストールされているPCにダウンロードしてインストールしようとすると，このPCにはすでに上位バージョンがインストールされていますと言って弾かれます．

＞又エイサーのタブレットでWindows10にインストールしていたがSSDの容量少なく Visual Studioをアンインストールしたら動かなくなった。

VAIOにはVisual Studioはインストールされていないように見えますが，Visual Studio 8のパッケージがProgram Files (x86)に入ってますね．Visual Studio にはそのときの .NETのバージョンが入っているはずなので，それをアンインストールしたため動かなくなるということは考えられます．今朝目を覚ましたら画面に隠れて以下のようなパネルが出ているのを見つけました．どのタイミングで出たものかよくわかりませんが，おそらくインストール画面を閉じたあとに出されていたのではないかと思います．

まだ試していませんが，→の行をクリックするとオンライン・ヘルプにジャンプするのでしょう．「互換性の設定」という話はどこかで聞いたことがあるので，うまくゆけばインストール時のトラブルがすべて解決できる可能性があります（多分そううまくはゆかないだろうとは思いますが…）以下について調べてみたいと思います．

1. VAIOに新規ユーザとしてログインしてゼルコバの木をアンインストール→これでOwnerがゼルコバの木を使えなくなるとすればマイクロソフトの「落ち度」と考えられる　しかし，新規ユーザとしてゼルコバの木を起動したときの動作から考えると，「すべてのユーザ」を指定していても実際には個別ユーザごとにインストールしていて共有しているのはmsiインストーラだけということも考えられる（実際の動きはそういう感じになってます）
2. VAIOの新規ユーザでゼルコバの木ベータをインストール→成功した場合，保説の蓋然性が高くなる
3. VAIOに.NET 2.0がインストールされているかどうかを調べる（昔はコントロールパネル→プラグラムと機能でインストールされている.NETのバージョンがずらずらと出てきたのですが…）
4. すでに上位バージョンがインストールされているPCに.NET 2.0（ないし下位バージョンの.NET）をインストールする方法を調べる　C++のディストリビューションをインストールするという手があるかもしれない
5. 「プログラム互換性アシスタント」の動作と「互換性の設定」について調べる　可能ならばそれを使ってインストールを試す
6. 他の機種でも「EXEを実行して直接起動」が動作するかどうかを確認する
7. ゼルコバの木の直近バージョンで古いサンプルが開けることを確認する（EXEから起動したゼルコバの木ベータで*.QDBを含む2012年以前の古いファイルが開けることは確認済み）

ゼルコバの木ベータで.NET 2.0が必要になるというのはゼルコバの木の根っこがVB6(Visual Basic 6)にあるためとも考えられます．VB6の機能はいまでも使っていますが，コード的には変換されているので .NET 2.0は不要ということになったのではないかと思います．貴重な情報のご提供ありがとうございました．大変参考になりました．

馬場 英治

早速にも上記項目のチェックに入りたいところだが，仕掛りになっている本線が思わぬところで難渋しているので，そちらを先に片付けてしまいたい．修正は32箇所で完全に特定できている．コードは何度も読み直してどこにもミスはないと思っているのだが，思ったように動いてくれない．Visual Studioのコンパイラが誤動作しているのではないかとさえ考えてしまうような状況なので，もはや「本格的なデバッグ」に入るしかないのではないかと判断しているのだが…さて，今日中にこのトラップから脱出できるだろうか？

ありゃ，おかしい．tamo2さんへの返信で添付したはずの画像がメールに入っていない．入れ忘れたのだろうか？画像はVAIOのスクリーンショットだが，Mouse Without Borders で受け渡ししたあと消してしまったのでどこにも残っていない…あ，パネルはまだ閉じていなかった．以下のようなメッセージだ．

WinMergeを使って全ソースファイルの比較検査を行ったところ，ミスがぼろぼろ出てきた．⇒修正を入れて，少なくとも旧版の部分は復元できた．あとはこれをデバッグするしかない．バックアップを取ってから始めることにしよう．修正箇所にはすべて「NODULE：nodegeneをBobjectに移管する＠20201020」が入っているので，この部分だけ検査すればよいはずだ．まず，複数クラスに新たに追加した変数nodegeneをコンストラクタで初期化しておいた方がよい．対象クラスはCARDLINK, MARGBOX, COMPLISTだけだ．

tamo2さんからVAIO ノートパソコンが届いた．パソコンと一緒にお菓子まで！パッキングするときはお菓子を詰めましょう！

Version 1.9.9.99が走っていると聞いたのでてっきり32ビット機と思っていたが，64ビット機だった．ほとんど新品同様！RAM 8MB, HD 100Gもあるのでサブマシンとして使っているタブレットの2倍のキャパがある．このタブレットはときどき電源が入らなくなったり，かなり不安定なところがあるのでバックアップ機になりそうだ． ゼルコバの木ベータ２では新しいバージョンで作ったサンプルは読めないので，古いサンプルを探してみよう．2013年頃のサンプルならかなりあるのだが，Version 1.9.9.99をリリースしたのは2012年の3月だ．サイトのバックアップにはかなり古いものがあり，その中にもサンプルがある．

外付けHDのバックアップにあるZelkova Shootsフォルダにはアルファ版のサンプルまで入っている．tamo2さんはすでに1万件に近いデータを入力されているゼルコバの木の最強ユーザだが，ずっとVersion 1.9.9.99を使われているので，いよいよとなればZELファイルの入ったフォルダを一括コンバージョンできるようなツールが必要かもしれない．ちょっと厄介な問題が出てきた．これまではまったく意識されてこなかった点だが，どうもmsiインストーラでインストールされたプログラムはインストール元のmsiと紐付けされているのではないだろうか？

tamo2さんから送られてきたノートにはあらかじめゼルコバの木ベータ２がインストールされていて起動できることも確認してあるが，別のログインアカウントを作ってそこから開こうとすると，msiのファイルを探す動作になってしまう．ゼルコバの木ベータ２のアイコンは新しく作ったアカウントのデスクトップにもあって使える状態にはなっているのだが，起動できない．実行しようとすると以下のようなパネルが出る．

このmsiインストーラのコピーをデスクトップ上に置いて，「ソースを使用」ボックスに入力してOKを実行すると，

のようなメッセージが出て「致命的なエラー」で終わってしまう．もし，ここでこの新しいユーザがこのアプリをアンインストールした場合，元のユーザはどうなってしまうのだろう？常識的に考えれば元のユーザはこれまで通り使えなくてはおかしいということになると思われるのだが…アンインストールは簡単だが，それをやってもし元のユーザからも使えなくなると元も子もなくなってしまう．ともかく，別のマシンを使ってVer 1.9.9.99が任意の64ビット機にインストール可能であることを確認しておこう．このマシンには一度もインストールしたことがないので試してみることにしよう．⇒ダメだ．

どこが違うのだろう？tamo2氏のノートはCPUはIntel Core 13-3227U でOSはWindows 10 Home 2004 64ビットだ．OSのインストール日付は2020/08/09なのでつい最近インストールされているみたいだが…コメントを読み直してみると，Windows 8から10にアップデートしたとあるので，Windows 8の時期にインストールされたものと思われる．しかし，Windows XPでも64ビット版があるくらいなのだから，このWindows 8も64ビットOSだったのではないだろうか？だとしたら，プラットフォーム的にはそれほど隔たりはないはずなのだが…

いずれにしても，このマシンでいまこのアプリをアンインストールすると再インストールできなくなる可能性はかなり高いような気がする．もちろん，ゼルコバの木の新しいバージョンなら問題なくインストールできるはずだし，新しいバージョンのゼルコバの木は古いバージョンの系図ファイルも読むことができる．新しいユーザでアンインストールしても古いユーザはアプリにアクセスできるというのなら，新しいアカウントで再インストールを試すこともできるが，失敗するとゼルコバの木ベータが走る64ビットの貴重な参照マシンを失うことになりかねない．

インストール時に「すべてのユーザ」ではなく「このユーザのみ」としておけばこのような事態にはなっていなかったと思われるが，デフォルトで「すべてのユーザ」となっているのでそうするのが普通だろう．新しいユーザでアンインストールして古いユーザが使えなくなるとすれば，それはマイクロソフトの「過失」に当たるとは思われるが，インストールに関してはあらゆるところでトラブルが発生しているので，到底安心してお任せという訳にはゆかない…

このマシンにインストールされている版のバージョンが確定した．バージョンは1.9.9.99だが，このバージョン番号を持ったリリースはある事情から複数存在する．そのうち，この版は2012年3月26日にビルドされた版だ．これはインストーラのサイズ4,235,264バイトおよび，ライセンスコードのMNERKEGが一致することにより特定された．なるほど，だいぶ実情が分かってきた．このバージョンはネット上で公開されていたものと思われるので，「公開版」と呼ぶことにしよう．

これまでの所内テストではゼルコバの木ベータないし，32ビット環境で構築されたバージョンは64ビット環境では動かないものと決めつけてきたが，tamo2氏からお送り頂いた実証機によってそうではないということが確証できた．確かにVer1.9.9.99のリリース版は64ビット機にインストールできないが，実際には「実行可能」であることが明らかになった．つまり，インストールするのではなく，直接EXEのアイコンを叩いて起動してやれば何の問題もなく動作する．

結局，マイクロソフトはややこしい（飛び切りスマートな）ことをやりながら，動作するものを動作させないということをやってきただけということになる．妨害行為とまでは呼ばないが，事実上それに近いと言ってはばからない．その結果バカバカしいことでバカバカしいほどの時間の空費が発生しているのだから…ひどい話だね～

これで問題は一つ片付いた．つまり，32ビット版は64ビット機上で動くということが発見された．32ビット版が64ビット機にインストールできないのはやむを得ないとしても，それが「使える」ことが分かればかなり救われる．これで残る問題は「64ビット機で開発した版を32ビット機上で走らせることができるか？」という問題に絞り込まれた．原理的に言えば「動いて当然，動かなければおかしい」ということになるが，いまのところ32ビット機というのは手元にないので確認できない．

ようやく動き始めたが，多重が13件も出ている．1点だけ見てみよう．

上の2つのカードの位置（世代）を厳密に一致させなければ多重は解消しない．そのような箇所が13箇所もある．これだけ見ても天皇家系図を多重カードゼロで描画するのが如何に困難かご想像頂けると思う．

マイクロソフトが系図作成ソフトを販売している！やられたかな？開発元はIW Technologies LLCという（怪しい）ところで多分2011年にはすでに発売されていたのではないかと推定される．販売価格580円！価格的にはゼルコバの木に勝ち目はないが，スクリーンショットで見ると下図のようなシンプルなものなので，まだ当分の間リードを保つことはできるだろう．お手頃価格なので当所の財政でも購入可能だが，評価はもう少し手が空いたときにやることにしよう．

いや，これは「マイクロソフトストア」で販売しているというだけでマイクロソフトが開発したものではない．この手の系図作成ソフトは掃いて捨てるほど存在する．昨日見たのはこれではなかったような気がする．Windows 10の新機能というポップアップから誘導されたところにあったと思う．⇒出てきた！この画面だ．

Family history and occasions

よく見るとこれらはすべて「テンプレート」だ．つまり，Excel, Word, PowerPointなどを使ってこれくらいのことができますというお手本．確かにこれは頭のよいやり方かもしれない．特別な系図作成ソフトを使わなくてもそれなりに見栄えのするコンパクトな系図図面が出力できるというのは結構需要がありそうだ．「Buy Microsoft 365」というボタンが表示されている．Microsoft 365はサブスクリプションで個人用でも年間1万3千円掛かる．確かにOfficeは有用なアプリなのでそのくらいの値打ちはあるかもしれない…こういう汎用性（なんでもできるという万能感）のあるソフトというのはわたしの好みだ．

Shirley（ミニノート）へのVisual Studio 2017のインストールは完了している．ツール→拡張機能と更新プログラムでMicrosoft Visual Studio Installer Projectsをインストールしてからソリューションを読み込んだところ，VBを除く3つのプロジェクトがすべて（利用不可）になってしまった．これはエンタープライズ版を立ち上げたときと同じ状況だ．32ビットCPU機のShirleyにVisual Studio 2017をインストールすること自体は成功しているので，64ビット機（のVS2017）で構成したプロジェクトは32ビット機（のVS2017）環境では動作しないということになる．32ビット環境でプロジェクトを構築し直せば多分使えるものができるのではないかと思われるが，手が掛かりそうなのでしばらくは置くことにして本線に戻ることにしよう．

天皇家で垂線がブツブツに切れているという問題がある．これほど「派手な不具合」が長期間見過ごされてきたということは考え辛いので，VS2017に移行したことによって発現した不良であると考えてよいのではないかと思っているが，真偽のほどはいまのところわからない．バージョンパネルやカード画面の下部が切れてしまうという事象もVS2017で初めて起きていると考えられるのでVisual Studioの生成するコードに何らかの変異が起きていると考える方が素直なのではないかと思う．

描画がこの程度に壊れていれば目視で確認することも容易だが，ごく一部の線分が切れていたりなどのことがあったとすれば見落としてしまうこともあり得る．正しく描画できているか否かの検査は目視で行うしかないが，テストサンプルは膨大でしかも包括テスト中はめまぐるしい速度で画面が更新されるのでその中で不良を目視で発見するというのはかなり難しい．ここから目視に頼るのではなく，論理的に不良を検出できるようにしておくべきだという教訓を得て，線分の接続関係をグラフの連結性の問題として抽象化するという方針を立てた．

作業は順調に進んでいるが，テスト環境を構築する前に昨日提示した2つの改善項目を片付けてしまうことにする．実際これらを片付けてしまわないと思わぬところで不測の事態が発生するリスクがあるので先行して解決しておかなくてはならない．課題は2つあるが，分節すると，①SIMPLENODEにリスト構成用のスロットを増設する，②LISTクラスを拡張して任意のスロットを用いたリストを構成できるようにする，③NODULE::nodegeneをSIMPLENODEに移管する，④nodegeneを参照しているタスクでは枝グラフ生成時に値を設定するのようになる．

このうち①，②，③は比較的簡単な話だが，④については少し考えておく必要がある．有限半集合を推移簡約表示したものというのがハッセ図の定義だが，ここで使っているハッセ図という用語はもう少し特殊なものだ．系図は親子関係を半順序関係とする有向非循環グラフと考えることができるから，それを推移的に簡約した配置を求めることが系図作成のための図法であると言ってもよい．ゼルコバの木では結婚枠ないし人名枠を「世代」によって階層表示しているので，平面描画可能なハッセ図を生成するためにはどうしても世代を考慮しなくてはならない．

重婚同類循環グラフ検定では重婚同類グラフ1, 2, 3という3つの枝グラフを使用している．ここでハッセ図と呼んでいるものは内部的には重婚同類グラフ2と呼ばれるものに等しい．この処理をアプリケーションから切り離して完全に抽象化するというのは難しいというより不可能と考えられるが，SIMPLEEDGEには類似概念としてgenerationというのを扱っているので，これがどういう動作になっているのかを見てみたい．generation→_generationと改名して出現箇所をチェックしてみる．

この値は，SIMPLEGRAPH::addで設定されているが，参照されている気配がない．おそらく「このパラメータは現在使われておりません」という状態になっているものと思われる．不用なものが入っているのは望ましくないので廃止しておこう．「SIMPLEEDGE_generationを廃止＠20201020」を定義してコンパイルオプションで切り分けることにする．⇒廃止した．ここで一応バックアップを取っておこう．さて，nodegeneをSIMPLENODEに移すことができるかどうかを見ることにしよう．問題はこのパラメータをどこで設定しているか？にある．

この値は基本的にハッセ図を扱うところでしか参照されていないのではないかと思うのだが…⇒値はnodule::setnodegeneで設定されている．初期値0を与えているところを除外すると，以下の関数でsetnodegeneが呼び出されている．

1. NAMEBOX::MakeExtractBox
2. TOPOLOGY::TestInevitableMultiZeroのステージ【18】
3. TRIBELIST::AdjustTribeGeneration
4. SIMPLEGRAPH::TightenHasseDiagramのステージ【７】
5. SIMPLEGRAPH::DownStreamHasse　3箇所
6. SIMPLEGRAPH::UpStreamHasse
7. TREEVIEW::UpdateDiagram

setnodegeneの逆関数getnodegeneの出現箇所を見てみると68箇所もある．ファイル単位ではInevitableMultiCard.cpp，Potential.cpp（検査用），SimpleGraph.cppの3本で基本的には枝グラフ処理の内部処理ないしその関連と考えられる．

TestInevitableMultiZeroとAdjustTribeGenerationはTRIBELISTのTribeRelocationの中で一回だけ実施される．前者はステージ【５】重婚同類グラフ検定，後者は【５.１】で実施されている．UpdateDiagramは描画フェーズの中でしか実行されないので，操作不要と思われる．SIMPLEGRAPHクラスの関数ではすでにグラフは生成済であるはずだから，内部の値を参照することは可能と考えられる．つまり，nodegeneはTribeRelocationの中で設定され，グラフ検定の内部で操作されているものと推定される．重婚同類グラフ検定の概略手順は，

1. TOPOLOGY::TestInevitableMultiZero
2. TOPOLOGY::VerticallyTightenHasseDiagram
3. TRIBELIST::AdjustTribeGeneration

のようになっていると見てよい．MakeHasseDiagramは最初のTestInevitableMultiZeroの中で実行されているので，少なくともnodegeneのスコープは重婚同類グラフ検定中と見て間違いないと思われる．ただし，最後のAdjustTribeGenerationはグラフ検定によって決定されたnodegene（絶対世代番号）に従って構成要素の再配置を実施しているはずなので，この時期までは関係する枝グラフが存続していなくてはならないと考えられる．しかし，その修正を一時に導入するというのはリスクが高過ぎる．nodegeneが必要となるオブジェクトはCARDBOXとMARGBOXだけなのだから，むしろその上位クラスであるBobjectに預けるというのが順当なのではないだろうか？

HasseDiagramに関連する関数はSIMPLEGRAPHのクラスメンバーということになっているが，ここで扱っている図式は数学的に定義された純粋なハッセ図ではなくむしろその応用と考えるべきであり，その意味ではこれらの関数が応用クラスであるBobjectを参照しなくてはならないという構成の方がより論理的であるように思われる．つまり，SIMPLENODEにnodegeneを持たせるという仕様はSIMPLEGRAPHに不純な要素を持ち込むということに他ならない．これで方針は決まった．

tamo2さんからコメントが入っていた．i5のVAIOノートを送って下さるという．このパソコンではゼルコバの木ver.1.99999が走っているという．ありがたい！これがあれば鬼に金棒だ．さて，修正に取り掛かることにしよう．③と④は③’NODULE::nodegeneをBobjectに移管するということになる．この修正はキャストをちょこっと直すだけだから，すぐにでも終わる．「NODULE：nodegeneをBobjectに移管する＠20201020」を定義した．

まずい．一つ勘違いしていた．CARDBOXではなくCARDLINKだ．CARDLINKの親はnoduleでBobjectではない．ではMARGBOXはどうなるのか？少し混乱があるような気がする．いずれにしてもCARLDINKとCARDBOXの対応は1対多だが，MARGBOXとMARGLINKの対応は1対1だから，このまま進めることにしよう．やや変則的になるが，CARDLINKとMARGBOXの両方にnodegeneを置いてみる．

少しややこしい話になってきた．COMPLISTでもnodegeneを使っている．なぜだろう？COMPLISTというのはグラフの連結成分リストで純グラフ理論的なオブジェクトであるはずなのだが…どこかで必要になるのだろうか？かなり面倒くさい話だが，現在のロジックを壊す訳にはゆかないので，COMPLISTにもnodegeneを持たせるしかない．これでは結局SIMPLEGRAPHの内部に外部要素を抱え込むことになってしまうのだが…NAMEBOXでもnodegeneが存在することを予定したコードがある．この論理は少しおかしいのでコメントアウトしておく．場所はNAMEBOX::AbsoluteGeneGapだ．

Dドライブの空き容量がゼロになってしまった．Eドライブにはまだ151GBの余裕があるので少し空けてみよう．バックアップフォルダはZELKOVA_2021とする．テストサンプルも相当大きいのでCドライブに移すことにしよう．⇒エクスプローラのドライブの残量表示バーがすべて青になった．Dドライブは37GBの空き，Cは64GB，Eが129GB，外付けのGが926GBとそれぞれ適当な空き領域を持っている．これだけあれば，しばらく遊べるだろう．

CARDLINKにはcleanという関数がないのだが，いいのだろうか？MARGBOXにはある…TESTABSOLUTEGENERATIONというオプションは一時的に止めておくことにする．⇒どうも訳が分からなくなってきた．nodelist の中にCOMPLISTが入っている．どういうことになっているのだろう？「予定が狂った」というのはこのことだ．nodelistには181個のノードが入っている．⇒ハッセ図を扱っている重婚同類グラフ2の節点はCOMPLISTだ．これはキャストをCARDLINKからCOMPLISTに変えれば対応できる．

どうもどこか壊してしまったようだ．SIMPLEGRAPH：TightenHasseDiagramのステージ【７】移動対象となる人名リンクの絶対世代番号を設定するで停止してしまう．(MINMOV == _INT_MAX)になっている．ループの中ではまともな値を取っているのにループ外にでて突然初期値の_INT_MAXに戻ってしまっている．マネージド デバッグ アシスタント ‘ContextSwitchDeadlock’ という障害まで起きている．確かにどこかでハングしているような気配はある．⇒一度開発機を再起動してみよう．

デバッグアシスタントでは止まらなくなったが，状況は変わらない．「SIMPLENODEsLINKを廃止＠20201019」をオフにして動作を確認してみよう．⇒やはり同じだ．つまり，どこかを不用意に壊してしまったということのようだ．一度バックアップに戻るしかないが，バックアップが動作していることをまず確認する必要がある．⇒確かにこの版はまともに動いている．WinMergeをインストールして比較してみよう．

1. nodule::getnodegeneとsetnodegeneがコンパイルオプションを付けずにまるごと削除されている⇒ただし，このコードはRingLink.cppに移されている．
2. SimpleGraph.cppのSIMPLEGRAPH::TightenHasseDiagramでコンパイルオプションがネストしているところで記述を誤っている⇒ただし，このコードは検査用コドなので動作には関係しない
3. ．．．

大失敗！Shirley（ミニノート）にインストールしたVisual Studio が不調なので，一旦アンインストールした後，再インストールを一晩掛けて実施したが，無料版のVisual Studio Communityをインストールしたつもりで，Enterprise版をインストールしてしまった．Enterprise版は30万円もする上，既存プロジェクトが「利用不可」になってしまう．これをアンインストールするだけで1時間くらい掛かりそうだ．

親子連結線の途切れを自動検出するためグラフ理論を応用したツールを作成することを意図しているが，すでに実装済の抽象グラフ検証系の仕様を調べておこう．ゼルコバの木では以下のような検定グラフをグラフ検証系の応用として実装している．

1. 逆転循環検出枝グラフ
2. 血統軸線図用枝グラフ
3. 系列木グラフ枝グラフ
4. 重婚同類グラフ1
5. 重婚同類グラフ2
6. 重婚同類グラフ3

これらはすべてSIMPLEGRAPH（検定用枝グラフ）として実装されている．SIMPLEGRAPHは①NODELIST，②EDGELIST，③COMPLISTを管理している．NODELISTはグラフの頂点集合，EDGELISTは辺集合，③COMPLISTは連結成分集合を意味するものと思われる．SIMPLEGRAPHの特徴はグラフの頂点としてシステム上の任意のオブジェクト（NODULE）を参照できるという点だ．NODELISTはSIMPLENODEのリストでSIMPLENODEはnoduleを参照している．EDGELISTはSIMPLEEDGEのリストでSIMPLEEDGEは辺の端点を示す2つのSIMPLENODEを参照している．

構想しているグラフを親子関係グラフと呼ぶことにしよう．親子関係グラフの節点は線分の端点であり，枝は線分そのものと考えられる．線分を描画する関数には用途によって各種ある．これらの描画仮数を呼び出すタイミングでグラフが生成されなくてはならないが，これはかなり難しい．描画関数は単純にディスプレイに描画を実行するための外部関数であり，システム内のオブジェクトとはまったく無関係だ．現行ではSIMPLENODE::linkにはnoduleポインタを格納することになっているが，これをvoidポインタに変更可能かどうか調べてみよう．

検定用枝グラフは基本的に対象システムを上から俯瞰するようになっていて，対象システムにはいかなる副作用も与えないことになっているのだから，参照先オブジェクトは必ずしもNODULEでなくても動作しなくてはならないはずだ．⇒この修正は比較的簡単に行えるが一つ問題が出てきた．連結成分の検査に用いているCOMPLISTは対象オブジェクトを直接参照するリストになっている．リスト操作は一般にノードのSLOTZEROを用いて構成されているが，SIMPLENODEはそれ自体リストを構成しているので，SLOTZEROが使えないようになっているためではないかと推定される．しかし，この構成はやや問題があると言わなくてはならない．グラフ検証系が一般的に活用される段階では対象オブジェクトがSLOTZEROを使っている可能性は十分あり得るからだ．

class NODELIST : public NLIST<SIMPLENODE, ‘V’>

どうすればよいか？SIMPLENODEに連結成分リスト用のスロットを設けることが考えられる．既存のリングないしリグという構成が使えるのではないか？   デバッグ用増設スロットというものもある．

1. WASHING –4 UNDOシステムでオブジェクトの再生に用いる特殊枝番
2. SEIZEGROUND -3    アンカー接続：ポインタはメモリ上のセルに格納
3. XPAND_ANCHOR -2    デバッグ用増設スロットを示すスロット番号
4. EXTRA_ANCHOR -1    増設スロットを示すスロット番号

これらのスロット番号が負の値を取っているというところが不気味なところだ．実装者であるわたしでさえ想像つかない…親子関係グラフと夫婦関係グラフを合わせて結婚関係グラフと呼ぶことにしよう．系図木というのは究極のところ結婚木であり，婚姻関係図であると考えられる．結婚関係グラフがデバッグ時にのみ使われるものであるのなら，デバッグ用増設スロットを使うことも考えられるが，場合によっては拡張されたリリースバージョンでも使われるようになる可能性は十分考えられるので正規のスロットを定義しておいた方がよいように思われる．

リング参照リンクという構成が実装されている．これは「環状リスト用の汎用双方向参照」をサポートするためのもので，描画オブジェクトクラスでは2種のリングが使われている．一つは結婚枠衝突検定用結婚枠リング，もう一つは極大グラフ検定用セグメントリングだ．このクラスにはスロットを3つないし4つ使ったグループ参照リストも組み込まれているが，これらは汎用的な処理とはなっていない．現行のリスト処理はLISTクラスを基本クラスとするものでNLISTはその派生型だが，これを任意のスロットを用いる形式に仕様変更するのもかなり厄介だ．

COMPLISTはNLISTの派生型なのでここではキャストを用いて逃げておくことにしよう．クラスCOMPLISTの他にSIMPLEGRAPHでもlinkがnoduleであることを仮定している以下のような操作がある．MakeHasseDiagram，TightenHasseDiagram，DownStreamHasse，UpStreamHasse，RemoveRedundantEdge．これらはすべてNODULE::nodegene（絶対世代番号）を参照しているものだが，NODULEクラスの汎用性を考えるとこのパラメータをNODULEのメンバーとしておくことには問題がある．

しかし，その前にlinkを汎用ポインタでアクセスできるようにするためには，まずこのリンクを固有データ域に移す必要がある．実際，この状態で走らせるとGENEBOX::CheckInverseCycleでSIMPLEGRAPHを初期化しただけで落ちてしまう．

SIMPLENODEsLINKを廃止する必要がある．「SIMPLENODEsLINKを廃止＠20201019」を定義して切り分けるようにしておこう．TestSimpleGraphはコメントアウトした．「SIMPLENODEsLINKを廃止＠20201019」の両面で動作することを確認した．アプリ終了時に64バイトのメモリリークが出ているが，これは既存コードでも同じであり，以前から存在する事象と考えられる．

これで一応オブジェクトを含め「なんでも」グラフ検定の対象とすることができるようになった．たとえば，描画関数で線分を描画するとき，端点情報をどこかに保管できるようにしておけば，それだけで検証用の枝グラフを生成することが可能だ．ただし，その先は少々難しい．

◎COMPLISTは対象オブジェクトのSLOTZEROを使って連結成分リストを構成しているが，SIMPLEGRAPHを完全に抽象化するためにはオブジェクトから完全に分離する必要がある．SIMPLENODEにリスト構成用スロットを一つ設けるのがよいのではないか？任意のスロット番号を指定してリストを構成するようにLISTクラスを拡張するのは新たに組み込みで特殊リスト操作を付け加えるよりはるかに簡単なのではないか？現行ではSIMPLENODE::linkからオブジェクト以外の場所を参照することができるようになっているので，地雷を踏む危険性がある．

◎SIMPLEGRAPHで使っているnodegene（絶対世代番号）をNODULEのメンバ変数とすることには問題がある（一般性がない）．この値がハッセ図を生成するために不可欠であるというのなら，SIMPLENODEに持たせた方がよい．実際，SIMPLEEDGEはgenerationという値を持っている．枝を生成する時点でアプリからnodegeneを設定するSIMPLENODEの関数を呼び出すようにすればよいのではないか？

上記はSIMPLEGRAPHの抽象化レベルを高める上での必須項目である．

どうもはかばかしい進捗がない．Shirley（VAIO 4インチミニノート）はむちゃくちゃ遅いし，Tamoz（3インチタブレット）はタッチペンを使わないと誤動作するくらい文字が小さい．Tamozはそこそこ動いてくれるが，唯一の32bitCPUマシンであるShirleyは泣きたくなるほど遅い．どこかで中古品を見つけてきたいくらいだがともかく辛抱して使うしかない．32bit/64bitというのが問題になっているが，一つ勘違いしていたことがある．32/64という区別はOSの場合とCPUの場合があるという点だ．つまり，32ビット機と言ってもOSが32ビットでCPU64ビットということがある．64ビット機というのは概ねOS64ビット，CPU62ビットと考えて間違いないと思われるが…

これまで確認した限りではVisual Studio 2017でビルドしたパッケージはCPU62ビット機では「ソリューションプラットフォーム」の設定如何に関わらず動作するが，CPU32ビット機では「ソリューションプラットフォーム」の設定如何に関わらず動作しないという状態になっているように思われる．この点を確認するためにはどうしてもCPU32ビット機というのが必要になってくるが，現状唯一のCPU32ビット機であるShirleyは遅過ぎてほとんど使いものにならないというレベルだ．タスクマネージャで不要と思われるバックグラウンドタスクをいくつか殺してみたが，あまり効果はなかった．姉貴の旦那が持っているノートを貸してもらうということも考えてみたが，このノートのOSは多分Windows 7のはずだが、CPUは64ビットである可能性が高い．

今後は32ビット機というときはCPU32ビットのPCを指すものとし，32ビットOSを意味する場合には明示的に示すことにする．（これは通常の用語と少し違うかもしれない…）ShirleyにはVS2017をインストールしてあるが，コンポーネントが不足しているため満足な動作になっていない．Visual Basicに関わるコンポーネントを改めてダウンロードしてインストールしてみたが，どうもまだ思わしくないところがある．Visual Studio 2017自体は32ビットアプリケーションなので32ビット機でも64ビット機でも同様に動作しなくてはならないはずなのだが…

Windows Formの追加で新しい項目の追加が開いてしまう

インストールを妨げる要因として，.NETのバージョンが合わない（必要なバージョンがインストールされていない）場合と，C++がインストールされていない場合がある．必要な.NETがインストールされていても「有効化」されていないと同じようなエラーになる．このような場合はMSからダウンロードしても「すでにインストールされています」と言って弾かれてしまう．ランタイムをMSサイトからダウンロードするsetup.exeも失敗することがある．

Windows 10タブレットは前から使っているが，2 in 1 ノートで通常はキーボード付きで使っているため，キーボードのないタブレット上でゼルコバの木がどのような挙動を示すかという点に関してはほとんど知らなかった．今回tamozさんのタブレット上でZTを起動して初めてかなり悲惨なことになっていることに気付いたが，この辺りはすでに相当昔にkamui氏から指摘されていたところだ．「タッチ操作」をサポートすることはもはや喫緊の課題になっている．

作戦タイムが必要だ．ここでは一旦開始点まで退却するしかないのではないだろうか？つまり，「当面はターゲットを64ビット Windows 10 搭載機に限定する」という当初方針だ．この条件ならインストール可能なバージョンはすでに確保されている．あとはリリース可能な程度までデバッグするだけだ．ここでこれ以上深入りしていたら持ち時間を使い切ってしまう可能性がある．実際，天皇家系図だけでも相当な不具合が生じているのでまずこれを片付けないことにはお話にならない．

ShirleyではVSを一度アンインストールしてもう一度今度はVisual Studio 2017をフルインストールしてみることにする．どのくらい時間が掛かるかわからないが，放置しておけばよいので作業の妨げにはならない．タブレットTamozは32ビットOS（CPU64ビット）だが，64ビットOSのメイン機とまったく同じ動作になっているので動作上の問題はない．「タッチ操作」は「次期課題」としておこう．

Semalt.com によるリファラスパムを遮断する方法

デスクトップ上にはこれまでのランニングテストで発生した障害ファイルが11本もある．まず，これを片付けておこう．⇒いや，特に問題なくすべて開ける．おそらくリリース版でSTOP文が残っているバージョンがあったのだろう．もうひとつ気になっているのは，ヘルプ画面の下の方が切れているという不良だ．

デザイン画面ではもちろんこんな風にはなっていない．このパネルは最前面に表示されるフロートパネルでサイズ変更はできないから，レイアウトの計算などは一切行っていないはずなのだが…MaximumSizeとMinimumSizeを固定したら，とりあえず画面が切れることはなくなった．ただし，デザイン画面とはレイアウトが微妙に異なる…高さはほぼ一致するが，横幅がかなり詰まっている．おそらくそのためではないかと思われるが，フォントが少しぼやけて見える※．Max, Minをデフォルトに戻した場合は縦横ともに均等に縮小する．どういうことだろう？

※これは画面を解像度の高い（ピクセルサイズの小さい）モニターから低いモニターにドラッグ移動して比較しているためではないか？

カード画面もデザインより縦横ともに詰まっている．ただし，横幅の方が少し縮み方は大きい．カード画面は可変サイズなので調整すればデザインとほぼ同等の見え方にはなる．ファイルを開き直したとき，系図画面は前回と同じサイズ・位置に表示されるが，カード画面は位置は同じでもサイズは標準のサイズに戻される．タイトル枠設定画面も可変サイズだが再起動時には標準サイズに戻される．手動で変更したサイズと標準サイズはボタンで切り替えできるので，仕様的にはこれでもよいのかもしれないが，使い勝手からは閉じたときの画面がそのまま表示された方がよいような気がする．

▲表示→タイトル枠表示で系図画面にタイトルの表示/非表示を切り替えるようになっているが，違和感がある．ここは表示→タイトル枠設定画面を表示ではないだろうか？この場合はタイトル枠設定タブがタイトル情報タブより先に来るべきだろう．

描画処理系では座標・サイズとも物理単位（ピクセル）で操作しているが，元々のプロトタイプでTwipという単位を使っていたため保存数値はTwipになっている．Twipは絶対単位で1Twip=1/20ポイント=1/1440インチ=0.01763888mm=17.6μmに当たる．絶対単位では画面上のサイズと印刷出力のサイズは厳密に一致するが，ピクセルの場合はアスペクト比というものがあるため調整が必要になるという点に配慮したものだ．しかし，事実上ピクセルで扱った方がずっとわかり易いので現在ではTwipなどの単位はほとんど廃れてしまっているのではないだろうか？

Twip⇔ピクセルの変換でこれほど大きな誤差が出るとは考え難いので何か別な理由を考える必要がある．フォームのサイズはGetWorkingAreaという関数から取得しているが，この関数が返す値は「ディスプレィの作業領域」とされているので，タイトルバーなどの領域が除外されているのではないだろうか？⇒フォームのWidthとHeightを直接取り出しても同じ結果だ．デザイン画面ではSizeは554×381だが，ヘルプ画面のLoad関数の入口ではこの値は411×282に変わっている．およそ0.74くらいに縮小している．これから推測すると，静的なデザイン画面と実行時の内部（System.Drawing）では座標単位が違うような気がする．

LoadWndPostにも多少疑問はあるが動作は変化しないので，オリジナルに戻しておこう．いまのところ対処策としてはMaxとMinを固定するという方法しかない．ただし，この方法ではカード画面のように実行時に変化する画面を扱えない．カード画面も画面下部が少し切れている．

カード画面のデザイン時のサイズは695×476，Max＝任意, Min＝527×238となっている．カード画面サイズという関数でサイズをランタイムに決定しているが，既定値は現在516×370となっている．修正履歴的に変化しているのに対応していないのではないだろうか？⇒どうもますますわからなくなってきた．695×476を既定値とすると，下図のように下部に広い空白が生じてしまう．

この図面は縮小されているので実際にはもっと大きい．⇒原因がわからないので，暫定的に高さを調整して516×382としておこう．バージョンパネルはもうちょっと縦が詰まってもよいので554×371とする．

▲タモリんちで人名枠線なしのとき人名下部の垂線が人名描画域に越境している．

系図画面設定パネルはとりあえず問題なさそうだが，タイトル枠設定画面はすこしだけ下が切れている．プロパティ画面その他のパネルもサイズ的な問題はなさそうだ．系図画面設定パネルとタイトル枠設定画面の違いはFormBoderStyleで，前者はFixedDialog，後者はSizeableとなっている．タイトル枠設定画面もSizeableとすれば多少の難はあるが，文字が切れたりすることはなくなる．⇒これから言えることは，画面をサイズ変更可に設定すると，システム側で何か余分なことをしてくれるということのようだ．何をしているのかわからないが，ありがた迷惑だ．

タイトル枠設定画面はタイトル設定画面サイズという関数でサイズを決定している．SetupTitleSizeには既定値の516×370が入っている．これは正確にカード画面と同寸だ．というか，①カード画面，②系図画面設定，③タイトル枠設定の3つの画面は完全に同寸というのが元々の設計なのだが…現状ではタイトル枠設定画面は516×373という数字になった．しかし，奇妙なことにこれらの横幅は同じ値を取っているのに不揃いな林檎たちになっている．

調整すれば完全に同一サイズに「見える」ようにすることは可能とは思われるが，これは後日ということにしよう．タブレットで「タッチ操作」を実装しようとするときにはいずれこの辺りをみっちりやるしかなくなるはずなので…一応これで一番気になるところは調整できたことにして，現状で目につく最大の瑕疵である切れ切れの垂線の問題に移ることにしよう．かなりひどいことになっている．

何が原因かよくわからないがブツブツに切れてしまっている．この図面では多重カードは発生していないので，少数の先祖ノードを除けばほとんどすべてのノードには親からの垂線が入って来なくてはならない．途中で線分が切れていることをプログラム的に検出することは可能だろうか？各線分がオブジェクトとして管理されていればそれもそれほど難しい話ではないが，ゼルコバの木では描画出力はすべて描画関数によってディスプレイに直接描画されているため，事後に検査するというのはかなり難しい．しかし，今後このようなことが二度と起きないようにするためにはなんらかの検査関数を作ってチェックする必要がある．

系図図面は人名枠と水平線および垂直線から構成されるが，人名枠を１個の垂線とみなせば，かなり単純な線分の集合とみなすことができる．従って，グラフG(V, E)としてV=｛線分の端点｝，E=｛線分｝からなるグラフを考えることができる．Vの部分集合ｐ={人名枠線分の端点}とし，ｐに属する2つの点pとp’が「親子関係」にあるとき，pからp’に至る経路があるかどうかを探索すればよい．座標計算には誤差があり得るので完全一致できない場合には近傍探索でもよいが，むしろ誤差が発生する原因を追求する端緒としても活用できる．同様のことは夫婦関係についても言える．原則的に夫婦は同じ世代に属すると考えられるが世代差が出る場合もあり得るので同じ手法で一般的に解いた方がよい．

グラフ理論的なアルゴリズム（抽象グラフ検証系）はこれまでにもある程度実装しているので多分それほど難しくはないのではないかと思う．これはあくまで部外の検査であり，リリース版ではそこまでやる必要はないが，描画図形をオブジェクトとして扱えるようになると，たとえば線分をくリックしたときそれに接続する経路の全長をハイライトしたりなどのことができるので，その方向性も考えておく必要がある．さらには線分をクリックして選択→削除で（親子・夫婦）関係を切断したり，人名枠を2つ選択して関係付けなどの直観的操作も実装可能になる．

uuidの更新の問題は置いて，先に32/64ビットの問題を片付けてしまおう．32ビット Windows 10のShirleybirdにインストールできないという問題が続いている．開発機（64ビット）ではソリューションプラットフォームを①Any CPU, ②Mixed Platforms, ③Win32のいずれにしてもリリース版を起動することができるが，ShirleyではWin32でもインストールできない状態が続いている．VC++ 14の再頒布可能パッケージをインストールするsetupでもエラーが出た．VC++ 14の再頒布可能パッケージはマイクロソフトから直接ダウンロードしてインストールできたが，インストール時のエラーHRESULT=2147024770は解消しない．

2.0.2.088という2018年にビルドしたバージョンではHRESULT = 2147010895エラーになる．コマンドラインからmsconfig.exeを実行してSystem Configuration→Tools→Change UAC settings→Launch→User Account Control Settings→Never notifyを設定しても状況は変わらない．2012年の1.9.9.99でも同じエラーが出る．⇒最終手段として実機にVSをインストールしてビルドしてみよう．

ようやくインストールが完了した．開発パッケージの転送だけでもかなり掛かりそうだ．この機械はともかく遅い．ソリューションを開こうとしてエラーになった．このエラーはVSをアップグレードするたびに出てくるが，VSは開発機と同じバージョンなのでおかしい．

OKを押して何が起こるかみてみよう．セットアッププロジェクトが未サポートということのようだ．どう対処したのか忘れてしまった．ソリューションエクスプローラには「非互換」と表示されている．⇒ツール→拡張機能と更新プログラムでInstaller Projectを導入する必要がある．

インストールできたが，セットアッププロジェクトについた（非互換）のラベルは消えない．ともかく，デバッグモードでクリーンビルドしてみよう．1本コンパイルするのに15秒以上掛かっているのでビルド完了までには相当掛かりそうだ．⇒ビルドは完了したが，遅いだけでなく誤動作している．VBプロジェクトにFormを追加しようとしているのに項目の追加パネルが出てしまう．しかもプロジェクトを選択という指示を出しているのになんの選択肢も与えられない．しかもサブメニューのどの項目でも同じパネルが出てくる．IDEが壊れているのかマシンが壊れているかのどちらかとしか考えられない．

もうひとつのタブレット（TAMOZ）を試してみよう．画面は小さいがこちらの方がずっと速いし，動作も確実だ．VSのダウンロードを始めたが，VSをインストールするより前にアプリケーションのインストールの可否を確認した方がよいのではないだろうか？⇒ダウンロードと平行してVSのインストールが実行されているので止めようもないが…TamozにVS2017のインストールは終わったが、ゼルコバの木のインストール時に、.NET 2.0.50727 ないし、2.0 を要求される．マイクロソフトのダウンロードサイトには3.5より番号の小さいバージョンは置いていない※．　上位バージョンをインストールしようとすると，すでにこのマシンには.NET 4.8がインストールされていると言われてしまう．

※Googleで検索すると出てくる．x86, x64の指定も効く

.NETの場合は上方コンパチになっていたはずだと思うのだが…なぜこのような動作になるのか？VBの必須コンポーネントには .NET 4.5.2(x86 および x64)が指定されている．この動作はClickOnceに関係しているのだろうか？どうもこの辺りが関係しているようだ．

How to enable Microsoft .NET Framework 3.5 on your operating system

つまり，.NET Frameworkはインストールされているが，有効化されていないということのようだ．有効化するためにはWindowsの機能というコントロールパネルを出して，チェックを入れなくてはならない．

下位のチェックボックスは空のままでよいのだが，枠が小さくて指でチェックを外せないためそのままOKしたら，Windows Updateになってしまった．タッチスクリーンは箸の先などでは反応しない…電荷が必要なのだろうか？いや，タッチペンの素材はゴムのようなものが使われているので，弾力なのかもしれない…導電性は必要なようだ．

Tamozには2.2.0.008をインストールすることができた．ただし，このマシンは32ビット機と思っていたのだが違う．OSは確かに32ビットだが，CPUはx64ベースつまり64ビット機だ．一方Shirleyの方はOS，CPUともに32ビットだ．Tamozで動作しているのはOSのバージョンとは無関係にCPUがx64であるためと考えられる．このバージョンはWIN32でビルドされているが，おそらくAny CPUでも動作するのではないかと推定される．⇒これは試してみる必要があるが…ともかくAny CPU版を作ってみよう．⇒ビルドに失敗した．

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(3988,5): error MSB3482: 署名中にエラーが発生しました: ..\Release\app.publish\ZelkovaTree2021.exe の署名に失敗しました。

いままで出たことのないエラーのような気がする．VBのプロパティ→署名でCheckOnce マニフェストに署名するのチェックがオンになっている．オフにしてやってみよう．確かに通った．無意識にクリックしてしまったのだろうか？古いバージョンをチェックしてみた方がよい．⇒確かに以前の版ではチェックは落ちている．TamozではAny CPU版も問題なくインストールできた．Shirleyの動作から見るとVS2017で生成した版はCPU32ビット機では動かないということになるのだが…

どうもShirleyの動作自体芳しいものではないのでそう結論付けるのは早過ぎるような気がする．Shirleyは異常なくらい遅いだけでなく，VSの動作でもかなりおかしな動きになることがある．たとえば，ツールと機能でインストールされているプログラムが見つからないと言うなど…⇒いや，今度はそのエラーは出なかった．どうしようもないほどに遅いが，もう少し使ってみることにしよう．

確かにわたしもかなりボケて来ているかもしれない．無茶遅いマシンなのでできる限りダウンロードの容量を小さくしようとしてケチったものだから，C++用のコンポーネントしか入っていなかった．ゼルコバの木ではVisual Basicを併用している．上記の「VBプロジェクトにFormを追加しようとしているのに項目の追加パネルが出てしまう」という事象が起きるのも当然だ．この追加だけで10GB…

▲タブレットはPC代わりにかなり使われるようになっているが，キーボードやマウスを持たないタブレットではタッチ操作のサポートが必須になってくる．

OSの再インストールに掛かる前にあらかじめThunderbirdのprofilesをバックアップし，念のためImportExprotTools NGでプロファイル（アカウント情報）をエクスポートして臨んだのだが，復元に失敗した．Thunderbirdではヘルプ→トラブルシューティング情報→プロファイルフォルダで保存フォルダを確認することができる．再インストール後，このフォルダの中に入っている（複数の）*.defaultフォルダをバックアップしたフォルダで差し替えてみたところ，「Thunderbirdでプロファイルが見つかりません」というエラーが起きるようになってしまった．

悪いことにこのエラーはアプリをアンインストール→再インストールしてアカウント未登録の状態まで初期化しても消えない．つまり，Thunderbirdがまったく起動できないという状態になってしまった．わたしの環境ではThunderbirdメールデータ本体は外部ディスクのフォルダに保存するようになっていて，このフォルダはしっかりバックアップを取ってあるから紛失する虞は皆無だが，プログラムが起動できないということになったら最悪このPCのHD自体をフォーマットしなくてはならないかもしれない．絶対絶命のピンチに追い込まれ真っ青というところだ．幸いこの悪夢からは下記リンクの情報で脱出することはできた…

thunderbirdでプロファイルが見つかりませんというエラー

Thunderbirdのメニューにはプロファイルを操作するコマンドは存在しないが，Thunderbirdをコマンドプロンプトから以下のコマンドでプロファイルマネージャを起動することができる．

＞Thunderbird.exe –p

ここで「新しいプロファイル」を作成し，「古いプロファイル」を削除してやれば問題なく起動できるようになる．新しいプロファイルを作成するときには，アカウント設定やメールデータを保存するフォルダを指定することもできる．これでまたThunderbirdを立ち上げることができるようになったので，ImportExprotTools NGアドインをインストールして，エクスポートしたプロファイルをインポートしようとしたのだが，インポートのコマンドメニューが見つからない．

ツール→設定とデータのインポートはThunderbird付属のインポートツールだが，これはシステムに別のメールアプリがインストールされているときにその情報をインポートするためのもので，いまの場合にはまったく役に立たない．アドオンマネージャはアドオン自体を操作するためのものでアドオンを実行するためのものではない．ImportExprotTools NGをインストールするとツールメニューの一番下にImportExprotTools NGという項目が現れてそこからコマンドを実行することができる．しかし，このときは焦っていたためだろうか？理由はよく覚えていないが，このコマンドを発見することができなかった．

プロファイルのインポートはあきらめて手動でアカウントを３つ登録し，アカウントのアカウント設定→サーバー設定→メッセージの保存→メッセージの保存先で常用している外部フォルダを指定してようやく復元することができた．Thunderbirdで使っているわたしのアカウントはすべてウェブメールアカウントだが，Thunderbirdはネット上の主なウェブメールサーバーを知っているのでこの設定はほとんど自動でやってくれる．最初からそうすればよかったのだが，アカウントごとの細かい調整などもあるのでできれば現状をそのまま復元したかった…

ちなみに現在ネット上で一番安全なメールアカウントはウェブアカウントであるということをご存知だろうか？hotmail, outlook, gmailなどいろいろあるが，昔は「ウェブメールなんて（少なくともフォーマルなコミュニケーションでは危ないから）使っちゃだめだよ」と言われ，捨てメアドなどと蔑まれていたのだが，この間（ネットにアクセスできなかった時期）に大きく変わり二段階認証なども導入されてセキュリティ上もっとも堅牢なアカウトと認識されるようになって来た．逆にドメイン名の付いたメールはそこまでやっていないところが多いので，脆弱なところがかなり残っていると考えられる．（もちろんマイクロソフトやグーグルが本当に信頼できるのかどうか？というのはまた別の問題だ）

ImportExprotTools NGのプロファイルのエクスポート/インポート機能はまだベータ版で動作は保証されない．実際，事後にインポートを試してみたがあまり芳しいものではなかった．一番確実なのは最初からプロファイルマネージャを使って外部フォルダにプロファイルを保存するようにしておくことではないだろうか？現在Cドライブの空き容量は13.4GBある．この作業に掛かったときの空き容量は2.48GBだったので10GB以上増加している．インストールしていないアプリもいくつかあるのでこの先どうなるかはわからないが，OSの再インストールに丸一日を潰しただけのメリットはあったのではないかと思う．

いよいよ本格的な「再開発」の段階に入るところだが，その前に新版と旧版が併存できることを確認しておきたい．ユーザはこれまで使っていたバージョンを温存しておきたいと考えると思われるからだ．馬場研究所でリリースしたプログラムはC:\Program Files (x86)\babalaboというフォルダに格納される．これまではその下のZelkova Tree 2020（古いバージョンではZelova Beta2）に保存していたが，今回の版からはZelkov-Tree 2021に保存するようになっている．わたしの理解ではこれによって2つの異なるインストールを併存させることができるようになっているはずだと考えているのだが，果たしてそうなっているかどうか？試しておきたい．もし，それでうまくゆかないということになるとまたいろいろと厄介な話が出てくる．

ともかく出来不出来はともかくとしてバージョン2.1以下のインストーラを探してみよう．いや，一般ユーザの手元にあるのはおそらく，2.0より前の1.xxxだと思われるのでその辺りとの競合を見た方がよいのではないか？公式リリースの最終版は2018071321-SXATQFMだ．これをインストールしてみよう．ダメだ！OCXの登録に失敗している．

新版をアンインストールしてもう一度試してみる．いや，そもそも新版はまだインストールされていない．しかし，デスクトップにはZTのアイコンがあり，起動することはできる．リンク先はZelkova-Tree 2021と表示されているだけだ．ZT2021のOCXは登録されていないはずだから，実際にはEXEを直接叩いて開くというのと同じ動作になっているものと思われる．ZT2021を先にインストールしてみよう．⇒勘違いしている．開発機とタブレットの画面を混同している．開発機にはZT2021がインストールされている．

2018071321-SXATQFMのバージョンは2.0.2.088だ．2.0.0より小さいものの方がよい．2.0.0より若い番号というと2012年まで遡らなくてはならない．2013年12月26日～2014年1月2日のおよそ1年間は2.0.0.000という同じ番号を使い続けている．これはこの時期に「正式版」をVersion 2.0.0という切りのよい番号で発行しようとしていたためだ．結局一年かけてもその目標は達成されず，その後は順調に番号をインクリメントしてゆくことになる．1.9番台の最終バージョンは2012042421-YLUFYWLの1.9.9.99でおそらくこの版がもっとも普及している版ではないかと思う．

1.9.9.99は2012年4月24日にリリースされ，そのあとの公式リリースはほぼ完全に途絶えているので，あとからユーザ会に参加したメンバーもずっとこの版を使っていたものと思われる．さて，ともかくこれを開発機にインストールしてみよう．2012042421-YLUFYWLにはいくつか同名ないし類似の異種バージョンがある．しかし，msiインストーラが生成されたのは2012年4月24日で間違いないように思われる．この版はZelkova Beta2というフォルダにインストールされる．しかし，インストールには失敗した．

このエラーはZelkova Beta2は64ビット機にはインストールできないということを示しているものと思われる．今回ターゲットは当面64ビット機に限定しているので対象外ということになるが，バージョンを確定するために32ビット機を起こしてインストール可能であることだけは確認しておこう．⇒32ビット機のSHIRLEYBIRD（tamo2さんが置いていってくれたミニノート，Windows 10）にインストールを試みたが失敗した．この時期はもしかするとXPの時代だったかも知れないが…

Windows 10 32ビット機にインストールできるバージョンというのはあるだろうか？最新版はAny CPUでビルドしているのでもしかするとインストールできる可能性はある．再開発版初版をShirleybirdに送ってみよう．⇒ダメだ．当面は32ビット機はターゲットとしないとしているので，最新版がインストールできないというのはよいとしても，32ビットWindows 10にインストールできる版がないというのもかなりまずいのではないか？64ビットへの移行というのは比較的新しいトレンドなので，既存の公式リリース版の中に32ビットにインストールできる版がないということはあまり考えられない．

lenovoノートは32ビットのWindows 7だった．この時期のリリース版というのはあるはずだ．遅くとも2012年頃にはlenovoを使っている．従って2012年からつい最近まではlenovoで開発していたことになる．Visual Studio 2005を使い始めたのがいつ頃か？正確には特定できないが，かなりの期間はXPとWindows 7がターゲットになっていたはずだ．Windows のバージョンとVSのバージョンの対比も正確なところはよくわからないが，Windows 10にインストールするにはVisual Studio 2012ないし2015ないし2017に移行する必要があったのではないだろうか？2018年12月にはネット復帰し，その時期にDiginnosに乗り換えているが，VS2015を導入したのはそれよりもかなり早いはずだ．

2018/07/13の2.0.2.088はインストールできなかった．2019/01/06でVS2010を試しているので，Windows 10で動作するバージョンというのは2019年より後なのではないだろうか？lenovo のOSをWindows 7から10にグレードアップしている可能性はある．Windows 10 対応は2019年以降と考えてよさそうだが，2019/01/11に「Visual Studio 2017 でビルドして Windows 7 にインストール」という記事がある．

Windows 10のZEKOVA_2020でリリース版を走らせたとき，「タイプ初期化子が例外をスローしました」というエラーが出る．VBのプロパティでコンパイル→ターゲットCPUをAnyCPUからx96x86に変えてやればエラーは解消する．

Windows 7の環境でもこの点は確認されている．Windows 10で生成→Windows 7にインストール，ないしWindows 7で生成→Windows 7にインストールも確認されている．Windows 7搭載機は32ビットCPUと推定される．この記事には「Visual Studio 2015まではXPをサポートしていた」ともある．Windows 7搭載機と呼んでいるのはlenovo G570のことだ．この時期にはまだICU室で延命していたものと思われる．CPUはインテル Core i5 2410Mでビット数は明記されていないが32ビットで間違いない．「Windows 10のZEKOVA_2020」というのは新規導入されたdiginnos（Windows 10 64ビット）のことだ．※

※この点は再確認を要する．現時点では再開発版初版も同じ設定（VBのプロパティ→コンパイル→ターゲットCPU＝x86）になっている．

VSの構成マネージャではVBのプラットフォームはAny CPU固定で変えられないが，ソリューションプラットフォームではWin32を選択できる．これまではつねにAny CPUとしてきたが，Win32というリリースを試してみることにする．⇒デバッグモードでは走ったが，リリースモードではエラーになってしまう．⇒デバッグモードで成功したあと，リリースモードでも走行するようになった．ただし，どちらのモードでもForm1.vbにOCXを貼り込むことはできない．

一応インストール版はできたのでインストールしてみよう．⇒開発機にはインストールできて実行も可能だが，Shirleybirdにはインストールできなかった．エラーコードはHRESULT=2147024770．ネットで検索するとこのエラーは

pgoledb.dllが依存しているMSVCP60.DLLが無い

ということのようで，MSVCP60.DLLをダウンロードし、C:\WINNT\system32にコピーすれば解決するとある．ShirleybirdにはこのDLLは存在する．ただし，サイズはかなり違うので別物だ．32ビット版と64ビット版の違いだろう．最新版をダウンロードしてみよう．⇒system32フォルダにコピーしようとして拒否された．管理者権限のあるアカウントでログインしているのだが…

System32にファイルを保存できる管理者について。

64ビット機でも32ビットDLLは持っている．

On a 64bit version of Windows, the default folder for 32bit DLL-files is C:\Windows\SysWOW64\ , and for 64bit dll-files C:\Windows\System32\ .　

開発機の32ビット版MSVCP60.DLLとShirleybirdが持っているそれとは同じだ．従って，上記「MSVCP60.DLLが無い」には該当しない．

.NETのバージョンはどうか？⇒Shirleyには.Net Framework 4.8がインストールされている．リリースビルドではC++のランタイムをインストールするためのsetup.exeが作られているのでこれを使ってみよう．VBの必須コンポーネントにはVisual C++ “14” Runtime Libraries (x86)が含まれている．ネット情報ではVC++ 2017ではVC++14.1 再頒布可能パッケージが必要とある．⇒現在Windows のupdateを実施中なのでこれが完了してから，もう一度インストールを試しておこう．その後でランタイムのインストールを実行してみる．

hama2234氏から短信．「家系図ソフトは今でも使用可能ですか？」という問い合わせへの回答に対する返信だ．皆さんしびれを切らしてお待ちになっていらっしゃるのだが…ユーザ会メンバー千人のうちおそらく何人かはすでにお亡くなりになっているに違いない（と確信を持って言える）．いまでも有効なメアドはおそらく登録数の一割を切っているのではないだろうか？まぁ，ともかくわたしはまだ残っているのだから残っている時間のうちにできるだけのことをやらなくてはならない…

Visual Studio ではターゲットプラットフォームとしてソリューションプラットフォームとプロジェクトプラットフォームを区別している．ソリューションはプログラム全体，プロジェクトはそれを構成するコンポーネントを意味するが，プラットフォームはそこで使われるCPUの命令セット（の汎用レジスタビット長）を示している．（ソリューションは64ビットでも一部のコンポーネントは32ビットということがあり得る）．

現在使われているCPUのビット長は64ビットか32ビットだ．この仕事を始めたころは（メインフレームを除けば）8ビット長というのしかなくて，16ビットパソコンが出てくるのをまだ一度も会ったことのない花嫁のように憧れたものだ．VSでは64ビットをx64，32ビットをx86と表記している．x86というのはCPUの種別で昔8086（8ビット）ないし80286（16ビット）など86系と呼ばれるCPUがあったことの名残りではないかと思われる．別の言い方では64ビットをAny CPU，32ビットをWIN32と表記することもある．

これは主にソリューションプラットフォームや構成マネージャで使われる呼称だ．Any CPUの意味は時と場合によって変化しているようで，昔はAny CPUでビルドしたパッケージが32ビットで走っていたのにいまはそれが通用しないように変わっているような気がする．マイクロソフトのデベロッパ用製品ではパラメータの「設定」と実際の「動作」に齟齬があるというのは普通であるようだ．普通であるだけでなく，それが時間とともに（勝手に）変化してしまうのでそれに付いてゆくのは至難の業と言わなくてはならない．

さて，WIN32でビルドしたパッケージが64ビット機で動作することは確認しているが，ひとつ問題が起きているのでそれを見ておくことにしよう．ZelkovaZ.idlでuuidと一緒にバージョンを設定しているところがある．これもビルド時に更新する必要がある．現在値は3.0だが，アプリと同じ2.2としてみよう．どこかに3.0のオブジェクトが残っているようで，参照の追加で項目がダブってしまう．また，リビルドしてVBからOCXへの参照が解決できない．⇒奥の手の「Form1にOCXを貼り込む」で解消した．「ひとつ問題が起きている」というのはそのことなので，一応これは事実上解消したということになるのだが，uuid（Universally Unique Identifier, マイクロソフトではGUIDと呼ぶ）が同じというのはやはり問題があるのではないだろうか？

ネット上にはuuid生成ツールがあるので書き換えてみよう．Zでは4個のuuidを使っている．その他にGUIDとして定義されているものもある．

1. uuid　3B5BE240　ZelkovaZ.idl　ゼルコバの木系図エンジン for WIN32
2. uuid　F3C38B89　ZelkovaZ.idl　ディスパッチインターフェイス
3. uuid　CAB2182C　ZelkovaZ.idl　イベントインターフェイス
4. uuid　4E61AC51　ZelkovaZ.idl　Zelkova Tree 2016 コントロール
5. GUID　601c9479　ZelkovaDLL.cpp　BASED_CODE _tlid　V=2.1
6. GUID　4E61AC51　ZelkovaCtrl.cpp　IMPLEMENT_OLECREATE_EX　ZELKOVAZ.ZelkovaCtrl3.1　クラスファクトリ
7. GUID　F3C38B89　ZelkovaCtrl.cpp　IID_DZelkovaZ3　インターフェイス ID
8. GUID　CAB2182C　ZelkovaCtrl.cpp　IID_DZelkovaZ3Events　インターフェイス ID
9. GUID　3B5BE240　ZelkovaZ.cpp　BASED_CODE _tlid　アプリケーション　V=2.0

_wVerMajorと_wVerMinorでDLLとOCXのバージョンを設定している．これらの値はタイプライブラリに保存されているものと思われる．uuidと_wVerMajor，_wVerMinorが一致するものを同一オブジェクトと認定しているのだろう．修正箇所には「2012-10-16 再開発版」を入れておく．⇒いや，単にコメントを挿入するのではなく，コンパイルオプションとして切り分けられるようにしておいた方がよいと思う．

ShirleyのWindows Updateは完了し再起動したが，1本だけ更新に失敗している．悪意のあるソフトウェアの削除プログラムでもしかするとカスペルスキーが妨害している可能性も考えられる．Windowsのバージョンを1909に上げるという更新が出てきたので，実行しておこう．

コンパイルオプションは「再開発版20201016」とし，ZとDLLのそれぞれのstdafx.hで定義する．IDLファイルを修正していてVisual Studioがクラッシュしてしまった．IDLファイルでは日本語リテラルを使えないのだろうか？「再開発版20201016」を止めて「ZELKOVA2021RESTART」を使うことにした．

Shirleyを再起動して更新はすべて完了．上記のエラーも解消している．ここでもう一度WIN32版のインストールを試みたが，同じエラーになった．エラーを無視して完了することはできるが，アプリを起動しても立ち上がって来ない．このマシンにはゼルコバの木ベータ２がインストールしてあったので走らせてみたところ，下記のエラーになった．

GCのロードに失敗しているようだ．このアプリは記憶には残っていないが※，存在しているところを見ると一度は実行に成功しているのではないだろうか？32ビット版を32ビット環境でビルドするということは考えられるが，その前にVS2017には64ビット版と32ビット版があったはずなので，それを試してみるということも考えられる．C++ランタイムをインストールするためのsetup.exeを実行してみたところ，エラーが発生した．ログを見ると下記のような障害が起きている．

※1.9.9.99のインストールを試みたとき生成されたものと思われる．

(2020/10/16 19:19:01) u’vcredist_x86\vc_redist.x86.exe’ from ‘https://aka.ms/vs/16/release/14.25.28508/VC_Redist.x86.exe’ to ‘C:\Users\Zelkova\AppData\Local\Temp\VSD5A51.tmp\’

どうもこのリンクはリンク切れになっているようだ．いや，存在する．こちら（ネットアクセス用のサブマシン）ではダウンロードできた．⇒Shirleyはネットに接続していなかった．⇒ネットに接続してsetup.exeを再実行してみたが，以下のエラーになった．

OKでダウンロードを再実行しても効果はない．何がまずいのかよくわからないが，C++のランタイムはマイクロソフトから単体でもダウンロードできるはずなので，まずそれを試してみるということにしておこう．※後述で試している．　ZELKOVA2021RESTARTを立てて（uuid更新バージョン）ビルドするとビルド中に以下のエラーになる．

もう一度ビルドするとエラーは解消したが，実行時に以下で停止した．

考えられるのはネットで生成したuuidがマイクロソフトのGUIDの要件に合致していないということくらいだが…ネットのuuidはバージョン4の乱数で生成されている．ctlreg.cppで起きているエラーはやはりGUIDに関係したものだ．

How can I give an old ActiveX control new GUIDs?
GUIDs pop up everywhere in software!

VSはbuilt in GUID generatorを持っている！多分これを使えば間違いないだろう．ShirleyでVC++ 2017の再頒布可能パッケージをダウンロードしてインストールしたが，WIN32版のインストールには失敗した．今度は少し違うエラーコードが出ている．

ようやくスムースにインストールできるようになった．マイクロソフトは一時廃止したセットアッププロジェクトを復活させているが，アップデートのルールが変わってしまっている．以前はRemovePreviousVersionがTRUEなら上書きインストールを黙って実行していたものが，パッケージに含まれる個別コンポーネントのファイルバージョンをチェックして新しいものでなければインストールしないという動作になっていた．バカげた仕様だと思うが従うしかない．ともかくこれでインストール上の問題は基本的に解決したのではないかと思われる．開発機はWindows 10 Version 1909の64ビット機なので現在使われているもっとも標準的構成と考えてよいと思う．

タブレットの「Windows Updateのクリーンアップができない」という問題でコマンドプロンプトから管理者権限で「Windows Updateコンポーネントをリセットする」ための一連のコマンドを実行するということをやっているが効果はなかった．あとはOSを再インストールするしかないのだが，その前に一応「後始末」を付けておこう．以下を実施する必要がある．

rmdir c:\windows\softwaredistribution.old /q /s
rmdir c:\windows\System32\catroot2.old /q /s

インストーラ生成手順については落ち着いてからもう一度考察することにする．先に進む前に面倒だがタブレットのOSの再インストールを片付けてしまうことにする．多分ユーザ領域を温存した再インストールができるはずだが，一番面倒なのはそのあと使っているアプリをすべて再インストールする必要があるという点だ．このマシンにインストールされているアプリをチェックしておこう．⇒このマシンには最小限のものしかインストールされていない．

1. BlueGriffon version 3.1
2. Google Chrome
3. Google 日本語入力
4. Java 8 Update 261
5. Lhaplus
6. Mery (x64) 2.6.7
7. Microsoft Garage Mouse without Borders
8. Mozilla Maintenance Service
9. Mozilla Thunderbird 8.3.2 (x86 ja)
10. Realtek SDIO Wireless LAN Driver
11. Windows Essentials 2012
12. カスペルスキーインターネットセキュリティ
13. カスペルスキーセキュアコネクション

この他にマイクロソフト関係が3，インテルが2あるが多分プレインストールと思われるので自動的に補充されるはずだ．Windows Essentials 2012はOpen LIve Writerのことではないかと思う．Open LIve Writerのフォルダの設置場所はE:\My Weblog Posts．Optionsから設定できる．Thunderbirdの設定をエクスポートする方法が見つからない．⇒以下のデータをまるごとコピーして元に戻すというだけだ．

C\Users\＜ユーザー名＞\AppData\Roaming\Thunderbird\profiles\＜英数字＞.default

データ本体は別のところに置いてあるが，多分アカウント情報はここにあると思われるので大丈夫だと思う．最悪アカウントを再設定したとしてもデータは外部にあるのでリンクするのは難しくない．拡張機能でアドオンを使うという手もある．⇒ImportExportTools NG はあったが無効になっている．Thunderbird 78.3.2と互換性がないという理由だ．⇒製品レビューには「Works great with Thunderbird 78.3.2.」のような書き込みもあるのだが…自動更新になっていて2020-03-19に更新されたことになっている．インストールされているのは4.0.4だが，ネット上にはもっと新しいバージョン10.0.1がある．

https://addons.thunderbird.net/en-US/thunderbird/addon/importexporttools-ng/

インストールできた．使えそうだ．いろいろなフォーマットが扱えるようになっているが，アカウント設定のエキスポート/インポートはできないような？一番簡単なのはヘルプ→トラブルシューティング情報→プロファイルフォルダーでデフォルトフォルダを開き，その内容をバックアップしてリストアでよいのではないか？ImportExportTools NGにはプロファイルのエクスポート/インポートがあるので多分それと同等のことができるのではないかと思う．⇒両方やっておくことにする．プロファイルのエクスポートはかなり時間が掛かりそうだ．⇒終わった．

さて，いよいよOSの再インストールに掛かるとしよう．設定→回復→このPCを初期状態に戻すを試してみる．「個人情報を保持する」を選択し，「このPCに最初から付属しているアプリと設定を復元」で初期化を実行する．⇒ディスク領域が足りませんになってしまった．多分以前試みたときもここで挫折していたものと思われる．1.56GB不足している．現状でCドライブの空き領域は2.48GBだ．⇒アプリをアンインストールしておこう．Thunderbirdはやはり結構大きかったようだ．

次のアプリ（上記以外）はWebまたはインストールディスクから再インストールする必要があると出た．

1. Intel Processor Graphics
2. Microsoft SQL Server 2005 Compact Edition [ENU]
3. Microsoft Update Health Tools
4. Update for Windows 10 for x64-based Systems (KB4480730)

OSの再インストール（設定→更新とセキュリティ→回復→このPCを初期状態に戻す）は難なく終わり，アプリの再インストールも順調に進んですでに午前中にあとはThunderbirdだけというところまで進んでいたのだが…その先で地獄を見ることになった．

2019-02-06版という１年半前のバージョンに戻ることに決定した．これが我々のスタート台となる切り株だ．この夏の連日の炎暑で唐沢川の土堤の桜が軒並み枯れかけている．この桜は40年前（わたしが東京で暮らしているころ）に若かりしころの友人Oが青年会議所理事長の職にある時期全滅しかけていた桜並木を復活させたものだ．いまは，歴代がそれを引き継いでいるので多分大丈夫だろうとは思うが…さて，我々もこの倒壊したゼルコバの木に残った切り株からもう一度再スタートすることにしよう．事実上これが最後の挑戦になることだけは間違いがない．

この版ではまだ「基準ノード配偶者近接配置」の修正が収束していないものと思われるが，これは一時置いて，「安定版」の確立に当面は注力することにする．目標は11月8日（立皇嗣の礼挙行）までに公式リリースすることとしておこう．「安定版」とは，標準的かつ包括的なテストをすべてクリアしたものと定義される．しばらく遠ざかっていたので「標準的な包括テスト」で何をやっていたのかも忘れてしまっているが，主なテストはヘルプメニューに入っているのですぐにでも掛かれるだろう．この版では最小限，最新版のWindows 10搭載64ビット機で動作することが求められる．開発機はこの条件を満たしているだろうか？Windows UpdateすればOSは最新版になるはずだが，開発機はネットには常時接続していない．チェックしてみよう．開発機のOSは

Windows 10 Home バージョン： 1909　インストール：2020/02/11　ビルド：18363.1082

だ．タブレットは

Windows 10 Home バージョン： 1903　インストール：2020/03/17　ビルド：18362.900

でインストール日は遅いのにバージョンは古くなっている．現在 Windows 10 の最新バージョンは2004になっている．標準テストはやはり開発機でやるしかないので一度ネットにつないでアップデートするしかないだろう．Bluetoothテザリングなら複数機に接続できる．2004のアップデートは始まっているようだが順番があるようだ．手動で実行することもできるようだが，そこまでやるまでのことではないように思われるので（むしろ1909のユーザの方が多いのでは）自動でアップデートされるまで待つことにする．

アップデート時の不具合に備えてFileRepository（ドライバーのバックアップ）をコピーした．回復ドライブも作っておこう．⇒Windows Updateが進行中なのでシステムのバックアップはできない．どうも相当な時間が掛かりそうだ．システムイメージのバックアップ機能はWindows 10では非推奨になっている．Windows 10ではファイル履歴でバックアップという方法が導入されている．これはサイトのバックアップのように定時にバックアップするという方法だが，果たして必要だろうか？⇒回復ドライブだけ作っておくことにする．回復ドライブはコントロールパネル→回復でアクセスできる．16GB以上必要と出ているが，16GBのUSBを試してみる．これもまた相当な時間が掛かりそうだ．

ディスク領域が逼迫している．「Windows Updateのクリーンアップができない」という問題があり，削除できない不要なファイルが4.5GBくらいある．OSを再インストールすれば解決するという話だが，それもかなり厄介だ．参考になる記事があったので試してみる．

https://answers.microsoft.com/ja-jp/windows/forum/all/windows/5a67137b-5ee4-4cb0-8392-483de6d83174

再開発版のリリース版を起こしてみよう．バージョン番号は2.2.0.000とした．製品名＝Zelkova-Tree 2021，主題＝系図作成ソフトゼルコバの木2021，タイトル＝ゼルコバの木正式版 Ver 2.2.0.000とする．製造者URLもAYANETからhttps://zelkova-tree.net/WordPress/ に変えた．⇒DLLでエラーが出た．

error D8016: コマンド ライン オプション ‘/ZI’ と ‘/GL’ は同時に指定できません

/GLはプログラム全体の最適化，/ZIはデバッグ情報の形式エディットコンティニュのプログラムデータベースという意味のようだ．リリース版ではデバッグ情報はほとんど不要と思われるが，プログラムデータベース（Zi）としてみよう．⇒通った．GCで警告が出ている．

warning MSB3284: タイプ ライブラリ “f10efde4-db94-11d2-b863-289605c10026” バージョン 1.0 のファイル パスを取得できません。ライブラリは登録されていません。 (HRESULT からの例外:0x8002801D (TYPE_E_LIBNOTREGISTERED))

バージョン番号を振り間違えていた．

ERROR: Invalid product version ‘2.2.0.000’. Must be of format ‘##.##.####’

2.2.0000としなくてはならないということだろう．msiファイル名がZelkovaTreeSetup.2.1.0.016.msiのままになっている．これはどこで決めていたのだろう？⇒VBのプロパティ→発行→発行するバージョンではないか？⇒いや，ここを変えても変化しない．セットアッププロジェクトのプロパティ→Output file nameという場所がある．⇒インストーラがビルドできた．リリース版を走らせてみる．⇒まだスプラッシュパネルが出ている間にエラーで停止した．

OKを押しても連続して出てくる．サンプルはタモリさんちの超複雑な家系.ZEL．TRIBEBOX::GetMajorTribeChainで出している模様だが，呼び出し履歴では確認できない．これはおそらくデバッグ用のチェックボックスではないかと思われる．checktribesenzoというデバッグ専用関数が呼び出されている．確かにそういう作りにはなっているが，非デバッグ時に呼び出されるとStop文で停止するようになっている．STOPマクロは非デバッグでも定義されているが，funcnameなどが未定義となるためコンパイル時エラーになる．⇒Stop文を廃止，ダンプ文に変えた．check = c，ないしcheck = 1が残留している．⇒一掃した．

回復ドライブの作成が完了した．14.4GBしか使っていないのでまだ5.5GB余っている．V2.2.0.000_R20201014というパッケージを作ってバージョンを確保した．プログラムはデフォルトでは製品名として登録したZelkova-Tree 2021というフォルダに保存される．

C:\Program Files (x86)\babalabo\Zelkova-Tree 2021\

おかしい．またSTOPボックスが出てしまった．ビルドしていなかったのだろうか？開発環境ではすでにボックスは出ない動作になっている．ビルドし直して再インストールしているのに動作が変わらない．かなりおかしい．アプリ登録されているのは一つだけだ．アンインストールして再インストールしてみる．⇒これで動作するようになったが，かなりまずい現象だ．インストーラのファイル名を変更していなかったのが敗因なのだろうか？VBのバージョン番号はおそらく無関係と思われるが…

ヘルプ→バージョン情報の内容も変化していない．⇒更新した．リビルドして再インストールしたが内容は同じままだ．つまり，プログラム自体の差し替えが実行されていない．Program Files(x86)を見ると12:50に生成したものが入っている．もう一度リビルドしてみよう．⇒ダメだ！アンインストールすれば入るのは確実とは思われるが，それでは持たない（クレームが殺到する）．Program Filesの中身が変わっていないのだから動作するはずがない．UpgradeCodeも変えてみたのだが…RemovePreviousVersionはTRUEになっている．

EXEの名前もZelkovaTree2021.exeに変えなくてはならない．⇒VBのプロパティ→アプリケーションでアセンブリ名を変える必要がある．アセンブリ名をZelkovaTree2021と変えることでEXEの名前は変わり，ZelkovaTree2021.exeもProgram Filesに入るようになったが，元のZelkovaTree2019.exeも残っている．立ち上がって来るのは（おそらく）2019の方だ．ヘルプのバージョン情報もおかしい．バージョン番号とリリース日付だけ古い値のままになっている．

▲軟体動物2.zelのタイトルが軟体動物２.ZEL《頭足類家系図》となっているが，おかしい．

アプリが3つに増殖している．デスクトップ上にはアイコンは一つしか出ていない．すべてアンインストールして再インストールしてみた．今度初めてライセンスキーの登録画面が出てきた．

しかし，スプラッシュパネルの内容は古いままだ．

ライセンスキーは生成されているが，パネルに表示されているコードと一致していない．いや，これはそれでよいのかもしれない．ライセンスキーが生成されるのはデバッグモードのときだけだからだ．今度はバージョン情報も更新されているようだ．気になるのは画面が下の方で切れてしまっているという点だが…

スプラッシュのタイトルはMyForm.Info_Titleというところから引いている．MDIParent.vbで一括して定義しているところがある．ここを修正する必要がある．

▲ライセンスキーファイルがデスクトップ上にあると上書きされない．

リリース版をビルドしてバージョン番号を上げるときに必要な編集操作のリストを作っておこう．

1. プロパティ画面でセットアッププロジェクト→Version をインクリメントしてProductCodeを更新する　Titleのバージョン番号も更新しておく
2. セットアッププロジェクト→プロパティ→Output file nameのmsiファイル名を更新する
3. ライセンスヘッダファイルで※ライセンス番号※とバージョン文字列を更新する
4. ※アプリをデバッグモードで起動し，ライセンスコードとライセンスキーを取得してヘッダファイルに書き込む※
5. MDIParent.vbファイルでInfo_Releaseと※Info_LicenceCode※を更新する⇒これは多分不要
6. Z.OCXとDLLのリソースでVersionを更新する
7. VBのプロパティ→アプリケーション→アセンブリ情報の中身（ファイルバージョン）を更新する
8. リリース版をビルドする
9. ※は所内版の場合は不要

▲Info_ReleaseとInfo_LicenceCodeはDLLから取得できるのではないか？それ以外の情報もDLLから取得している可能性がある．

どうも現状ではアンインストールする以外にインストールを実施する方法がないように思える．Visual Studio 2005辺りからmsi形式のインストーラを生成するセットアッププロジェクト機能が廃止されている．その代わりにVisual Studio Installer Projectsというのが導入された．⇒いや，どうもこれは単純に「復活した」だけなのではないかという気がする．アイコンも同じ，内部の構成も同じだ．ネット上にこんな質問があった．この記事は参考になる．

RemovePreviousVersions=True but previous version is not removed from the target machine　https://social.msdn.microsoft.com/Forums/ja-JP/9ce5da29-3f37-4e7f-a548-1cbeb4a3e0a3/removepreviousversionstrue-but-previous-version-is-not-removed-from-the-target-machine?forum=winformssetup

どうもVBのプロパティ→アプリケーション→アセンブリ情報の中身を更新する必要があったように思われる．この情報はEXEの右クリックで出るプロパティの内容と同じだ．⇒この情報を更新して少なくともProgram Files のEXEのプロパティは更新されているように思われる．ただし，ヘルプのライセンスコード・バージョン・リリース日付などは古いままだ．確かにEXEは18:23に生成されているが，それ以外のDLL，OCXの時間は1～5時間も前だ．EXEとGC3.DLLは開発環境と一致しているが，それ以外は更新されていない．GC3.DLLはファイルバージョンを持っていない．Z.OCXは2.1.0.1というバージョン番号を持っている．DLL3.DLLのファイルバージョンは1.9.9.99で製品バージョンは2.0.1.925だ．どこからこんな数字を拾ってきているのか？

ネット情報によると，セットアッププロジェクトのVersionではなく「ファイルバージョン」が新しい必要があるということのようなので，どこでこれらの値を設定しているかを突き止めなくてはならない．⇒それぞれのリソースの中にVersionという項目がある．⇒対処した．これで4主要コンポーネントはすべてアップデートできるようになった．この他にInterop.ZelkovaZ3Lib.dll，AxInterop.ZelkovaZ3Lib.dll，ZelkovaTree2021.exe.configがあるが，これらはインターフェースが変化しない限り変動はないと思われるのでとりあえずこれでよいということにしておく．configにはバージョン番号はないが，他の２つには3.0.0.0という番号が振られている．

パッケージの中に複数のコンポーネントが入っているときに個別のバージョン番号を見て新しくなければインストールしないという（VS2005以来の）現在の仕掛けはわたしには理解できない．仮に異同がなかったとしても単純に上書きすればよいというだけの話ではないのだろうか？誰がこんなつまらないことを考えたのか？面も見たくはないが…ネットに情報があったからよいが，もしそれを聞いていなかったら，まだまだ手間取って，こんな小石にさえつまづいていたかもしれない…

現在「再開発スタート版候補」として以下の4種が上がっている．

1. ZELKOVA2019_2019-03-10★2.1.017　ほぼ最終版
2. ZELKOVA2019_2019-08-09★2.1.020　最良版候補
3. ZELKOVA2018_2019-08-14★2.0.2229　VS2017移行仕掛り版
4. ZELKOVA_2020-10-12★2.1.012　現行仕掛り版

いずれもVS2017で開けることは確認してあるので，それぞれをビルドしてパフォーマンスを比較してみることにする．以下ではこれらをそれぞれ①ほぼ最終版，②最良版候補 ，③移行仕掛り版，④現行仕掛り版と呼ぶことにする．まず，①から試してみることにしよう．これはビルド日付が去年のわたしの誕生日に当たっているので幸先がよい．

ビルドできた．タモリんちは正規形で表示できている．⇒残念！バグが出ている．天皇家で「多重カード」が発生してしまった．かなり致命的というより最低だ．これは一応残して別の候補を見ることにしよう．②の最良版候補はどうだろう？⇒リリース版を作ってしまった．⇒天皇家は問題なく開けた．天智天皇から上が上方にY字に拡がっているというパターンだ．タモリんちも正規形で開ける．

もう少しテスト用サンプルを探さなくてはならない．テストキットのようなものがどこかに保存されていなくてはならないのだが…このサンプルキットそれ自体かなり貴重なものなのでどこかになくてはならないのだが，ちょっと見たところ見当たらない．デスクトップ 2020-02-11というフォルダがあった．多分これはこの時期デスクトップ上にあったサンプルを網羅していると思う．サンプルファイルだけで112,428本．まずい！この版（最良版候補）にも重大な欠陥がある．Ancestryがシンメトリックに描画できない！これはかなり由々しき事態だ．

軸線図ならこのような図式になる可能性もあるが，設定はデフォルトの軸線なしだ．これを「最良版」とみなすことはできない…③移行仕掛り版を見てみよう．⇒「”ADODB” のラッパー アセンブリが見つかりません。」が出た．プロジェクト→参照の追加でMADO 2.5 Libraryから6.1 Libraryに切り替えてエラーは解消した．いや，このエラーは通ったが別のエラーが噴き出してきた．エラーの一つのタイプは

error BC40000: ‘Public Function FontChangeSize(CurrentFont As Font, Size As Single) As Font’ は廃止されています: ‘Microsoft.VisualBasic.Compatibility.* classes are obsolete and supported within 32 bit processes only. http://go.microsoft.com/fwlink/?

というもので，もうひとつは

error BC30311: 型 ‘CheckBox()’ の値を ‘ISupportInitialize’ に変換できません。

というタイプのものだ．

error BC30451: ‘address_Leave’ は宣言されていません。アクセスできない保護レベルになっています。

というタイプのエラーもある．もう一つのタイプは

error BC30456: ‘Item’ は ‘TextBox()’ のメンバーではありません。

というものだ．ビルドのターゲットはAny CPUになっていたが，これをWIN32ないしx86に切り替えても同じだ．おそらくこの版では64ビット版への移行を狙っていたのではないかという気もするが，このシステムはアンマネージドなネイティブコードがベースになっているので64ビットにストレートに移行することは少なくとも現時点では現実的ではない．「オブジェクト配列の廃止」という修正がまだ収束していないということも考えられるが，それだけでもなさそうだ．他のパッケージと比較してここまで動作が変わるという理由がよくわからない．とりあえず，この版は再開発のコースからは一時的にであれ外すしかない．

現行仕掛り版の動作はすでに見ているが，一応再確認しておこう．⇒この版では天皇家も問題なく開ける．ややのけぞったような形態にはなっているが，本質的な問題ではない．タモリんちでバランスが崩れるというのが最大の問題だ．ここまでを整理すると：

1. 2019-03-10★2.1.017　ほぼ最終版　天皇家で多重カード
2. 2019-08-09★2.1.020　最良版候補　Ancestry.ZELが非対称
3. 2019-08-14★2.0.2229　移行仕掛り版　ビルド不能
4. 2020-10-12★2.1.012　現行仕掛り版　タモリんちでバランス不良

③の移行仕掛り版を弾くとすると残り3つになるが，多重カードが発生するというのはかなり致命的なので外すしかないのではないだろうか？残り2つはいずれもバランスの悪い図を描画するという欠陥があるが，どちらの問題も解決策がないという訳ではないので，どちらがより容易に対処可能か？ということになりそうだ．どちらかというとAncestryの非対称の方が扱い難いような気がするので，現行仕掛り版から始めるということになりそうだが，この版の出自をもう一度確認しておこう．もしかすると，この辺りの問題まで解決した版が出てくるかもしれない．

この版のベースはZELKOVA2019_2020-10-11という名前でバックアップしている．SetupのVersionで見ると2.1.010とあるので，3候補の中では一番古いものということになる．DLLのソースコードは2019/01/11修正が最終だ．バージョン番号から見ると，現行仕掛り版（1月11日）→ほぼ最終版（3月10日）→最良版候補（8月10日）ということになる．

ただし，ほぼ最終版と最良版候補はどこかで分岐しているようで，最良版候補は必ずしもほぼ最終版の継承にはなっていない．最良版候補には2019/02/06の修正が入っているのである意味でこれは「基準配偶者配置問題」の修正に入る前の版と考えられる．ほぼ最終版はある意味で間違った方向に進んでしまったと考えられるのでこの意味では

現行仕掛り版（1月11日）→最良版候補（2月6日，8月10日）

ということになるから，むしろ最良版の方がベターなのではないだろうか？最良版候補のベース版を見つけることができるだろうか？ZELKOVA2019_2019-02-10というのがある．その他にも2月26日～3月10日までの間には6個のパッケージが残っている．とりあえず，まず2019-02-10を試してみたい．このあと，2月26日まではかなり長い空白期間になっているのだが…ZELKOVA2019_2019-02-10を起こしてみたが，起動時にエラーが発生した．何が悪いのかよくわからない．⇒リビルドして解消した．この版でもAncestry非対称が起きている．

ZELKOVA2019_2019-02-26を見てみよう．⇒ほぼ同じだ．天皇家の多重は起きていないがAncestry非対称になる．このあと，3月10日のほぼ最終版までの間で天皇家多重が起きるようになるのだろう．次が2月27日でその次の3月5日まで若干の空白がある．ZELKOVA2019_2019-03-05を調べてみよう．⇒動作的にはまったく同じだ．あと残っているパッケージは3つしかない．一つづつ調べてみる．まず，真ん中のZELKOVA2019_2019-03-07から行ってみよう．

この版では天皇家で非連結になる．天皇家はほぼ一系列なので非連結になるというのはほとんど考えられないのだが…タモリんちは逆に完璧な理想形になっている．Ancestryはかなりひどい毀損状態になる．

ZELKOVA2019_2019-03-06も見ておくことにしよう．⇒状況は同じ．結局2019-03-05が屈折点になっているということになる．選択肢としては現行仕掛り版（1月11日）を取るか，ないし最良版候補（2月6日）～3月5日の間を取るということになりそうだ．あるいは，1月11日～2月6日の期間も対象になるのではないか？最良版候補に入っている8月10日の修正というのも気になるところだ．しかし，この日の修正をログから特定するのはかなり難しそうだ．むしろソースコードを比較してしまった方が早いかもしれない．1月11日～2月6日の期間はほぼ1日置きにパッケージが残っている．2019年2月のログを少し読み直してみよう．

2月は17日から仕事を開始しているが，かなりブランクを空けて26日までは大したことはやっていない．3月にはThunderBIrdの導入とサイトメンテナンスに焦点が移ってしまっている．「基準ノード配偶者近接配置」の件は片付いているのだろうか？言及がないところを見ると一応落着したと認定していたのではないだろうか？自分自身は仕掛りという意識でいたのだが…いずれにしてもここをすくい上げることができればほぼ最終版に近いものになると考えられるのでできる限り追求してみたい．バックアップを見ると仕事をしていなかった訳ではなさそうなので，ログで言及されていないということはほぼルーチン的な作業になっていたためではないだろうか？3月5日を過ぎると天皇家で不具合が発生し始めるのでやる気を喪失していたのかもしれない…

2月最後の記事は27日の「基準ノードの配偶者で多重が起きる問題」だが，そこで途絶した状態になっているのでおそらく解決しなかったと考えた方がよいのではないかと思う．2月はほとんど遊んでいたに等しいので，やはりこの修正は一旦戻した方がよいのではないだろうか？2月10日に「基準ノードの配偶者が枠外に出てしまう問題」に取り掛かっている．ある程度までは動作していたはずだが，SUWが出るのを抑えきれなかったというのが真相だろう．この修正をそのまま残してデバッグから入るか？それとももう一度一からやり直すのか？それが問題だ．可能な限り直近のバージョンを取るとすれば，3月5日のバックアップということになる．修正廃棄という方針なら2月6日（最良版候補）になるだろう．2019年1月の状況もチェックしておこう．タイトルを列挙すると：

1. 2019/01/30　トライアングル関係BTWの導入で配偶者多重問題を解決する
2. 2019/01/29　開発三種の神器の一つ「草薙のデバッグブレーク文」が復活した
3. 2019/01/28　妻を奪われた残念な男がせめて家系図上で妻を取り戻すには
4. 2019/01/27　「家内婚は左手本人の預かり」という仕様変更が収束しない
5. 2019/01/25　「家内婚は左手本人預かりとする」という仕様変更
6. 2019/01/24　INT 3→NOPの現象が一時止まったがまた元の状態に
7. 2019/01/22　int 3 のブレークポイントがNOPに書き換えられてしまう
8. 2019/01/21　15点という小さいサンプルで障害が発生している

のような感じでそれほどトリビアルとは言えない問題に対処しているので温存するのが妥当だろう．これを見ると1月28日頃からすでに「配偶者近接問題」に関わっていたことがわかる．この修正を撤回するということもあり得ないのでむしろ中断したところからデバッグするという方が現実的なのではないだろうか？とすると，再開発開始版は2019年3月5日版ということになるはずだ．もう一度この版をチェックしてみよう．3月6日版を起こしてしまった．この版ではAncestryが完全に壊れてしまう．いや，おかしい．3月5日版でもシンメトリが崩れている．

いや，この辺りでは常態としてAncestry非対称が起きている．むしろ，天皇家で垂線がぶつぶつに切れるというのが目立つ．もう少しましな版はなかったろうか？最良版候補（2月6日，8月10日）をもう一度見てみよう．2月6日なら配偶者近接の修正も導入されているのではないか？⇒同じだ．どうせ同じなら日付が近いものの方がよいのではないだろうか？2月6日版のオリジナルを見てみよう．手元の2月10日版を見ることにする．⇒ダメだ．この版では例外が発生する．2月26日版でも状況はほぼ同じ．つまり，Ancestry非対称，天皇家で垂線切れだ．⇒例外の発生はエラーではなくカスペルスキーが実行をブロックしたためと思われる．天皇家で垂線が切れるという事象は現行仕掛り版（1月11日）でも見られるので相当前から発生していたものと見られる．これは独自にデバッグする必要があり，版の選定では無視してよい．

となると，最後の決め手は天皇家でY字型の空白部ができることを許容するか否かという問題に絞り込まれるように思われる．現行仕掛り版ではかなりコンパクトというか，おそらくこれ以上は無理と思われる程度にコンパクトになっているが，1月～2月のどこかで拡がるようになってしまったのではないかと思われる．現行仕掛り版のコンパクトな配置はTYWの作用によるものと思われるので，どこかでその効果を減殺するような論理が組み込まれたのではないかと思う．どこでこの差異が発生するようになったかは突き止めておきたい．

修正が入ったとすれば1月11日から2月10日までの期間と推定される．まず，ZELKOVA2019_2019-01-20から見てみよう．この版ではAncestryは対称，天皇家はまだコンパクトだ．1/30を見てみよう．この版ではAncestryは対称，タモリんちもバランスよく，天皇家もコンパクトという非の打ちどころのない仕上がりになっている．2/4を見てみよう．2/4版では天皇家で「先行系列との接続関係確立に再び失敗」という障害が発生する．このエラーは他のサンプルでも起きる．描画は可能なのでこの時点で初めて設置されたトラップである可能性もある．2/6には問題は起きていない．2/7でAncestryのシンメトリが崩れる．同時に天皇家でも上が開くようになる．これはおそらく同一の機序によるものと考えてよいだろう．2/6と2/7の間に2つパッケージがあるが，いずれも同じ．

結局，2/6というパッケージは2019/02/06の始業時バックアップなのでその後の修正で不具合が紛れ込んだという結論になる．これは何を目的とした修正だったのか？

この日の修正は「冷泉院の切り替え」という問題だが，その内容がよくわからない．2/5のログなく，2/4は「系列優先実ノードが隠蔽リスト上にあるという問題」というタイトルになっている．「冷泉院」の名前は出てこないが，関連した問題である可能性はある．いや，多分関わりはないと思われる．この日の対象サンプルはN一族で「N一族家系図に取り組み初めてすでに3ヶ月経過したが，途中に大きなブランクが生じたためまだ収束にはほど遠い状況で足踏みしている．」という書き込みがある．その後に同じ日付でもう1本ある．こちらが本当の2/4だろう．

課題はやはり，「隠蔽された系列優先実ノードが出現する」という問題だ．系列が優先ノードのBTWで結合されているときには，どちらかのノードは消去されていなくてはならない．このとき，「[系列枠]: #806 優先=桐壷の更衣(0)の優先ノードは桐壷の更衣．桐壷院が基準ノード承香殿女御（朱雀院の）の配偶者であるため，桐壷院＋桐壷の更衣の結婚は桐壷の更衣の系列で展開されている．このため桐壷の更衣の仮ノードは1個しか存在しないので系列優先ノードを桐壷院に切り替える必要がある．エラーを無視して描画した場合には冷泉院に切り替わっているが，実仮ノードで世代差が発生している．」というストーリーなのだが…

対策としては「RIBEBOX::decidePrimaryNodeで優先仮ノードを決定する時点で優先実ノードの存在を確認するようにした．このためにGetRealnode(NAMEBOX*)という関数を新設した．優先実仮ノードの対が得られないときはGetAlternativePrimeNodeが実行され，優先仮ノードの切り替えを実施する．これで桐壷の更衣から桐壷院に切り替えることができたが最終的には冷泉院に切り替わる．」としている．図面を見てもよく飲み込めないが，ともかくそのような問題があったとされる．

2/6にはまず，NODULE::IsAliveという関数が間違っているとして修正し，さらに多分PairBoxGeneChangeを修正してエラーが解消したとしている．ここでリリース版を起こしているのでその存在を確認してみよう．少なくとも公式版ないし安定版としては存在していない．2/6-1が2.1.0.016で2/6-2が2.1.0.017に変わっているのでこの間でリリース版を起こしていると考えられるが，不具合はすでに2/6-1で発生している．

2/6のログには『「基準ノードの配偶者は基準ノードに近接配置」という原則が崩れている』という記述があり，2/4には「N一族家系図に取り組み初めてすでに3ヶ月経過」ともあるので，2018年の末頃にはすでにこのテーマに取り組み始めていたものと推定される．従って，Ancestry非対称と天皇家の弛緩はこのテーマとは直接関わりがない可能性が高い．

2/6版と2/6-1版の差異はソースファイルを直接比較するのが一番早いと思う．いずれにしてもそこから先は「デバッグ」の領域に入ってしまうと思われるのでここでは扱わないことにする．とりあえず，今日のところは2019-02-06まで戻るということで確定ということにしておこう．