午前11時起床，雨．9時ごろから雷鳴を伴う豪雨になっていたが，一時休憩に入ったようだ．朝食は抜き．VS2005からVS2017の変換がなかなか収束しない．対処したところも暫定対策で本格的に稼働するまでには相当な紆余曲折が予想される．ともかく一歩づつ進むしかない．

午前10時起床，晴れ．大型の台風が本土接近しているという話だが，今のところはカンカン照りが続いている．朝食は薄切りパン2枚にレモンジャム．今回のレモンジャムは作り残って粒が残ってしまった．最後に残ったオブジェクト配列の問題に掛かるとしよう．この修正をパスして最終版のデバッグに転回するという選択肢もあり得るが，いずれは対策しなくてはならない部分であり，本番前のリハーサルを兼ねて試してみることにする．

オブジェクト配列を使っているのはCardBox.vbだけと思われるが，17個も実装されているので，それらを一つづつ片付けてゆくしかない．CardBox.vbを開くと「メインディスプレイのスケールは125%に設定されています．100%のスケールでVisual Studioを再起動します．」が表示され，再起動を実施すると，今度は「自動スケールがオフになっています．WPF/UWP XAMLデザイナーが正しく表示されない可能性があります．自動スケールでVisual Studioを再起動します．」が表示されて堂々巡りになってしまう．スケール値を設定している場所が見つからないので放置とする．修正が必要となるオブジェクトには以下がある．

1. Nengo  ComboBox　Cardbox
2. Check1  CheckBox　Cardbox
3. Yoshi  CheckBox　Cardbox
4. KodomoSeibetu  ButtonArray　Cardbox
5. adate   Panel　Cardbox
6. cay TextBox  Cardbox
7. mei  TextBox　Cardbox
8. nenrei  TextBox　Cardbox
9. nonth  TextBox　Cardbox
10. sei  TextBox　Cardbox
11. xear  TextBox　Cardbox
12. address  TextBox　Cardbox
13. Kno  TextBox　Cardbox
14. Yusen_merge　CheckBoxArray　MergeName
15. mei_merge　TextBoxArray　MergeName
16. regno_merge　TextBoxArray　MergeName
17. sei_merge　TextBoxArray　MergeName

いや，どうもこの修正は思ったより大変だ．CardBox.vbフォームにはあらかじめ，nengo0～11のオブジェクトが配置されている．これをNengo[]という配列で統一的にアクセスできるようにしているのだが，オブジェクトの配列で個別のセルを異なる位置に配置するということができるのだろうか？いや，発想が反対だ．多分現在の実装をあまり改変せずに対応できるはずだ．つまり，①フォームのロード時にオブジェクトの配列を生成する，②SetIndexの代わりにオブジェクトを配列に代入する，という手順でよいのではないだろうか？

Nengoのオブジェクト配列からオブジェクトの配列への転換は大体できたが，オブジェクト配列はイベントを受けられるようになっているのに対し，オブジェクトの配列ではそれができない．対処できるだろうか？NengoではLeaveとSelectedIndexChangedの2つのイベントを処理している．これを個別オブジェクトのイベントハンドラから起動するようにするというのもありがたくない話だ．オブジェクトの配列は結局隠しオブジェクトになってしまうから，明らかにそれ自体のイベントというのはあり得ないように思われる．しかし，いまのところそれ以外の方法はない．とりあえず，イベントハンドラーはすべてコメントアウトして切り抜けておく．

SetIndexを実行している行をすべて書き換えて，InitializeCardBoxとInitializeMergeBoxに集約したが，まだまだ山のようなエラーが出ている．

1. VB6.FixedLengthStringは廃止されている　⇒　これを使っているWriteProtect関数には疑問があるので暫定的に止めておく
2. VB6.TwipsToPixelsXは廃止されている　⇒　この関数はLoadWndRectから呼び出されている．前回終了時のフォームサイズはTwips単位でレジストリに格納されている．⇒暫定的にTwipsToPixelsXとTwipsToPixelsYという関数を作って呼び出すようにした．この逆関数PixelsToTwipsX/Yも同様とする
3. VB6.CopyArrayは廃止されている　⇒　暫定，Cloneを使う
4. VB6.FontChangeSize，VB6.FontChangeBold，VB6.FontChangeItalic，VB6.FontChangeUnderline，VB6.FontChangeStrikeout，VB6.FontChangeNameは廃止されている　⇒　Font.SizeはReadOnlyで書き込むことができない．

午前8時半起床，晴れ．朝食抜き．VBを除く DLL, GC, OCX の主要3コンポーネントはすでにエラーなしでビルドできるようになっているが，VBのところで頓挫している．2019/01/08 でも2010から2017 への移行というのを実施している．ほぼこのときのログの記述に沿って進行したのだが，前回はVBではほとんど問題なくスルーすることができた．この作業に掛かる前にメイン機がインターネットに接続してしまうという問題を見ておこう．

現在メイン機には２つのWi-Fiルータが接続されている．LTEのルーターGL04PとWIMAX2のルータSPWNだ．LTEルーターはUSBでPCに接続している．前者は回線契約が切れているため，ネットにアクセスすることはできない上，LANのハブとしても使われていない．単純にPCがWIMAX経由でネットに接続するのを防止するためのロックとして使っているだけだ．このためにはLTEの接続優先順位がWIMAXより高い必要があるが，なぜか逆転してしまっている．下記を参考にWi-Fiの優先順位を変更してみた．

Windows 10 パソコンでWi-Fiの接続優先順位を設定する手順

コマンドラインプロンプトで以下を実行するだけで切り替えできる．

netsh wlan set profileorder name=ルーター名 interface=インターフェース名 priority=1

