GPIB32 APIとNI4882 APIの相違点

Windows用NI-488.2バージョン2.6では、64ビットアプリケーションインタフェースの一部として新しいAPIが導入されました。この新しいNI4882 APIでは、既存のGPIB32 APIとの一致をできる限り維持しながら、最適なAPI設計が取り入れられています。新しいAPIを使用するには、新しいヘッダとオブジェクトファイルを使用してアプリケーションを再コンパイルする必要があります。NI4882 APIでの主な変更点は以下のとおりです。

• constキーワードが最適に適用されるようになりました。
• 関数のバリアントでunsigned shortタイプではなくwchar_tが使用されるようになりました。
• ポインタの長さを示すパラメータを取る関数で、size_tタイプが使用されるようになりました。
• ステータス変数でunsigned longタイプが使用されるようになりました。
• ThreadIbcntl()が削除されました。この関数の呼び出しはマクロによってThreadIbcnt()に変更されます。
• グローバルステータス関数Ibsta()、Iberr()、Ibcnt()が追加されました。新しいコードでは、ibsta、iberr、ibcnt/ibcntlの代わりにこれらの関数を使用してください。
• 長期廃止されていた関数が完全に削除されました。
• ibconfigを使用するほとんどの関数が削除されました。新しいコードではibconfigを使用してください。既存の関数の呼び出し先はマクロによってibconfigに変更されます。影響を受ける関数は以下のとおりです。
• ibpad
• ibsad
• ibtmo
• ibeot
• ibrsc
• ibsre
• ibeos
• ibdma
• ibist
• ibrsv
• 多くのマクロ定義は、プログラム上の安全性を高めるよう改善されました。

NI4882 APIは、既存のアプリケーションに最小限の作業量で適用できます。多くの場合、新しいインクルードファイル（windows.hおよびni488.hの代わりとなるni4882.h）を使用し、新しいオブジェクトファイル（gpib-32.objの代わりとなるni4882.obj）にリンクすれば、アプリケーションをコンパイルすることができます。ステータス変数タイプの符号付きプロパティの変更によって、警告が発生する可能性があります。

特定の特殊なケースでは、問題が生じる可能性もあります。これまでに、以下の問題が確認されています。

• ibnotifyコールバックへの関数ポインタが保存される。これにより、割り当て時にタイプの不一致が発生します。この問題は、コールバックの関数プロトタイプでステータスパラメータをunsigned longが使用されるよう修正することで解決できます。
• ibfindへの関数ポインタが使用される。ibfindマクロは1パラメータの引数を必要とするため、この問題によってプリプロセッサエラーが発生します。この問題は、アプリケーションのユニコード表記規則に応じてibfindAまたはibfindWにポイントすることで解決できます。
• 構成関数がNI Spyにibconfig呼び出しとして表示される。これはマクロがこれらの呼び出し先をibconfigに変更するためです。最初からibconfigを使用することで混乱を回避できます。

多くの場合、NI4882 APIで記述されたアプリケーションはWindows用NI-488.2ソフトウェアの旧バージョン（バージョン1.7以降）でも使用できます。特定の新しいibaskオプションとibconfigオプションを使用すると、後方互換性が損なわれる可能性がありますが、これらのオプションは別のオプションで代用可能です。既存のアプリケーションはGPIB32 APIを使用しても変更なく実行されます。GPIB32 APIは存続予定ですが、32ビットアプリケーション専用です。NI4882 APIで記述されたアプリケーションは、32ビットと64ビットの両方の環境でコンパイルできます。アプリケーションを64ビット環境で使用できるようにするには、NI4882 APIに移行してからコンパイルする必要があります。

以下のNI4882 APIの構成では、Windows用NI-488.2の旧バージョンとのAPIの互換性が損なわれます。

• ibask(IbaEOS)
• ibconfig (IbcEOS)