以前のポストでは、現在、4 種類用意されている AutoCAD API の概要をご紹介しました。今回は、AutoLISP、COM、ObjectARX、.NET API を使って作成したアドオン アプリケーションの移植性についてご紹介しましょう。
AutoCAD に限らず、最近のオートデスクのデスクトップ製品は、1 年に 1 回、新バージョンをリリースする製品サイクルを採用しています。もし、過去のバージョンの AutoCAD と API でアドオン アプリケーションを開発して運用している場合には、そのアドオン アプリケーションが新しいバージョンの AutoCAD でも動作するのか、事前にチェックしておく必要があります。場合によっては、新バージョンで動作させるための移植作業が必要になるものがあるためです。
それでは、まず最初に基本的な製品のリリース サイクルについて理解していただきましょう。AutoCAD 2002 以前の AutoCAD は、採用する DWG/DXF ファイル形式とアドオン アプリケーションの互換性が、バージョン毎に異なっていました。
DWG ファイル形式の場合は、どのバージョンでも旧バージョンの AutoCAD とデータ交換できるよう、旧バージョンの形式で保存することができるので、大きな問題にはなりませんでした。アドオン アプリケーションの場合には、少し事情が異なります。製品の機能とともに API も大きく変わってしまうため、バージョンごと移植作業を行なわなければいけなかったのです。ただし、AutoCAD 2002 以前のリリース サイクルが 2 年から 2.5 年あったため、頻繁に移植作業が発生するというわけではありませんでした。ところが、AutoCAD 2004 以降になって、サブスクリプション特典の導入によって、リリース サイクルが 1 年に 1 度 リリースに変更され、新しい製品が手元に届くようになると、移植をある程度意識する必要がでてきたのです。
そこでオートデスクは、DWG ファイル形式の流通と開発者の負担を低減することを目的に、AutoCAD の DWG ファイル形式とアドオン アプリケーションの互換性を、3 年に 1 度変更する方向性を打ち出してました。このため、コンパイルを必要とする .NET API や ObjectARX を利用したアプリケーションであっても、再コンパイルなしに .dll ファイルや .arx ファイルのまま、新しいバージョンで動作させることができるようになっています。逆に言えば、本格的な移植作業は、基本的に 3 年に 1 度実施すればいい、ということになります。ただし、アドオン アプリケーションが、AutoCAD の新バージョンが持つ新機能を追加実装しないことが前提になりますので、注意してください。
基本的な移植のサイクルを意識していただいた上で、移植の際に重要になる「移植の壁」をご紹介しましょう。
まず、最も面倒な UNICODE です。AutoCAD 2007 から導入された UNICODE という文字コード体系は、コンパイルを必要とする ObjectARX 製アドオン アプリケーションに影響を与えます。AutoCAD 2006 以前の AutoCAD では、AutoCAD のユーザ インタフェースに表示する日本語文字や、図面に作図される日本語文字の内部表現に、Shift_JIS コードを利用してきました。Shift_JIS は日本の仕様であるので、日本語を記入した DWG 図面を中国や韓国に持ち出して、現地の言語の AutoCAD で開いて編集すると、いわゆる「文字化け」が発生してしまいます。この問題を解決するために、採用されたのが UNICODE です。UNICODE によって、どの国に DWG 図面を持ち込んで現地で編集しても日本語が文字化けしない利点を得ることができるようになりした。
その反面、日本語を扱う AutoCAD 2006 以前の ObjectARX アドオン アプリケーションは、最新のバージョンで動作させるために、Shift_JIS の日本語の文字入力や操作、表示といったプログラム部分を、UNICODE 操作の処理に変更する必要がでてきています。
AutoCAD バージョン以外にも、移植作業に影響を与える問題があります。Windows プラットフォームの違いです。従来 32 ビット版が中心だった Windows OS は、最近のハードウェア（プロセッサ）の 64 ビット化に伴って、64 ビット化しているかと思います。AutoCAD も、AutoCAD 2008 からパッケージ内に 32 ビット版の AutoCAD と 64 ビット版の AutoCAD を同梱されるようになっています。インストール時には、インストーラが使っている Windows OS がどちらのビット数かを検出して、自動的に同じビット数版の製品をインストールするようになっています。
そして、AutoCAD に合わせて、ObjectARX 製のアドオン アプリケーションは、AutoCAD のビット数に合わせて生成する必要があります。
もう 1 点、現在では既に意識する必要もなくなってきているかと思いますが、AutoCAD R14 以前のアドオン アプリケーションは、AutoCAD ウィンドウ内に複数の図面子ウィンドウを表示できるようになった MDI (Multi Document Interface) に対応する必要もあります。AutoCAD R14 までは、AutoCAD ウィンドウに1つの図面しか表示することができない SDI (Single Document Interface) を採用していました。アドオン アプリケーションの移植作業も発生するのですが、おおよそ15年前の変更になるので、この記事では MDI 対応についての紹介は省くことにします。
まとめると、過去バージョンから利用しているアドオン アプリケーションには、いくつかの移植の壁が存在することが理解いただけたかと思います。
詳細までは紹介できませんが、ここで説明した代表的な移植の壁に対して、最新の AutoCAD 2013 に移植することを前提に、API 別にどの程度の移植作業が発生するかを見ていきます。
AutoLISP
AutoLISP は AutoCAD の一機能として提供されているため、AutoLISP のプログラム自体をUNICODE 対応する必要なく、そのまま動作させることができます。また、64 ビット版のAutoCADであっても、同様にそのまま動作します。つまり、UNICODE 化と 64 ビット化は意識する必要はありません。
ただし、移植元の AutoCAD バージョンによっては、AutoCAD 2013 でコマンド オプションが増減していたり、コマンドやシステム変数そのものが削除されているものもありますので、それらにアクセスしている場合には、プログラムの変更が必要になるものあります。また、(vl-XXXX) といった関数を用いていて、Visual LISP 環境でコンパイルした .vlx ファイルや .fas ファイルをお持ちの場合は、AutoCAD の COM(ActiveX オートメーション) のタイプライブラリが変更されていますので、.lsp から再コンパイルすることをお勧めします。
コマンドやシステム変数と同様に、新バージョンに加わった DXF グループコードに対応する必要もあります。たとえば、
AutoLISPプログラムを TrueColor対応 にするには？
で紹介しているような内容です。
AutoLISP の特性であるインタプリタ実行環境を生かして、とりあえず、新しいバージョンの AutoCAD にロードして実行してみるのも手段です。
COM(ActiveX オートメーション)
バージョン毎によってタイプ ライブラリが異なりますので、原則、新しいタイプ ライブラリを参照することが必要です。ただし、前述のとおり 3 バージョン範囲内であれば、そのまま動作します。もちろん、新機能に準ずるオブジェクトにアクセスする場合には、その環境でプログラムを変更する必要はあります。
で紹介しているような内容も存在します。まずは、AutoLISP と同様に、 新しいバージョンの AutoCAD で実行してみることをお勧めします。
なお、AutoCAD 2009 以前で VBA プロジェクトを利用していた方は、AutoCAD 2010 以降の VBA 環境に注意してください。VBA コンポーネントは、AutoCAD 2010 から インストールメディア(DVD-ROM) には含まれず、http://www.autodesk.com/vba-download からのダウンロード提供に切り替わっています。これは、Microsoft 社が提供する VBA コンポーネントが、32 ビット版でしか用意されていないためです。
64 ビット版 Windows 上で動作する 64 ビット版 AutoCAD で、32 ビット版 VBA を動作させるには、プログラムの実行時に AutoCAD と VBA の内部的な通信が発生します。32 ビット版 Windows 上で動作する 32 ビット版 AutoCAD の場合には、同じ 32 ビット版 VBA は AutoCAD と同じメモリ空間で動作することが出来るので、この通信が発生しないのです。この結果、 64 ビット版 AutoCAD で VBA を実行すると、パフォーマンスが低下したり、一部の VBA プログラムの互換性が崩れることになってしまいました。
現在では、オートデスクは VBA プロジェクトのプログラムを、同じ Visual Basic 言語を利用できるAutoCAD .NET API に移植していただくことを推奨しています。詳細は、
VBA プログラムの .NET API への移行方法について
をご覧ください。
ObjectARX
ObjectARX アプリケーションは、コンパイルされたバイナリ（.arx ファイル、.dbx ファイル）であっても、3世代間であれば、そのままロードして実行することができます。ただし、3世代間をまたいで移植する場合や、移植の壁にあたってしまった場合には、特に大きな移植作業が発生します。正直に言えば、AutoCAD API 上、最も強力な API である ObjectARX は、MDI 対応、UNICODE 対応、64 ビット プラットフォームに最も影響を受ける API です。
移植の際には、http://www.autodesk.com/objectarx から AutoCAD 2013 用の ObjectARX SDK をダウンロードして、 ObjectARX アプリケーションの Visual Studio 2010(SP1) でプロジェクトで参照するように変更します。また、プロジェクト設定の変更で最も重要なのは、「マルチバイト文字セットを使用する」から「Unicode 文字セットを使用する」に変更することです。
加えて、ソースコード内の文字列処理は、すべて UNICODE 対応が必要です。たとえば、strcpy() 関数は_tcscpy() 関数に、strcmpi() 関数は_tcsicmp() 関数に置き換える必要があります。また、acutPrintf() 関数でメッセージを表示しているような場面では、acutPrintf("Hello World"); のような記述を acutPrintf(_T("Hello World")); にすることになります。つまり、移植作業の多くは、関数の置き換えや文字列指定の書き換えに費やされることになってしまいます。このため、対象になる関数や文字列処理を見つけて、置換したり、操作内容を警告する Visual Teefy というツールが用意されています。Visual Studio 2010 用の Visual Teefy は、ブログ記事 http://adndevblog.typepad.com/autocad/2012/04/migrating-objectarx-and-net-plug-ins-to-autocad-2013.html の ObjectARX Migration に、動画とともに Visual Teefy のインストーラを含む VisualTeefy for 2010 Multilang EULA.zip として提供されています。
ObjectARX アプリケーションは、32 ビット版の AutoCAD 用と、64 ビット版の AutoCAD 用に生成するバイナリ（.arx、.dbx）を作り分けます。簡単に言えば、32 ビット版の ObjectARX アドオン アプリケーションは、64 ビット版の AutoCAD にロードすることが出来ません。その逆も然りです。プログラム内で扱うポインタ長などが異なることが理由です。実際にコンパイルやリンクをする際には、ObjectARX SDK 内に用意された 32 ビット用、64 ビット用のヘッダー ファイル、ライブラリ ファイルをプラットフォーム毎に参照し直す必要があります。
.NET API
.NET API の Visual Studio プロジェクトで最初に行う必要があるのは、AutoCAD 2013 に合わせたアセンブリの参照設定です。AutoCAD 2013 では、最低でも acmdg.dll、acdbmgd.dll、accoremgd.dll の3つのアセンブリ参照が必要です。
.NET Framework を利用する AutoCAD .NET API では、登場時から文字列操作を UNICODE で処理するようになっているので、プロジェクト設定では、UNICODE 以外の選択肢はありません（UNCODE と意識する設定がありません）。
また、コンパイルされて生成されるアセンブリ ファイル（.dll）は、ObjectARXのような純粋なバイナリではなく、中間言語で構成されています。中間言語で構成された .dll ファイルは、AutoCAD にロードされて最初に実行されるタイミングで、プラットフォームにあわせてバイナリにコンパイルされることになります（実行時コンパイル）。
つまり、UNICODE 対応、プラットフォーム対応を意識する必要はありません。
ここまで読んでいただくと、少々ぐったりかもしれません。結論を急ぎましょう。現時点での移植作業負荷は、おおよそ次のような傾向となるはずです。今後の移植作業の目安や、新しく API カスタマイズをする場合にはこの移植性を考慮して取り組んでいただいたほうが後々楽になります。「プログラム資産」という言葉があるように、時間とコストを費やして開発したプログラムを、簡単に切り捨てられるものではないはずです。
By Toshiaki Isezaki
Subscribe
コメント