ただしインタフェース名にスペースが入っているとエラーになるので，Wi-Fi 2からWi-Fi2にリネームした．インターフェース名の変更はネットワークとインターフェース→ネットワーク接続で実行できる．GCをビルドして以下の警告が出た．

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2729,5): warning MSB3284: タイプ ライブラリ “f10efde4-db94-11d2-b863-289605c10026” バージョン 1.0 のファイル パスを取得できません。ライブラリは登録されていません。 (HRESULT からの例外:0x8002801D (TYPE_E_LIBNOTREGISTERED))

2019年1月18日のログにはこれに対処するために，VS2017をフルインストールしたとある．現行の開発環境はこのときとまったく同じはずだから，特に不足するものはないはずなのだが… 実際すべてのコンポーネントがインストール済になっている．修復インストールを試してみよう．完了したが，状況には変化がない．DLLでも同種の警告が出ていた．

2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2729,5): warning MSB3284: タイプ ライブラリ “f10efde4-db94-11d2-b863-289605c10026” バージョン 1.0 のファイル パスを取得できません。ライブラリは登録されていません。 (HRESULT からの例外:0x8002801D (TYPE_E_LIBNOTREGISTERED))

ソースコード画面のユーザインタフェースがかなり変わった．C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets が前面に出ていて他のファイルにタブで切り替えることができない．以前の設定をインポートしてみる．エラーが２件発生した．

設定はインポートされましたが、エラーが発生しました。

エラー 1:  ‘拡張機能と更新プログラム’ の設定のインポート中にエラーが発生しました [コード 5302]。
エラー 2:  ‘CoffeeScript’ の設定のインポート中にエラーが発生しました [コード 5297]。

どうも設定の選択を誤ったようだ．今まで使っていた設定は保存されていない．どこかにあるはずだが… 拡張子は .vssettings だ．SDドライブに一つ入っていたが，エラーが発生して移行できない．仕方ない．作り直すことにしよう．

ZelkovaGC3 が.NET 4.0を使っているため下記のエラーになる．

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3274: プライマリ参照 “ZelkovaGC3, Version=0.0.0.0, Culture=neutral, processorArchitecture=x86″ は、”.NETFramework,Version=v4.0″ フレームワークに対して作成されているため、解決できませんでした。これは現在ターゲットされているフレームワーク “.NETFramework,Version=v2.0” よりも新しいバージョンです。

VBでも.NET 4.0を使うように設定して，このエラーは解消した．最後に残ったのはオブジェクト配列関係が廃止されているという問題だけになった．現行バージョンでもこれらのオブジェクトは使われている．その前に

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3270: 構築されているプロジェクトのプロセッサ アーキテクチャ “MSIL” と、参照 “ZelkovaGC3, Version=0.0.0.0, Culture=neutral, processorArchitecture=x86” のプロセッサ アーキテクチャ “x86” の間には不一致がありました。この不一致は、ランタイム エラーを発生させる可能性があります。プロジェクトと参照の間でプロセッサ アーキテクチャが一致するように、構成マネージャーを使用してターゲットとするプロジェクトのプロセッサ アーキテクチャを変更するか、ターゲットとするプロジェクトのプロセッサ アーキテクチャに一致するプロセッサ アーキテクチャとの依存関係を参照で設定することを検討してください。

のようなエラーが発生している．⇒VBの設定でターゲットCPUをx86に切り替えてこのエラーは出なくなった．廃止されたオブジェクト配列には以下がある．

1. CheckBoxArray
2. ButtonArray
3. ComboBoxArray
4. PanelArray
5. TextBoxArray

このようなものが総数で17個使われている．これはVS2015を導入したとき，変換を途中で打ち切ってしまったために起こっているのではないだろうか？しかし，それでは現にエラーなしにコンパイルできる版があることを説明できない．コンパイル可能な版にもオブジェクト配列は温存されている．

もう一度VS2005→VS2017をやり直してみることにする．現在仕掛りの版はZELKOVA2018 2019-08-12 BADとした．しかし，開始プロジェクトのV2.0.2.229_R2018-10-07はすでに上書きしていたのではなかったろうか？EドライブのE:\ZELKOVA 2018 BACKUP\ZELKOVA-2018-10にZELKOVA_2018-10-07が残っている．これを使ってみよう．

一方向のアップグレード
Visual Studio は、次のプロジェクトを開くために機能的な変更を自動的に行います。プロジェクトの作成に使用したバージョンの Visual Studio では、プロジェクトを開くことができなくなります。
      – ZelkovaDLL3, “D:\ZELKOVA_2020\ZELKOVA2018\ZelkovaDLL\ZelkovaDLL.vcproj”
      – ZelkovaVB3, “D:\ZELKOVA_2020\ZELKOVA2018\ZekovaVB\ZelkovaVB3.vbproj”
      – ZelkovaGC3, “D:\ZELKOVA_2020\ZELKOVA2018\ZelkovaGC\ZelkovaGC.vcproj”
      – ZelkovaZ3, “D:\ZELKOVA_2020\ZELKOVA2018\ZelkovaZ\ZelkovaZ.vcproj”
      – ZelkovaTree, “D:\ZELKOVA_2020\ZELKOVA2018\ZelkovaTree.sln”

変更は必要ありません
これらのプロジェクトは、変更せずに Visual Studio 2015、Visual Studio 2013、Visual Studio 2012、および Visual Studio 2010 SP1 で開くことができます。
      – Solution Items, “Solution Items”
      – SetupBeta3, “D:\ZELKOVA_2020\ZELKOVA2018\SetupBeta\SetupBeta.vdproj”

VB3では以下のメッセージが出ている．

ZekovaVB\ZelkovaVB3.vbproj: このプロジェクトは .NET Framework 2.0 または 3.0 に対応しています。プロジェクトで新しい .NET Framework を必要とするアセンブリを使用すると、ビルドに失敗します。[プロジェクト] メニューの [プロパティ] をクリックし、[.NET Framework] ボックスの一覧で新しいバージョンを選択することにより、.NET Framework のバージョンを変更できます。Visual Basic では、これは [コンパイル] タブの [詳細コンパイラ オプション] ボタンをクリックすると表示されます。

