Visual Studio 2022でのトラブル対応
私の場合には、ということだけれども、今回 Visual Studio 2017で何の問題もなくコンパイルし、走っていたプログラムを、Visual Studio 2022でコンパイルするために、
stdAfx.h
に、以下のパッチを当てた。なぜ？というお話。
#define USING_V110_SDK71
// 2023/09/17: コンパイルエラー回避
#define E_BOUNDS 0x8000000Bまず直面したのは、
E0020 識別子 "CMFCOutlookBarTabCtrl" が定義されていません
というエラー。何じゃこりゃ？
私がこのプロジェクトのソースコードに触れたのは、2017年からだけれども、実はそれ以前、遅くとも2013年までにはNC工作機との接続に使われていたプログラムが、Windows XPで走らなくなったので、何とかして欲しい、という流れで私のところに来た。原型は、10年以上前に作られたと思う。
Wrapperを被せて動くようにした時のプラットフォームが Visual Studio 2017で、MFCを使ったVisual C++のプログラムだった。
この識別子自体に、そもそも見覚えがない。のも無理はなく、このクラス定義を参照しているのはAfxOutlookBar.h というヘッダーファイルで、どこかのモジュールがincludeしていたんだろうと思った。ところが、コードから辿っていっても、原因箇所が特定できない。結局4〜5時間検索しまくった挙句に、この方のサイトに辿り着いた。
https://blog.kintarou.com/2016/04/10/vc2013_directshow_update/
ならばと「#define USING_V110_SDK71」を「stdafx.h」で記述すると無事ビルド完了した。
これを試したら、とにかく私も、このエラーは解消。
正攻法としては、プラットフォームツールセットの設定値を変える、というのがあるらしいのだけれども、コード自体が読んでみると16ビットCPUの時代の残骸としか思えない部分を含んでいる。理由は単純で、NC工作機との通信は RS-232Cだけれども、そのRS-232C関連のプログラムを「パッチ」や「ラッパー」ではなく書き直す手段が、見つからなかったため。もはや、サポートされていない技術、ということになるのかも知れない。接続先が1990年代以前の工作機だから（営業さんに連れられて、あちこちの町工場を訪ねてみると、驚くほど、あちこちの工場で、この古いPCが現在も現役で仕事をしていて）RS-232CはあくまでもRS-232Cとしてプログラムするしかない。
RTSの信号を「0」に落とす、そのRTSなんていう概念が、最新のシリアル通信では見つからない。
バブルで取り残され、安倍元総理の「シャンパンタワー」でも上の方で消えてしまって部品工場までは「救済」が及ばず、1980年代、1990年代の日本製は堅牢だったというその事実のみに支えられている「町工場」が、日本の工業技術の底辺を支えている、ということなんだろうな。日本もいつまで持ち堪えるか、なんとも言えないけれども、その辺の話題は私の領分じゃない。再任した麻生さんあたりに任せるしかないんだろうか、とも思うけれど。話が逸れた。
いかんせん、1980年代からプログラムを書いているシーラカンスみたいなプログラマですから、ネットで検索して出てこなくても、RS-232C関連ならある程度、コードを見れば対応策もわかるのだけれど、それをどう「新しくするか」の選択肢がなく、パッチで対応するしかないんだろうな、と思いつつ、このエラーが解消したら、次のエラーがでた。
次は、これ。
エラー C2065 'E_BOUNDS': 定義されていない識別子です。
C:¥Program Files¥Microsoft Visual Studio¥2022¥Community¥VC¥Tools¥MSVC¥14.35.32215¥atlmfc¥include¥atlsimpcoll.h
Visual Studio Installerで、素直に、MFC関連を追加しただけでVisual Studio 2022をインストールした。そうしたら、まず、stdio.hが見つからないという冗談みたいなエラーが出た。
これは割とすぐに解決。stdio.hがあるincludeファイルのパスを、「外部include」として追加した。（何で、stdio.hが「外部」なのか、Microsoftの設計思想がよくわからんけれど。）
ところが、stdio.hのエラーが解決したら、今度は、Afx関連のエラーが大量に発生。インストール先の（と思われる）
C:¥Program Files¥Microsoft Visual Studio¥2022¥Community¥VC¥Tools¥MSVC¥14.35.32215
の中のincludeには、Afxで始まるファイルがない！なぜなんだ・・・？
Installerの操作で、上記の
E0020 識別子 "CMFCOutlookBarTabCtrl" が定義されていません
に対応するために、何度となくツールセットのバージョンを変えてインストールし直し、その都度モジュールの「削除」と「追加」が繰り返されて、そのどさくさで、Afx関連が消されてしまった？まさか？
この試行錯誤で数時間浪費。諦めた。そもそも、最終的には「同じライブラリ」がリンクされるはずだ。だとしたら、古いAfxでも動くはずだ、と推測した。Visual Studio 2017の環境で読んでいたAfxで始まるヘッダファイルを、まるごと、コンパイル時のinclude先にコピーした。（Afx*.h）
include として2017のincludeフォルダをまるごと指定するのは、怖くて出来なかった。Afx以外で、ライブラリとのハンドシェークが更新されていたとしたら、ヘッダの中身も新しくなっているかも知れない。常識的に考えれば、include全体の読み込み先は増やすべきじゃない。最悪の場合の被害を最小に留めるとしたら、Afxで始まるヘッダファイル群を丸ごと持ってくるしかない。そう結論した。
で、それをやった。
もしかしたら、だけれども、その「影響」で、このE_BOUNDSが定義されていない、というエラーが出たんだろうか。
本来、「新しいAfxのinclude」が読み込めていたなら、このエラーは出なかった可能性が大きい。ただ、他に迂回策がなかった。必要最小限のパッチで動かすにはどうしたらいいか、E_BOUNDSの値が0x8000000Bであることを検索して調べて、
#define E_BOUNDS 0x8000000Bを追加した。結果として、このエラーが解消した。
ぶっちゃけ、C言語の「文字列」は、Nullで終端しないと「境界エラー」を起こす、なんてのは、シーラカンスにとっては常識中の常識で、そんなトラップは片っ端から入れてある。私のプログラムは、C言語の文字列の「境界エラー」は絶対に起こさない。ということは、このE_BOUNDSのコードを呼び出しているシステムエラー関連のモジュールには出番がないはず、だから、ここはこのパッチで、コンパイラさえ黙らせれば問題ないはずだ、と考えた。
大丈夫だろうか、とヒヤヒヤしていたけれど、移動するのに片道5時間はかかる客先で、工場設備と、NCプログラム送信用の「最新版Windows PC」との接続テスト、「無事、すべてがうまく動作しました」と、さっき営業さんから連絡をもらった。
（なんだ、あんたは同行しなかったのか？と言われそうだけれど、設備更新は二日がかりで、宿泊を伴っての出張だとしたら、悪いんだけれども、旅費もプログラム開発費に上乗せしますから、という条件を出したら「来なくていい」ということになったので・・・）
バグさえ出さなきゃ、別に私が行かなくても、私が書いたプログラムは仕事をしてくれる「はず」。（この「はず」というのが、とにかく怖い。原子力関係の学者みたいに「想定外のことは起きません！」なんて言って、済ましてられりゃ気が楽だけれど、何か起きちゃったら、「お前、こんなことも想定していなかったのか！」と大目玉をくらいそうだし・・・（またしても話が逸れた。）
でも、「全部無事動作した。」よかった〜〜。結果オーライ。
それにしても、このVisual Studio 2022の出してくるエラーが、とにかくひどい。全部、クライアントのプログラムのせいにしているけれど、悪いのはインストーラじゃないのか？と私は思う。
やったこと、と言えば、Afx*.h のファイルをコピーしたことと、StdAfx.hに冒頭の2行を追加したこと、だけだった。
副作用はないのか？と思っていたら、実はあった。
リソースビューで、GUI機能を使ってWindowsのレイアウトを編集すると、なぜかわからないけれど、拡張子RCのファイルの DIALOGEXの窓サイズが、なぜか 3/4になる、という摩訶不思議な現象に遭遇。最初は焦った。
ポップアップのダイアログが、千切れて、小さくなっている。
編集前のR（Resource Config?）Cと、ファイル比較で確認したら、リソースビューのGUIで編集したDialog窓だけ、窓のサイズが3/4になっていたので、RCのファイルを直接編集して、元の大きさに戻した。めでたしめでたし、って、ソースを編集しなければ正常動作しないなら、ビューアーの意味がないと思う。これって、Afx*.hをコピーした副作用かなぁ・・・。ただ、なぜか、どこにもAfx*.hが存在しない、なんていう事態がなぜ起きたのか、その理由をMicrosoftには説明してもらいたい気がする。
あたしゃ、シーラカンスですから、いざとなったら直接ソースコードを編集する。GUIにはあまり頼っていない。こういうことが起きる、ということだけわかっていれば、これでも使えるだろうと思った。もう、これでいい。これ以上、Visual Studioの設定は、触りたくない。何が起きるかわからん。
で、結局、客先の事情に合わせてDialog窓をカスタマイズするだけの作業だったのだけれど、Visual Studio 2017の走っているWindows 10が、もう空き容量12GBと、瀕死の状態で（いかんせん、客先から問い合わせがあったらすぐに動作確認できないとまずいから、エミュレータまで含めてそのまま動作するようにしておくためには、迂闊にファイルを消せないため）開発マシンを新しくするしかなかった。少しずつ引っ越し。
PostgreSQLと、Oracleと、SQL Serverと、全部インストールしてあって、テストのためにこのうち二つのサービスを開始すると、普通なら20~30秒で終わるコンパイル、リンクが1時間近くかかる。ハードディスクが動きっぱなし。さすがに、開発機を新しくするしかなかった。使ってる人間がシーラカンスなら、開発機も、もはや漬物石みたいになっていた。重たいだけ。と、また話が逸れている。
結局、Dialogを編集するだけで、取説の更新まで含めても4〜5時間で終わるはずの作業に、原因究明まで含めると30時間以上かかってしまった。連休はこれでツブれた。
そう言えば、以前Windows Serverで仕事をした時も、得体の知れない動作に遭遇して、2〜3ヶ月、睡眠時間が平均で2〜3時間という事態に遭遇したことがあったっけ。一年前だったか。（それで、一気に聴覚障害が悪化した。）
これがあるから、Windowsではあまり仕事をしたくないんだ。
今でこそ開発環境は無償でダウンロードできるけれど、以前は、APIのレファレンスの出版物だけで10〜20万円近く、まともに開発環境を整えようとすると、ソフトウェア関連だけで30〜40万円近くかかった。アプリばかりではなく、開発者からも金を搾り取ろうとするのがMicrosoftじゃないか、と、これが私がMicrosoftを嫌いになった最大の理由だった。
今回のVisual Studio Installerの件は、明らかにInstallerのバグだと思う。
バグ、というよりも、レガシー環境から引き継いでいるモジュールの相互関係や、バージョン間の互換性の問題などを、もはや、Microsoft自身が把握しきれていないことが最大の原因じゃないか、という気がする。あれもこれも、詰め込みすぎた結果だと思う。
と思っていたら、さらに詰め込むようなニュースが流れた。
https://xtech.nikkei.com/atcl/nxt/news/18/15964/
Microsoftが生成AI機能「Copilot」を統合、Windows 11アップデートで提供開始
https://xtech.nikkei.com/atcl/nxt/news/18/15964/
これ、私は、Microsoftの自殺行為だという気がする。Windows 11だけならいい。様々なレガシーとの互換性、上位互換性など、おそらくVisual studio Installerの比ではないバージョン間の矛盾、コンポーネント感の不整合などが表面化すると思う。
それらの問題に対処する「時間」を、開発者が被りきれるか、と言えば、無理だと思う。
さすがに私も、今回は「想定外だった30時間」の、半分を開発費に上乗せさせてもらった。「開発環境の更新」だから、私が負担すべきコストかも知れないけれど、Microsoftのバグへの対応までは、負担する義務がない。「そんな余計なコストは、支払えない」ということならば、私に出来ること一つだけ。「新しいWindowsなどへの対応は、今後はお断りします。」それだけの話。今走ってるソフトは、まだ5年くらいは現状のままでも生き延びるんじゃないかと思うが、そこから先は知らない。
既に、なんだかもうゴチャゴチャになっているWindows向けアプリの開発環境が、今回の生成系AIの取り込みで、Microsoft自体が管理しきれないレベルに突入する気がする。開発者がその対応コストをエンドユーザに負担するように求めたら、Windowsを使うという選択肢そのものがハイコスト、ハイリスクの塊になりそうな気がする。
Microsoftは、この「何でもかんでも、Windowsに取り込む」という発想を、やめたらいいのに、と思う。昔、大型コンピュータでやっていたような「バッチジョブ方式」というか、コンポーネントの独立性を高めて、Widowsの内部構造を、切り離しやすく、組み合わせを変えやすい構造にしていくべきだと思う。ところが、現実には、コンポーネント間の相互依存性がかなり高い状態に拍車がかかっている。
Installerで素直にInstallした開発ツールでコンパイルすると、"Hello World!"がバグって動かない。これがMicrosoftの現状だと思う。
なんて話は、余計はことか。Microsoft関連製品にバグがあっても、開発がトラブった際には、エンドユーザにその開発費を負担してもらう、（開発者は、かぶらない）というのが常識化してくれたなら、私自身も別に、Windowsを使ってもいい。ただ、そうすると、前回なんか、数十万円で請け負ったシステムの開発費が5倍くらいになっただろうな、とも思うし、今回も、請求額は3倍に増やさせてもらった。体は壊れるし、連休はツブれるし、もう限界だとも思うし。
それを支払ってもらえないなら、今後はWindows アプリの更新作業は、一切引き受けません、と、そういうことになると思う。世間は、どうなんだろうかなぁ・・・世間には意外と忍耐強い人が、多そうだし。
この記事が気に入ったらサポートをしてみませんか？