早朝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のバージョンが入っているはずなので，それをアンインストールしたため動かなくなるということは考えられます．今朝目を覚ましたら画面に隠れて以下のようなパネルが出ているのを見つけました．どのタイミングで出たものかよくわかりませんが，おそらくインストール画面を閉じたあとに出されていたのではないかと思います．
まだ試していませんが，→の行をクリックするとオンライン・ヘルプにジャンプするのでしょう．「互換性の設定」という話はどこかで聞いたことがあるので，うまくゆけばインストール時のトラブルがすべて解決できる可能性があります（多分そううまくはゆかないだろうとは思いますが…）以下について調べてみたいと思います．
- VAIOに新規ユーザとしてログインしてゼルコバの木をアンインストール→これでOwnerがゼルコバの木を使えなくなるとすればマイクロソフトの「落ち度」と考えられる しかし，新規ユーザとしてゼルコバの木を起動したときの動作から考えると，「すべてのユーザ」を指定していても実際には個別ユーザごとにインストールしていて共有しているのはmsiインストーラだけということも考えられる（実際の動きはそういう感じになってます）
- VAIOの新規ユーザでゼルコバの木ベータをインストール→成功した場合，保説の蓋然性が高くなる
- VAIOに.NET 2.0がインストールされているかどうかを調べる（昔はコントロールパネル→プラグラムと機能でインストールされている.NETのバージョンがずらずらと出てきたのですが…）
- すでに上位バージョンがインストールされているPCに.NET 2.0（ないし下位バージョンの.NET）をインストールする方法を調べる C++のディストリビューションをインストールするという手があるかもしれない
- 「プログラム互換性アシスタント」の動作と「互換性の設定」について調べる 可能ならばそれを使ってインストールを試す
- 他の機種でも「EXEを実行して直接起動」が動作するかどうかを確認する
- ゼルコバの木の直近バージョンで古いサンプルが開けることを確認する（EXEから起動したゼルコバの木ベータで*.QDBを含む2012年以前の古いファイルが開けることは確認済み）
ゼルコバの木ベータで.NET 2.0が必要になるというのはゼルコバの木の根っこがVB6(Visual Basic 6)にあるためとも考えられます．VB6の機能はいまでも使っていますが，コード的には変換されているので .NET 2.0は不要ということになったのではないかと思います．貴重な情報のご提供ありがとうございました．大変参考になりました．
馬場 英治
早速にも上記項目のチェックに入りたいところだが，仕掛りになっている本線が思わぬところで難渋しているので，そちらを先に片付けてしまいたい．修正は32箇所で完全に特定できている．コードは何度も読み直してどこにもミスはないと思っているのだが，思ったように動いてくれない．Visual Studioのコンパイラが誤動作しているのではないかとさえ考えてしまうような状況なので，もはや「本格的なデバッグ」に入るしかないのではないかと判断しているのだが…さて，今日中にこのトラップから脱出できるだろうか？
ありゃ，おかしい．tamo2さんへの返信で添付したはずの画像がメールに入っていない．入れ忘れたのだろうか？画像はVAIOのスクリーンショットだが，Mouse Without Borders で受け渡ししたあと消してしまったのでどこにも残っていない…あ，パネルはまだ閉じていなかった．以下のようなメッセージ※だ．
※この画像はメール本文の位置に移動した
setnodegeneの呼び出しでは「NODULE：nodegeneを廃止する＠20201021」がオンのときとオフのときの相違はあるが，すべてTESTABSOLUTEGENERATIONのブロック内のコードで，現在テスト中の環境では「NODULE：nodegeneを廃止」がオンのときもオフのときもTESTABSOLUTEGENERATIONブロック内のコードは実行されないようになっているので，動作に変化がある可能性はないはずなのだが…TribeRelocationの【５】重婚同類グラフ検定の中でSTOPCARDSHIFTがオンになっている．つまり，絶対番号不一致が解決していない．これは実質的に検定が失敗したことを意味している． 異世代多重カウントオーバーが発生している．現行ではこのループカウントは最大でも1しか認められていない．オリジナル版ではこの事象は起きていない．
オリジナルの場合，当初はmultigenes=28, multicount=50だが，重婚同類検定後はいずれもゼロになっている．修正版でも当初は28, 50だが，最初のループで13, 13に減少したあと変化が止まってしまうため，強制終了しているようだ．オリジナル版と修正版を並行してテストできるようにVS2017のインスタンスをもう一つ立ち上げることにしよう．⇒ダメだ．開発パッケージはコピーを用意したが，OCXを参照できない．以下のようなエラーになる．
どうすればよいか？OCXは多分，uuidとversionで識別しているはずなので，これを変えてみよう．⇒対処した．デバッグモードでテスト環境と開発環境で独立にアプリを走らせることができるようになった．ただし，どうしてもVBからOCXへの参照が通らないので奥の手（プロジェクトに新しいWindowsフォームを追加してテストツールから直接貼り込むという方法）を使って決めた．一つだけ問題がある．VBのプロジェクト→参照の追加→COMでバージョンの異なるOCXが独立に表示されるようにはなったが，一つのOCXをチェックすると同時に複数のコンポーネントにチェックが入ってしまう．これはおそらく同じ名前のモジュールを作っているためと思われるが，もう少し落ち着いてから対処する．
オリジナル版ではループを一度で抜けている．重婚同類グラフ検定の出口ではmulticountはまだ50のままだが，事後処理のTribeGhostNameで19まで減少し，BetweenTwoWomenで残りを一掃している．今回の修正は重婚同類グラフ検定でそれ以外の部分には影響はないはずなのだが，何かしら副作用が出ているのではないか？TribeGhostNameでは「系列枠の範囲内で消去可能な仮ノードを消去する」処理を実行している．ここでは天皇系列だけで仮ノードを60個消去している．
一方の修正版では50→23→7→13→7→13→7→13…を繰り返して結局13でブレークする．TribeGhostNameでは23点になり．次のBetweenTwoWomenで7まで減少するが，MakePairListCleanで13に戻って以下同じパターンを繰り返す．TribeGhostNameではEraseGhostNameで可視の人名ノードを対象に消去を試みている．これがうまく動作していないものと思われる．最初のループでTribeGhostNameは28個の仮ノードを消去している．オリジナルでは31個消去しているが，その差はそれほど大きくはない．
修正版ではTRIBEBOX::adjustGenerationRangeで「先祖ノードが系列世代範囲を逸脱」が起きている．オリジナルでは起きていない．この差異が大きいのではないか？問題が起きているのは蘇我倉麻呂系列と藤原不比等系列，つまり天皇系列以外はすべてということになる．この関数はmin=28, max=31で呼び出されている．なぜだろう？オリジナルではこの関数では天皇系列しか処理されていない．TRIBELIST::ShiftDirectAbsoluteの絶対世代番号不一致→カードシフトでsc=54までは歩調を揃えているが，そのあとから大幅に狂い始める．
これはTribeRelocationのステージ【５.１】絶対世代番号に基づいてカードシフトで重婚同類グラフ検定のメインの処理に当たる．オリジナルではsc=79まで停止しないが，修正版ではsc=58で停止する．この処理は多重グラフ１の連結リストをベースに実行されている．これはハッセ図ではなく，最初の多重グラフ1ができそこなっているのではないか？多重グラフ1はいわゆる重婚同類グラフで，子どもないし配偶者のいない単身者は対象から除外されている．まず，このグラフを比較してみよう．目視で追いかけるより，グラフをダンプしてそれをファイルに格納し，WinMergeで比較するというのが一番速いのではないか？
グラフ１のノードは人名カード，枝は配偶関係で，連結リストには重婚多重集合のリストが生成されている．グラフとしては完全に一致している．それではなぜ動作に差異が見られるのか？⇒どうもフローが少し違うのではないかという気がする．TRIBELIST::ShiftDirectAbsoluteでscount=58のとき停止しているが，オリジナルは五百城入彦皇子で停止し，修正版ではその次の仲哀天皇で停止している．COMPLIST：DumpComplistのscountは前者が59に対し，後者は61だ．両道入姫で絶対世代番号不一致→カードシフトが発生したときにオリジナルではNAMEBOX::ShiftGenerationで余分なダンプが出ている．
修正版ではAbsoluteGeneGapが真になったため復帰している．なるほど原因は分かった．やはり，一箇所手抜きしたところだ．この関数では!getnodegeneが未設定の間は偽で復帰するようになっていたが，現行の人名枠オブジェクトはnodegeneを持っていないため通常処理して真を返しているものと思われる．TestAbsoluteGenerationでは人名枠のnodegeneを設定しているが，この処理全体がコメントアウトされている．AbsoluteGeneGapを呼び出しているのはCardShiftDirectだけだ．CardShiftDirectを呼び出しているのはShiftDirectAbsoluteはこの位置から呼び出されるのが唯一の出現だ．
！解決した！TOPOLOGY::CountMultiCardが11回しか呼び出されていないということは超速で収束しているという意味だ．最も頻繁に呼び出されている関数の中からMARGBOX::GetUpperNodeを選んで実行カウントを数えてみよう．⇒ダンプの量が多過ぎて一晩では終わらないかもしれない．どこかにグローバル変数を作ってカウントした方がよいかもしれない．⇒いや，完了した．修正版の呼び出し回数は2,156,353回だ．200万回以上実行されている．オリヂナル版のカウントとも正確に一致する．これで2つのバージョンの互換性はほぼ確証できたと言えるだろう．（不一致の可能性は10^6分の1以下とみてよい）
結論的にはAbsoluteGeneGapという関数はまったく不用だったということになる．NAMEBOXだけでなく，MARGBOXのgenenodeも不用なのではないかと思っているのだがどうだろう？⇒これはまた明日ということにしておこう．現状で天皇家を描画するまでに4.7秒くらい掛かっている．渋沢で6秒だ．⇒渋沢でTightenHasseDiagramを実行中MINMOV不定で停止した．このサンプルは避けられない多重が6あるのでやむを得ないものと思われる．いや，渋沢ではなく源氏だった．