さらに146個のメッセージがあるが，すべてバックアップに関するものだ．この変換はVS2010に対応するものでそれ以上の変換は実施されていない．しかし，このレポート画面は前回も見ているので実質的な変化は存在しないとみなくてはならない．選択肢としては，①オブジェクト配列の廃止に対応するか，ないし，②安定版の供給を断念して最終版のデバッグに注力するか？のいずれかしかない．

午前9時起床，曇り．朝食は抜き．今日は少し涼しいが扇風機を回している．昨日の続きに戻ろう．最新の安定版と思われるV2.0.2.229_R2018-10-07をVS2017に移植しているところだ．この版は公式リリース/安定版ではなくZELKOVA_2018フォルダにあったものだが，多分最終の安定版と考えてよいと思われる．上書きしてしまったためオリジナルはすでに残っていないが，VS2005上で開発されていたものと推定される．

1. C1083    include ファイルを開けません。’MAPIWIN.H’:No such file or directory    ZelkovaDLL3    d:\zelkova_2020\v2.0.2.229_r2018-10-07\zelkovadll\src\kakeizu.cpp    16    ⇒　コメントアウト
2. LNK1104    ファイル ‘mfc80d.lib’ を開くことができません。    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\LINK    1  
3. 以下のようなエラーが大量発生する：LNK2001    外部シンボル “”class ATL::CAtlBaseModule ATL::_AtlBaseModule” (?_AtlBaseModule@ATL@@3VCAtlBaseModule@1@A)” は未解決です。    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\DrawTree.obj    1    ⇒  特定の既定のライブラリを無視：atls.lib を指定から外す
4. LNK1120    1 件の未解決の外部参照    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\Debug\ZelkovaDLL3.dll    1   
5. LNK1117    オプション ‘VERSION:1.8.0’ に構文エラーがあります。    ZelkovaGC3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaGC\LINK    1   ⇒　VERSION 2.0 とした
6. MSB3284    タイプ ライブラリ “f10efde4-db94-11d2-b863-289605c10026” バージョン 1.0 のファイル パスを取得できません。ライブラリは登録されていません。 (HRESULT からの例外:0x8002801D (TYPE_E_LIBNOTREGISTERED))    ZelkovaGC3    C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets    2729    ⇒　最小のターゲットシステムをNT60からNT51に変更，パラメータの確認を/norobust から /robust に変更
7. MSB8012    TargetExt(.dll) が Linker の OutputFile プロパティ値 (.ocx) と一致しません。このため、プロジェクトが正常にビルドされない可能性があります。この問題を解決するには、$(OutDir)、$(TargetName)、および $(TargetExt) の各プロパティ値が、%(Link.OutputFile) で指定されている値と一致することを確認してください。    ZelkovaZ3    C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets    1217    ⇒　ターゲットの拡張子を.dll から .ocx に変えた

ここまでの修正でDLL, GC.DLL, OCXの3つのコンポーネントはすべてエラーなしでビルドできるようになった．VBのビルドではまだ大量のエラーが出ている．

1. 以下のようなエラーが大量発生する：IDE0044    Make field readonly    ZelkovaVB3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZekovaVB\FindCard.vb    53    アクティブ　⇒　エラーが出ている項目は参照されていないのでコメントアウトしておく
2. IDE0017    オブジェクトの初期化を簡略化できます    ZelkovaVB3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZekovaVB\ImportFile.vb    140    アクティブ　⇒　初期化部分をWith … End With で囲む
3. プライマリ参照 “ZelkovaGC3, Version=0.0.0.0, Culture=neutral, processorArchitecture=x86″ は、”.NETFramework,Version=v4.0″ フレームワークに対して作成されているため、解決できませんでした。これは現在ターゲットされているフレームワーク “.NETFramework,Version=v2.0” よりも新しいバージョンです。    ZelkovaVB3   ⇒    

かなり厄介な問題が持ち上がってきた．オブジェクト配列が廃れてしまっている．

午前9時起床，晴れ．今日も暑い．朝食抜き．少し昼寝した．眼が疲れている．昨日からダイソーのメガネを使っているためだろうか？遠近両用メガネにはブルーライトカットが入っているのでその違いかも知れない．ともかく少し動き始めたので先を急ごう．

現行の開発環境で問題なく動作していることが確認できたので，次にやるべきことは最新の安定版を確保することだ．2018/02/10には「規準Nodeの配偶者が枠外に出てしまう問題」に掛かっているが，これが目下仕掛りとなっている課題なのでそれより前で探さなくてはならない．2018/02/10の始業時バックアップを試してみることにしよう．⇒ダメだ．昨日のオープンテストで発生した反例BUG19-08-10 02-35-27.ZELで始系列の有線ノード不在が発生してしまう．

この障害は ZELKOVA2019_2019-02-06-2ですでに発生している．ZELKOVA2019_2019-02-06でも起きる．オープンテストを通ったかないし，好成績を揚げたバージョンが欲しいところだが，2月にはテストをまったく実施していない．ZELKOVA2020フォルダ中で一番古いのはZELKOVA2019_2019-02-02-1だが，すでにここでも同じエラーが発生している．1月にはオープンテストを実施している形跡はあるが，成績は芳しくない．

ZELKOVA2018フォルダにはそれ以前の版が入っているが，すべてVS2015でビルドされているためVS2017に移行するための作業が必要になる．ここには2つの安定版がある．V2.0.2.229_R2018-10-07とV2.0.1.978_R2018-03-30だ．VS2015を開発機に再インストールしてビルドし直すことも考えられる．VS2015にはAnyCPUというモードがあったはずだ．ともかくそれをやってみることにしよう．Visual Studio 2015 はVSのダウンロードページから探すことができる．ただし，X64版とX86版が独立しているようだ．Visual Studio Community 2015もあるが，こちらはX86版しかない．

