32 ビット ライブラリと C++/.NET ラッパーを 64 ビット (C++ の場合) と AnyCpu (.NET の場合) に移植することを可能にするために、2 週間ほどあらゆる種類のソリューションを探して試しています。
がある：
- さらに「The Brain」と呼ばれる C スタイルのインターフェースを公開する C++ ライブラリ (これは、私たち全員がそれを呼ぶ方法です)
- The Base を使用する 2 番目の C++ ライブラリ (DDC) は、非常に優れたインターフェイスをパックするという点で、そのラッパーのようなものです。
- The Base を使用し、C# および VB のラッパーのように機能する .NET ライブラリ (DDN)
- JAVA ライブラリ (DDJ) [重要ではありません。これを処理するための別の開発があります]
- PYTHON ライブラリ (DDP) [どちらも重要ではない]
ライブラリは巨大で、何千もの構造と関数 (データベースやさまざまなイーサネット デバイスとのインターフェイス) が存在します。コードに保持されている理由がわからない機能がたくさんありますが、要件は要件であり、従わなければなりません...
ドライバーとデータベース コネクタ全体が 32 ビット構成のみでした。内部に関連するドキュメントはなく、多くのコードを変更する必要がありました (書き直しやリファクタリングではなく、変更されました)。
すべての構造は 4 バイトに整列され、.net と C API の間のマーシャリングは 32 ビットで問題なく動作します。
新しい要件は、VB/C# アプリケーションが実行されるシステムに応じて、64 ビットまたは 32 ビット Base を使用する AnyCPU .NET 構成を作成することです。
これまでのところ、DDC は The Base とうまく連携します。しかし、DDN に関しては、多くの s### が発生しています。ベースでマーシャリングおよびアンマーシャリングされる構造には、4 バイトのパックがあります...したがって、ベース構造の配置はに切り替えられました。 32 ビットと 64 ビットの両方で 4 バイト (それぞれ 4 バイトは 8 バイトでした)。
私の当初の計画では、32 ビット構成と 64 ビット構成のそれぞれに 4 バイトと 8 バイトを配置する予定でしたが、Base C ラッパーとインターフェイスする .NET API には多くの作業が必要です... 呼び出しとコールバックは分離されていますそれぞれがそれぞれのライブラリを含む異なる名前空間内にありますが、構造は面倒です...
2 番目の計画は、すべてを 4 または 8 に揃えることでしたが、構造体と単項演算子のパッキングに関する多くの警告があります...それらの警告以外に、何もうまくいきません。ヒープの破損、シャットダウンのクラッシュなど.
3 番目の解決策は、解決策 1 に戻り、両方の名前空間 (32 ビット ベース ライブラリとやり取りする名前空間と 64 ビット ベース ライブラリとやり取りする名前空間) で適切なパックを使用して構造を作成することです。
フィードバックをいただければ幸いです。ご不明な点がございましたら、お気軽にお問い合わせください。
皆さん、ありがとうございました！