Visual Studio 2015 Update 3 をダウンロードしてみた．これにはX86とX64が入っているようだ．インストーラからダウンロードするようになっているので，ネットに接続する必要がある．Update 3だけではダメのようだ．Visual Studio Community 2015 with Update 3 というのがあった．インストーラはX64版とX86版を並列インストールしている！アイコンは1つしか作られないので，内部で切り分けるようになっているのだろう．VS2015はインストールできたが，やはり移行措置が必要になる．これはおもしろくない．むしろ，現在のプロジェクトにソースコードだけ移植してVS2017でコンパイルした方が早いのではないだろうか？

やってみたが大量エラーが発生する．これはやはりストレートに移行手順を踏むしかないのではないだろうか？オリジナルのV2.0.2.229_R2018-10-07をコピーしてVS2017で開いたらプロジェクトがすべてVS2015に切り替わっている．確かにZELKOVA2018で直接このフォルダをVS2015で開いてしまっているかもしれない．ビルドするとインクルードエラーが発生する．

VS2017ではプロジェクトごとにインクルードパスを切ることになっているからだ．インクルードパスは現行プロジェクトからコピーして片付いたが，コンパイルエラーが大量発生している．コンパイラーの構文検査が厳格になり，同一名の局所変数が使えなくなっている．相当な時間を掛けて片付けることはできたが，まだかなりのエラーが残っている．

1. E0020    識別子 “__checkReturn_wat” が定義されていません    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\SRC\comdebug.cpp    28    ⇒暫定的にこの行を止めた
2. C4996    ‘GetVersionExA’: が古い形式として宣言されました。    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\SRC\BugReportDialog.cpp    334    ⇒　暫定的にコメントアウト
3. E0308    オーバーロードされた関数 “abs” の複数のインスタンスが引数リストと一致します:    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\SRC\BugReportDialog.cpp    817    ⇒　absをfabsに変えて解決
4. E0020    識別子 “_get_amblksiz” が定義されていません    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\SRC\BugReportDialog.cpp    929    ⇒　暫定的にコメントアウト
5. LNK1117    オプション ‘VERSION:1.8.0’ に構文エラーがあります。    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\LINK    1    ⇒　親から継承
6. LNK1104    ファイル ‘mfc80d.lib’ を開くことができません。    ZelkovaDLL3    D:\ZELKOVA_2020\V2.0.2.229_R2018-10-07\ZelkovaDLL\LINK    ⇒ライブラリパスを$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86として解決

2019/01/06のログにVS2010試供版をインストールしたという記事がある．ここでは上記と同種のエラーが確認されているが，やはり一つづつこつこつ潰していくしかないようだ．プロジェクトのプロパティでプラットフォームツールセットをVisual Studio 2017 [v141]に切り替えたら，また大量の「…を宣言すると、クラス メンバーが隠蔽されます」が出るようになった．

午前9時起床，晴れ．朝食はサラダうどん3/4食．出遅れたので大急ぎでギブスを装着して新井整形に走る．これ以上悪化したら全体をギブスで固めますよ（現在は片側だけで取り外し可能）と言われていたので形だけでもギブスを付けなくてはならない．急いでいたので入れ歯を入れるのを忘れてしまった．レントゲン写真4枚のコピーをもらう．「ここがずれているが，そのまま安定したようだ」と言われたが，あまり納得しない．部屋に戻ってすぐにギブスを外した．

傷口にはまだ化膿が少し残っているが，化膿止め（抗生物質）はすでに止めて皮膚を乾燥させる軟膏というのを使っているのだがあまり効果がない．むしろ傷口を完全に開放して自然乾燥させた方が治りが早いような気がする（経験的に実証済）．医院は連休に入るので次の診断日（来週金曜）までは放置することにした．昨日はフロに入ったあとそのまま寝てしまった．EnglishBreakThrough　Chalenge の最後の課題を明日までに片付けなくてはならないのだが，昨日サボってしまったのでともかく仕事に戻ることにする．

手元にはWindows 10 搭載PC2機しかないので，これを使ってやれることをやるしかない．ここまでの観察で結論的に言えることは一つだけだ．つまり，「64ビット版と32ビット版は別々にビルドするしかない」ということだろう．現行ではAnyCPUという設定でビルドしているので，システム側で適宜対応してくれるものと思っていたのだが，Windows 10 の新しい環境ではそれが通用しなくなっていると考えるしかない．

Windows 10 にも32ビット版と64ビット版がある．ここにあるのはどちらも  64ビット版だ．これまでのところインストールに成功したのはZelkovaTreeSetup.2.0.2.261.msi だけだった．この版はVS2015でビルドしたものと推定しているが，正しいだろうか？しかし，VS2015からVS2017に移行したのは2018年12月なので，それ以前のバージョンはすべてVS2015製のはずだが，インストールできていないのではないか？

ZelkovaTreeSetup.2.0.2.261.msi だけは ZELKOVA_2019  に単独で保管されているので，この版は旧開発機つまり，lenovoから直接コピーされたものである可能性がある．もし，そうであるとすれば従来通りの動作となる版はWindows 7 環境で生成されたものに限定されるということになる．

ZELKOVA\/2018 に入っているインストーラはすべて2018年12月以前に生成されたものだが，インストールエラーが発生する以前に以下のようなエラーになってしまう．

外付けHDに入っている2017年版でも同じエラーになってしまう．どういうことだろう？違う．これはカスペルスキーのブロックが作動しているためだ．どうも具合が悪い．しかし，カスペルスキーのブロックを解除してもOCXの登録で失敗する状況は同じだ．

どうもこのZelkovaTreeSetup.2.0.2.261.msi という版はかなり特殊なものと考えるしかなさそうだ．このインストーラがどのような環境で作られたのかを突き止めなくてはならない．おそらく，この版だけはビット数に関わりなくインストールできる唯一のバージョンとなっている可能性がある．

2018/12/29の記事には，「Visual Studio 2015でビルドしたX86版をゼルコバの木2018，Visual Studio 2017でビルドしたX64バージョンをゼルコバの木2020と呼ぶ」としている．これはおそらくZELKOVA_2018, ZELKOVA_2020フォルダに対応していると考えてよいだろう．

現在メイン機として使っているDiginnosを導入したのは2018年11月頃と考えられるので，ZELKOVA_2018の中身はすべてlenovoからコピーされたものと考えてよいと思う．それにしても分からないのが，ZELKOVA_2019 の出自だ．これが突き止められれば32ビット，64ビット併用版を現時点でも生成できる可能性はあるのだが…

いや，このパッケージはどうもVisual Studio 2010で生成されているもののように見える．プロジェクト名の脇にVisual Studio 2010 とある．

Visual Studio 10 はメディアからインストールするしかないようだが，手元にあったろうか？VS2010は手もとにないし，インストールした記憶もない．ただし，このパッケージがVS2017で開けるということは少なくとも一度VS2017でプロジェクトを開いたことがあるのではないか？2018年頃の版を開こうとすると下記のようなパネルが表示される．

このような古い版を開いてかつ，VS2017に移行しないという選択肢があることも考えられる．もしそのようなことが可能であるとすれば，ある種の活路となる可能性もあり得るが…プロジェクトのプロパティ：プラットフォームツールキットでVS2010を選択できる．これはもしかするとVS2010の試用版をインストールして生成したものではないか？

2019年3月の最終版を見てみよう．おかしい．何か勘違いしていたのだろうか？問題なくビルドして実行できる．つまり，3月時点と同じ状態になっている．

リリース日付は2019/02/06となっているが，これが最終版であることは間違いない．なぜこんな勘違いが起きたのだろう？前回チェックしたときといまの環境でもっとも大きな相違点はメガネだ．前回は最近購入したばかりの遠近両用メガネを使っていたが，どうしても視野が狭く目が疲れるのでダイソーで買った4度に替えてみた．確かにこの方が楽だ．遠近両用は眼科医で検眼しメガネ屋で調整したので5万円も掛かっている！しかし，それでも腑に落ちない点がある．

2019/08/04のログには「最終版：2019/03/10をデバッグモードでビルドしてエラーになる．VBで未定義シンボルが発生している」とある．もう一度クリーンビルドしてみよう．どうも警告をエラーと誤認してしまったのではないだろうか？

エラーは1件発生しているが，無視して実行できる．リリース版をビルドしてみよう．問題なくインストールできた．ということは現行の開発環境にはなんら問題はなかったと言うことになる．問題を開始点に戻って解析し直さなくてはならない．

最新の安定版のEXEが実行できないという事象が起きていた．V2.0.2.143 R2018-08-18という版だ．日付から見て，これはVS2015でビルドされたものと思われる．VS2017にインポートしてみよう．この版では上記の「一方向のアップグレード」が発生するため互換性が維持できない．

この移行作業はかなり厄介だったような気がするのでできればパスしたい．2月6日が最終リリース日付になっているのでこの辺りのログを読んでみよう．このころはスマホが手に入ったころなのでまだ，ネット上の動画を漁っている．この後，2月10日から「基準ノードの配偶者が枠外に出てしまう」問題に掛かっているので，2月7日には一旦収束したものと考えてもよいように思われる．この版を起こしてテストしてみることにしよう．

いままでまったく気付かなかったが，Visual Studio 2017 のメニューに見慣れない英字タイトルのメニューが2つある．Incredibuild と R tools だ．Rというのはデータ解析用のツールセットのようだ．日本語メニューにも「分析」という項目はあるが，それを拡張したもののように見える．Incredibuild というのはVSのコンパイル時間を短縮するための分散処理技術と思われる．製品価格で14万円もしたものだ．VS2017は無償の上にこんなおまけが付いているとは思わなかった．

2019-02-07の安定版候補をビルドしようとしたら，大量のエラーが発生した．エラー件数17件，警告8件というのは前にも見ている．管理者権限でVSを起動したら通った．ZELKOVA2020_2019-08-09というビルドができた．テストしてみよう．障害サンプル集のオープンテストを実施してみる．このFolderには2605本のサンプルが入っている．ダメだ！早速SUWが出てしまった．

かなり芳しくないできだ．その上，描画上のゴミも出ているようだ．さらに最悪なことにはどうもどこかでハングしている模様だ．FB4反例/FB4検定2017-05-23/毀損サンプル/B UG15-12-28 14-52.NONで起きている．

午前10時半起床，晴れ．朝食は薄切りパン2枚に自家製レモンジャム．カスペルスキーから応答があった．不具合はすでに解消しているが，「当方サーバーの問題」である可能性が高いとの返答だった．カスペルスキーのロゴも変わっている．カスペルスキーのロゴが kaspersky lab から kaspersky に変わったことはニュースレターで承知していたが，わたしの記憶違いでなければEU圏限定だったような気がしているのだが…

lenovo ノートは工場出荷状態に戻すことでログインすることはできるようにはなったが，かなり不調だ．というか，昨日の移行作業中にも一度クラッシュして再起動になっている．このときのリブートでWindows を更新しているので，果たして期待するような動作になっているかどうかも疑問だ．

ともかく動いている間にできるテストを済ませておくことにしよう．ダメだ．リブートできなくなってしまった．通常起動と修復スタートアップという選択肢があるが，どちらを選んでも beeping になってしまう．完全に寿命が尽きたと考えるしかなさそうだ．たとえ起動できたとしても動作が緩慢でほとんど重病人という態なので使い物にならないと考えた方がよさそうだ．→ビープを無視して続行してスタートアップ修復画面までは進んだが，「スタートアップ修復ではこのコンピュータを自動修復できません」が表示されている．こうなっては廃棄しかないだろう．

Windows 7 搭載機がなくなってしまった．どうすればよいか？使用可能なPCはタブレットを含めて2台になってしまった．まず，OSのバージョンを確認してみよう．メイン開発機はまだ完全スキャンの実行中だ．76%しか進んでいない．どうもスタンバイに入るとバックグラウンド動作も止まってしまっているような気がする．メイン機はWindows 10 Home バージョン：1809　インストール日：2019/01/19 OSビルド：17763.615 だ．タブレットも同じ Windows 10 Home バージョン：1809 インストール日：2019/01/04 OSビルド：17763.615 となっている．この2つのマシンにそれぞれ異なるレビジョンの Windows 10 をロードすることができれば，ある程度のことは調べられるかもしれないが，できるだろうか？

Visual Studio を再インストールしてみれば，何か多少の情報が得られる可能性もあるが，インストール不能という事象は外部ユーザのマシンでも起きているのであまり意味がないようにも思われる．また，VS2017 を再インストールするとしたら，またマイクロソフトサイトからダウンロードしなくてはならないから，それがアップデートされていればほとんどやっても意味がない気がする．

午前8時起床，晴れ．朝食は食パン8枚切2枚，ベーコンエッグ．今日は外出しないつもりでギブスを外し，包帯も解いて軟膏を付けただけの状態にしている．左足の手術後の傷跡の辺りが黒く腫れの戻りが遅いのが気になる．内部で化膿していなければよいが…

lenovo は工場出荷状態に戻してしまったので，（プリインストールされているアプリを除けば）すっかり空の状態になっている．リカバリーディスクを使えば2012年8月までは戻せるが，パスワードがなければアクセスできない．パスワードの頭文字はRGLでこれにやや近接した語句 Remote Distance Love を思いついたが，2文字目が一致しない．

OCXの登録ツール Regsvr32 には32ビット版と64ビット版があり，32ビット版のOCXを登録するためには32ビット版のRegsvr32 を使わなくてはならないということのようだ．OCX もC:\Windows\SysWOW64 という特殊なフォルダに置かなくてはならないようだ．本来ならOCX/DLL はそれを参照する EXE のフォルダ以下ならどこに配置してもよいということになっていたはずなのだが… かなり理不尽な仕様変更と言わなくてはならないが，いつからこんなことになっていたのだろう？少なくとも2019/03/09以前ではこのような問題は起きていなかったと思うのだが…

Dドライブに Windows 10 クリーンインストール というフォルダがある．日付は2019/01/18 だ．クリーンインストールの手順は忘れたが，ログには「クリーンインストールに掛かった正味時間は2時間くらい」とあるので時間コストは無視することができる．ただし，その後各種アプリをダウンロードしてインストールしなくてはならないのでトータルではかなり掛かりそうだが…

ashikaga氏のレポートではクリーンインストールを実行後のインストールでエラーになったという… 開発機ではクリーンインストール後にVS2017をインストールし，ビルド→インストールを何度もやっているはずだが，この動作上の違いはクリーンインストールを実施した時期とみるしかないのではないだろうか？ashikaga氏も「Windows update からの update なら問題なく動作する」としている．これはおそらく「Windows 7 から Windows 10 にアップグレードした後，Windows update で更新した場合」の意味と解釈されるが，いずれにしてもある時点まではWindows 10 で配布インストーラが問題なく動作していた時期がある，と考えて間違いないのではないかと思われる．

さて，どう対策すればよいか？

1. Windows 7 搭載の lenovo に既存インストーラをコピーしてインストール可能であることを確認する
2. 手操作でOCXをSysWOW64にコピーし，SysWOW64/Regsvr32で登録し，EXEを実行して動作することを確認する
3. 開発環境で既存プロジェクトを開き，デバッグモード，リリースモードでビルドしてそれぞれ実行可能であることを確認する
4. 既存インストーラプロジェクトで新規に生成されたmsi インストーラが lenovo で実行可能であることを確認する
5. 32ビットOCXを生成し，それを所定のフォルダに配置して登録・実行が可能となるような32/64ビット版インストーラ・プロジェクトを構築する
6. #5で生成されたインストーラが Windows 10 実機で実行可能であることを確認する
7. OCXが64ビット化可能であるかどうかを調べる→これは実現不能である可能性が高い

lenovo にカスペルスキーをインストールして，マイカスペルスキーで状態を見ようとしたが，「初期化中」のまま，いつになっても「端末は保護されています」が表示されない．かなり具合の悪い状態だ．カスペルスキーのサポートに以下のような問い合わせを送った．

セキュリテイプレミアライセンス版（10台）のうち4台接続しています．うち2つはノートPC（Window 10 と Windows 7），1つはタブレット（Windows 10），もう１つはスマホ（Android）です．マイカスペルスキーにログインして「端末」を開くとAndroid スマホを除く3台の状態がすべて初期化中のままになってしまいます．スマホだけは比較的短時間で「端末は保護されています」に変わります．少なくとも半年前にはこのようなことは起きていなかった（と思う）のですが…なお，現在は「初期化中」となっていますが，少し前はすべての端末が「ステータスが不明です」の状態になっておりました．原因と対処策をご教授いただければ幸いです．

もう一つ具合の悪い事象が発生している．サイトに投稿したログを再編集するためにダウンロードすることができない．下書きがあるので作業は継続可能だが… 以前もこのようなことは起きたことがあるような気はするが，あまりよい兆候ではない．早速サーバーエラーが出た！xmlrpc.php405 Not Allowed というエラーだ．

カスペルスキーからはまだ応答はないが，対処してくれたのだろうか？ほとんど瞬時にステータスが表示されるようになった．開発実機は完全スキャンを実施しているので砂時計が出た状態で「スキャン中」を示している．それ以外はすべて「端末は保護されています」になった．

どうも WordPress に投稿するときにはカスペルスキーのセキュアコネクションというのは使えないようだ．これを外したらIPアドレスが変化してFTPのアクセス制御をパスできるようになった．だいぶまともになってきたのではないかと思う．

午前9時起床，晴れ．朝食はパン（ヤマザキのデニッシュブレッドチョコ3片）．時間がなかったのでギブスを外したまま新井整形に自転車で走り，レントゲンを取る．左足甲側面の骨折部にずれがあり，ギブスの着用厳守を指示される．9日金曜日にもう一度レントゲンを撮ることになった．

メインマシンの通知ボックスにOutlookからの着信通知が入ってきた．これはマイクロソフトアカウントがアクティブになったということを意味する．Outlookはずっと開いていなかったが，2019/07/13付けでasikaga氏からのフィードバックが入っている．Ver2.0.0.789 をお使いのユーザでWindows10Update1903May をクリーンインストール後 Ver2.0.0.789 のインストールに失敗したというクレームだ．やはり，zelkovaZ3.ocx の登録失敗が起きている．

まず，このVer2.0.0.789 の素性を調べておこう．開発用マシーンの安定版の中ではV2.0.1.181_R2016-11-16 がもっとも古いのでそれ以前のバージョンと思われる．従って，この版は lenovo 上のVS2015で開発されたものと推定される．lenovo ノートPCは廃棄予定で，現物はまだ温存されているもののログインパスワードを失念してしまったため起動することができない状態になっている．

この際なのでまず，このマシンを復活できるかどうか試してみることにする．パスワードリセットという機能があるが，これを使うためにはあらかじめパスワードリセットディスクを作っておく必要がある．そんなものを作ったことはないので，この方法は使えない．

パスワードの頭文字3文字は分かっているのだが，それから類推することができない．うち1文字はLなので言語は英語であるように思われるが，連想記憶がさっぱり働かない．このパスワードはDiginnos でもしばらく使っていたようなのだが…

搭載されているOSは Windows 7 Home Premium だ．lenovo のOSはインストール済でDドライブからリカバーすることは可能だが，ログインしないことには始まらない．ネット情報ではF11でシステムリカバリが起動することになっているが，作動しない．リカバリディスクは2種作ってある．一つは工場出荷リカバリでCD2枚，もう一つは事後に作成したものでCD7枚セットになっている．まず，これを試してみよう．F12でCDからリカバリディスクを起動することができた．残り時間は2時間と表示されている．

mmm… Hishitani氏からもメールが入っていた．Hishitani氏の場合もパソコンのリプレースという理由だ．新しいパソコンのOSは不明だが使用していたバージョンはZelkoba Bera Ver.1.9.4.20 2010-02-14 ライセンスコード AVWIWCB でインストール自体は問題なく実行できたようだ．10年も昔のソフトをいまだに使ってくださっている！というのはありがたいことだ．バージョン番号のメジャー番号が1なのでゼルコバの木ベータと呼んでいた時期のものと思われる．開発環境はVS2015と思われるが，もしかするとそれ以前かもしれない．

公式リリースのバックアップには2010021317 KGZIZNL AVWIWCB と 2010021716 IJOGPBF GIHPIAM は保管されているが，2010-02-14という日付の版は残っていない．もしかすると，個人的に特注版として発送しているのかもしれないが… ユーザ会クラブハウスがネット上でオープンしたのが2010年5月なのでそれよりも前だ．ユーザ会自身は2007年11月に発足している．ライセンスキーは分かった．

LICENSENO 2010021318        // ライセンス番号 AVWIWCB-RKZCKBJ 一般公開

一般公開という注記があるのにソースのバックアップがないというのは問題だがともかくライセンスキーが分かったので継続使用していただくことはできるだろう．Hishitani氏のメールには「先日パソコンが破損してしまい」とあるので，新規購入されたPCはWindows 10 の最新版と考えて間違いないと思われる．つまり，ある時期より古いバージョンのインストーラは問題なく動作していると考えてよいのではないだろうか？それも，開発用の実機で試してみれば分かることだ．

と言っても現物がないので，その近辺のバージョンで試してみる．2010年5月4日正式リリース版62版クラブハウス仮オープン：ゼルコバ通信No.9というのがあるので試してみよう．2010050406 URFKIY というパッケージだ．ダメだ．やはりOCXの登録で失敗する．インストーラはすでに自己解凍書庫のEXEではなくmsiに変わっているが，アイコンは昔ながらの切り株アイコンが使われている．この時期にはmsi単独ではなくZIPで配布しているが，これはシステムに常備されていないMSCOMCT2.OCXなどが使われていたためではないかと思われる．

ZIPを展開してからインストールしてみたが，結果は同じだ．このパッケージにはライセンス版とビューア用の2つのZIPが入っているようだが，なぜこれらが分離しているかの理由もよくわからない．ともかく，少なくともこの版は開発用実機にはインストールできないようだ．いや，ちょっと勘違いしていた．hisitani氏はVer.1.9.4.20 2010-02-14 ライセンスコード AVWIWCB としているが，AVWIWCB はライセンスコードではなく，ライセンスキーだ．これに合致するのは2010021317 KGZIZNL AVWIWCB だ．しかし，結果は同じOCX登録エラーになる．

Hishitani氏はパソコンが故障したあと，再インストールしているものと思われるが，インストールに成功しているとしたらその機種とOSのバージョンをお尋ねしなくてはならない．いや，それにしても少しおかしい．AVWIWCB というコードをライセンスコードとして持つ版とライセンスキーとして持つ版があるというのはかなりおかしい．ライセンスコードとライセンスキーは自動生成されているはずだが，同じ値を持つという可能性はゼロではないかもしれない… これは調べてみなければ分からない…

システムリカバリーは完了したが，パスワードが通らない状態には変化がない．ただし，パスワードのヒントとして「会いたいね」という文言が表示されている．誰に会いたいと言っているのだろう？このディスクを作ったのは2012年の8月だ．

それなら見当は付くが，それと頭文字3文字が結びつかない．頭文字だけで推測できると思ったのだからそれほど難しい単語ではないはずだ．わたしの貧弱なボキャブラリの中から該当するものを見つけるのはさほど難しくないはずだが，どうしても浮かんでこない．パスワードの頭文字を明かすとRGLだ．誰かこれを解ける人がいるだろうか？3 語で意味のあるフレーズになっているはずなのだが…

工場出荷状態に戻すしかないのだろうか？lenovo のリカバリがどういう仕様になっていたのかよく覚えていないが，Cドライブごとフォーマットするようになっていた可能性もある．データがすべて消えてしまったとしても，Windows 7 搭載機をテスト用マシンとして確保することは意味がある．工場出荷状態まで戻せばパスワードはリセットされるものと考えているが，確かだろうか？

今日の訪問者数はまた41になっている．昨日は16人．この波はなんだろう？工場出荷リカバリを実行した．中身は完全に空っぽになっている．USBでパスワードリセットディスクも作っておいたが，もう一つのリカバリでこれを使っても多分リセットはできないと思う．というのは，リセットディスクを生成した時点のパスワードと照合するような仕掛けになっていると思われるからだ．ともかくこれでlenovoにログインできるようになったので，参照用マシンとして使えるだろう．

午前８時起床，晴れ．朝食は焼きうどん．昨日はamory氏に返信を書くだけで終わってしまった．昨日の訪問者数15，今日の訪問者数は13だ．おそらくこれが実数だろう．残りの30は作業開始を見届けてどこかに散ってしまった模様だ．さて，どうやって復旧すればよいのだろう？ともかく，現状どうなっているのかを確認しておこう．

1. 旧バージョンがインストールできない．amory氏から V2.0.1.870 がインストールできないというレポートが送られてきた．OCXの登録に失敗している．開発用マシンでも同じ現象が起きる．
2. 開発環境 Visual Studio 2017 を立ち上げてソリューションを読み込むことはできる．
3. 最終版：2019/03/10をデバッグモードでビルドしてエラーになる．VBで未定義シンボルが発生している．ZelkovaBetaという名前空間はインポートされている．
4. Visual Studio 2015 はインストールされているはずだが，IDE 本体が見つからない．コマンドプロンプトしかメニューに出てこない．
5. 安定版V2.0.2.143 R2018-08-18をインストールしてOCX登録失敗になる．
6. ZelkovaTreeSetup.2.0.2.261.msi はインストールできた．このインストーラはD:\ZELKOVA_2019\ZELKOVA\SetupBeta\Releaseに入っている．N一族2.zelを開いてエラーメッセージが出るが，ファイルは開ける．このファイルの日付は2019/01/09だ．
7. 開発用ドライブDには以下の3つのフォルダがある，ZELKOVA_2018, ZELKOVA_2019, ZELKOVA_2020. ZELKOVA_2019には上記のパッケージしか入っていない．
8. ZELKOVA_2018に入っているのは2018年12月までの日付のファイルだが，この中で最新のZELKOVA_2018-12-25に入っているZelkovaTreeSetup.2.0.2.257.msiはOCX登録失敗でインストールできなかった．
9. インストールに成功した2.0.2.261は安定版には入っていない．公式リリースの最新版は2018071321-SXATQFMでここにはZelkovaTreeSetup.2.0.2.088.msiが入っている．これを起動しようとするとカスペルスキーにブロックされる．ブロック解除してもOCX登録失敗でインストールできない．

OCXを登録できないという事象は開発中にもたまたま起こることがあるが，安定版は通常インストール動作確認済のはずなのでここまで広範に障害が発生するとすれば，何らかの問題があると考えざるを得ない．インストールに成功した版はやや記憶は不確かだが，VS2015でビルドした最終版ではなかったかと思う．その後はすべてVS2017でビルドしているものと思われる．

ZELKOVA_2020は確かにVS2017でビルドしたものだが，ログにはターゲットがX64と書いてある．ZELKOVA_2018はVS2015でビルドしたものが入っているが，インストール失敗はここでも起きている．ZELKOVA_2019に1本だけ取り分けているのは何か理由があったのだろうか？

2018/12/28のログにはVS2015から2017に移行して232個のエラーが発生したとある．VS2017でZELKOVA_2018-12-25（のコピー）を開こうとしたら，下記のようなパネルが出た．これはどういうことだろう？

もともとこのフォルダはVS2017で作成したものであるはずなのだが…いや，違うかな？2018とあるのだから，明らかにVS2015のプロジェクトだ．2018/12/29のログには，VS2017でビルドしたX64バージョンという表現が使われているが，現行の設定はAny CPUとなっていて構成マネージャにはX64という字句は出てこない．これは多分VS2015でも変わらないと思う．

VS2015とVS2017のもっとも大きな相違点は後者が無償だという点だ．ただし，これを手に入れるためにはマイクロソフトアカウントを登録しておく必要がある．Windowsにログインするためには必ずしもマイクロソフトアカウントは必要ないが，インストーラを作るときなどに暗黙にマイクロソフトアカウントがチェックされている可能性はあるのではないだろうか？

認証方式を切り替えたり，一時的にマイクロソフトアカウントが停止状態になっていたことなどもあるので，その辺りが不安定動作の原因になっている可能性もある．一度VS2017を落として再インストールしたら何か変化があるかもしれない．もし，これでうまくゆかなかったとしたら，何か別の外部要因を考えなくてはならなくなる．