Visual basic5.0への移植　〜その理想と現実〜

はじめに

　ご覧のとおり今回の特集は「Visual Basic(以降VB)トラブル処方箋」です．なんだか消毒液のにおいとあの待合い室独特の喧噪が聞こえてきそうですね．筆者自身は大の“注射嫌い”ですから，めったなことでは病院には近づかないようにしているのですが，本日は“VB移植科”の専任ドクターとして，最近巷で多発している16bit版VBから32bit版への“コンバート（移植）作業にまつわるエトセトラ”と“VB5へのお気楽コンバート”へのアプローチ法をご紹介しましょう．
　なお，この記事はVisual Basic2.0J（以降VB2J）からVisual Basic5.0（同VB5）への移植を想定して書いていますが，同じ16bit版VBであるVisual Basic3.0（同VB3）やVisual Basic4.0 16bit版（同VB4-16）から32bit版VBへのコンバートを考えている読者は，対応するVBに置き換えてお読みください（残念ながらVB1やVB for DOSは対象としていません）．

●　目指すは32bit

　今年の３月，まばゆいばかりのVB5のリリースを前にした明るい話題の陰で，一つのニュースが筆者の元にも届きました　−　「VB用カスタムコントロールの大手ベンダーがVBX製品の販売とサポートを終了すると発表」，栄華をきわめたWindows3.1（以降Win3.1）＋VB2J＋VBXの時代も盛者必衰の例外ではなくここに終焉を迎えたわけです（注１）．もちろん，今までどおりVB2J＋VBXでの開発を続けることができなくなったわけではありませんが，その製品とライセンスを手に入れることが原則的にできなくなったことは，開発チームの増員や（カスタマイズ用）ソースコード付きのVBアプリケーションの配布ができなくなる事を意味します．たしかにVB4-16は継続販売されていますが，VB5に16bit版が添付されなかったこともからも，新規アプリケーション開発を16bit版VBで行うことは無謀といってよいでしょう．
　今となっては，Windowsファミリーにおいての標準プラットフォームはWindows95（以降Win95）やWindowsNT4.0（以降WinNT4.0）などの32bit Operating System(OS)であることに疑いの余地はありません．これからの新規開発は，32bit版VBであるVB5（またはVB4-32）が唯一の選択肢なのです．さあ目指すは32bitです！（注２）

●　16bitからの自動コンバートは幻想

　VB2Jで作成したプログラムをVB5用にコンバートする機能は標準でサポートされており，その方法はいたって簡単です．VB5を起動し【既存のファイルを開く】ダイアログからコンバートするVB2のプロジェクトファイル(.mak)を開き，後は【すべてのファイルを変換する】ボタンを押して【DAOライブラリの追加の有無】の確認で“追加しない”を選べば，VB5形式のプロジェクトに自動にコンバートされるとともに，一部のVBXについては上位互換のOCXに自動で置き換えられます（注３・４）．あとはプロジェクトの保存時にプロジェクトファイルの拡張子をVB5の標準である“.vbp”に変更すれば，作業はすべて完了（注５）．
　試しにVB2Jに附属している電卓プログラム(calc.mak)をコンバートしてみましょう．何の問題もありません．しかし，いつもこんな簡単にコンバートできる保証はありません．むしろ自動コンバートできるような業務用カスタムアプリケーションは皆無といってよいかもしれません．このことは，マイクロソフト株式会社のホームーページのサポート技術で，「【VB5】以前のバージョンからの移植時の注意」として次のように書かれています．

　あなたのカスタムアプリケーションは自動コンバートできそうでしょうか？おそらく躊躇せずに手を挙げられる読者は少ないことでしょう．実際にVB2Jで開発された業務用アプリケーションでこれらの「注意事項」をクリアできるようなアプリケーションはほとんどないといえます．試しに市販されているVB2Jで開発されたパッケージアプリケーション(図1)を自動コンバートしてみましょう．(注7)
　すると今度は[カスタムコントロールのアップグレード]ダイアログが表示され，サードパーティ製のカスタムコントロールについては「アップグレードすることができない」とのメッセージが出力され，先ほどのコンバートと同じようには行きません．仮に警告メッセージを無視して自動コンバートを強行すれば，そのプログラムが正常に動作しないことはもちろん,設計した画面さえも崩れてしまうのです(図2)．
　このアプリケーションはそのコードにとりたてて高度な技術を使っているわけではなく,むしろ一般的なレベルのプログラムといえます．つまり，業務用カスタムアプリケーションをVB5に移植するためには自動コンバートだけでは足りないのです．

図１：一般的な業務用アプリケーションの例

図２：自動コンバートの失敗例

●　コンバート作業にまつわるエトセトラ

　16bit版のカスタムアプリケーションのVB5へのコンバートが自動コンバートのみでは足りず，追加コンバート作業が必要なことは先に述べたとおりです．これはVBに限ったことではありません．他の開発言語においても，その言語仕様がバージョンアップにより変更されれば，なんらかの追加コンバート作業が必要なものです．ただ，16bit版VBから32bit版VBへのコンバートにおいては“その注意事項”が“あまりに多く”そして“広範囲”ですから，結果としてそのための追加コンバート作業も多くなってしまうのです．
　「コンバート作業だから」というだけで安易に引かれたスケジュールが誤りであることは，作業を始めてみればすぐに明らかになります．筆者の周りでも，当初のスケジュール内でコンバート作業を完了できたプロジェクトはわずかでした．また，結局VB5で新規開発したときと同じ時間を要してしまうケースも珍しくはなく，実際にコンバートを断念し「新規開発（参考プログラムあり）」とVB5での新規開発に切り替えたケースも少なくありませんでした．
　では，何がコンバート作業を難しくしているのでしょうか？
　トラブルの事例（表2）を見てみれば，コンバートに必要な作業項目はそう多くはありません．

　筆者はコンバート作業のスケジュールを誤らせる原因の多くは，次の2つの誤解によるものが多いと考えています．

　VBXと同名のOCXでも互換性がないものは少なくありません．後述するvb.iniを利用した自動置き換えの機能を利用するためには，そのカスタムコントロール内のオブジェクトモデルとプロパティが同一でなければいけません．互換性がなければ，そのコントロールに対する操作のコードを変更することはもちろん，自動置き換えが使えず，フォーム上に手作業でコントロールを貼り直す作業が必要となり，互換性のあるコントロールに比べ多くの手間を要することは明らかです．もっとも，VBに依存しメソッドを持てない独自仕様のVBXと，OLEをベースに公開されたメソッドを持つオープンな仕様のOCXはまったくの“別物”なのですから，互換性がある方が不思議といえるのかもしれません．
　そして，もうひとつのUnicodeの問題ですが，これこそが，コンバート作業を泥沼にはめる大きな原因といえます．日本語のカスタムアプリケーションではそのほとんどが漢字を使いますから，このUnicodeの問題は深刻です．文字列の定義部はもちろん，ユーザー定義体やテキストボックスのMaxLength，さらには文字列操作時にも影響が出る可能性があります．しかし，プログラム中のどの文字列操作で問題が発生するかは，そのコードすべてをチェックしなければわかりません．さらに「原則的にVB内部はUnicode，外部はANSIコードとし，DLL呼び出し時やファイルへの読み書き時には強制的にコード変換される」という仕様が，事態をさらに混乱させています．
　先の“VBXとOCXの問題”や“16bitDLLやWin16APIの問題”などは，後で紹介するようないくつかのツールを使うことにより作業時間を大幅に軽減することもできるのですが，このUnicodeの問題だけは効果的な方法もみあたりません．本当に頭の痛い問題です．
　そうです，これらのことを考慮せずに，「コンバートだから新規作成の30％の時間でプログラムが書けるね」などと，根拠のない思い込みで引かれたスケジュールなど実現できるはずもないのです．
　また，直接VBとは関係がありませんが，大きなプロジェクトでのコンバート作業では，そのプロジェクト管理の能力も高いレベルで要求されます．大規模な修正を実施するためには，そのバージョンの不整合，修正手順のばらつき，などなど，プロジェクト全体をより深い暗闇に突き落とす要因はいくつもあります．
　なんだか暗い記事になってしまいました．こんな状況ではとても“お気楽コンバート”などはできそうにもありません．しかし，それでは面白くありませんから次の項では，少し明く“お気楽コンバート”へのアプローチ法について書くことにしましょう．

●　ツールを使って“お気楽コンバート

　筆者はコンバート作業があまり好きではありません．なぜなら，ただでさえ単調で興味の薄い作業でありながら，その繰り返しは集中力の低下を招き，さらに面倒な事態を引き起こすことがしばしばあるからです．となれば，単調な作業はコンピュータにやらせるに限ります．VB5の自動コンバート機能や上位互換OCXへの自動置き換え機能とまではいかなくても，ちょっとしたツールはその移行作業を楽にするだけでなくプログラムの品質をもあげてくれます．まずは，VB5のCD-ROMの中を覗いてみましょう．
　なお，これらのツールの利用は個人の責任にて行なってください．これらのツールを使用したことにより生じた損害の一切について筆者および編集部は責任を負いません．

●　VBXから上位互換OCXへの自動置き換え

　VB5自身が行なってくれるこの機能は，なかなか便利です．どうせならマイクロソフトのVBXだけでなく，サードパーティのVBXからの置き換えにも使いたいと思うのが人情です．ではこの機能はどのようにして実現されているのでしょうか？ Windowsフォルダの中にあるvb.iniなるファイルを開いてみれば，その仕組みは一目瞭然です．そのファイルの[VBX Conversions32]セクションのエントリに，VBX名と対応するOCXのクラスID，バージョン，所在が記述されているのです（リスト1）．

　もちろん，ここにエントリを追加すれば，サードパーティのVBXもマイクロソフトのVBXと同様に自動置き換えができるようになります（注8）．OCXのクラスIDやバージョンを調べるのは簡単です，VB5プロジェクトを新規に作成し，該当するOCXを[プロジェクト]-[コンポーネント]から追加した後にそのプロジェクトを保存してください．後は，その保存したプロジェクトファイルをメモ帳などのエディタで覗いてみれば，必要な情報はすべてそこにあります．

●　使用している16bitDLLおよびWin16APIコール箇所の洗い出し

　VB5では16bitDLLやWin16APIをコールすることはできません．これらは32bitDLLやWin32APIへの書き換えが必要になります．それらのDeclare文を探すことはそれほど問題もないのですが，コードの中から修正対象を見つける作業は厄介なものです．こんなときに便利なアップグレードウィザードが，VB5のCD-ROMの中に同梱されています．

“Tools\Unsupprt\Migrwiz\Cswiz.exe”

　このツールは，その名のとおり“サポート対象外”なのですが，なかなかよくできています．16bitDLL呼び出し行の洗い出しはもちろん，コンバート作業前に必要となる問題点レポートの出力や，修正すべきコードの自動生成など，使いやすいツールに仕上がっています．

図3：VB5に付属するアップグレードウィザード

　ご覧の通りPDQCommなどでおなじみのアメリカの会社の製品です．いかにも「急遽VB5に対応した」といわんばかりのタイトルはさて置き，このツールの実力は先に延べたとおりです．ただし日本語版VB5での動作は前提としていないでしょうから，日本語のファイル名やオブジェクト名を付けていると正常に動作しない可能性もありますが（筆者の環境では正常に動作しているようです），この会社のホームページにはこのプログラムの改訂版とそのソースコードがともに公開されていますので，いずれにせよ問題はないでしょう．

Crescent Division of Progress Software
http://www.progress.com/crescent

●　互換性がないOCXの貼り付けとプロパティの設定を自動で

　VB5が提供するOCXの自動置き換え機能は，互換性のあるOCXについてのみ利用できます．もちろん，互換性がないカスタムコントロールを置き換えてもうまく動く保証はありませんので，VB5の自動置き換え機能自体に問題があるわけではありません．しかし，ソースコードの変更は高機能なエディタなどで一括変更を行なえるなど，比較的短時間で作業を終えることができるのにくらべ，フォーム上にカスタムコントロールを貼り直して必要なプロパティを設定してゆく作業はなかなか大変な作業です．なんとかこの“貼り付け”の作業だけでも楽にこなす方法はないでしょうか?
　試しに互換性のないOCXを先のvb.iniに指定してみると，自動置き換えができるOCXもあります．場合によってはそのOCXの置き換え時や，カスタムコントロールが貼られているフォームを開く際にエラーが発生したり，いくつかの情報が失われることもありますが，いったん保存し直せば特に問題もないようです．エラーの原因はその.logを見ればわかるとおり，VBXにはあったプロパティがOCXでなくなっている場合に発生しています．また，このような場合にはアイコンイメージなどの.frxファイルにバイナリ形式で保持されていた情報も失われてしまうようです．
　フォームに貼り付けられたらしめたものです．後は失われたプロパティ情報や，非互換の部分のコードを修正すれば置き換え作業は完了となります．また，無理矢理貼り付けことが少し不安でもありますが，作業効率のUPには有効な手段のひとつといえます．

●　さらに互換性のないOCXを無理やり貼り付ける

　まったく別のOCXと置き換えようとしたり，また同名のOCXであるにもかかわらずそのカスタムコントロール内のオブジェクト構造に変更が加えられている場合には，前項の自動置き換えの最初の段階ですらエラーになり，そのフォームモジュール自体がプロジェクトから除外される場合があります．これはOCX内のカスタムコントロールのクラス名が変更されている場合に発生するようです．
　このケースはどのように対処すれば，“お気楽コンバート”が実現できるのでしょうか？
　方法はあります．フォームに貼り付けたカスタムコントロールの内容は一部のバイナリ情報を除き，プロジェクトファイルとフォームモジュールにテキスト形式で記述されていますから，それらの記述内容を直接編集することにより，フォームへのカスタムコントロールの貼り付けや，VBXからの一部のプロパティの引き継ぎが可能になります．
　では，実際にファイルの中身を覗いてみましょう（プロジェクトファイルとフォームモジュールをメモ帳で開ければその中身を見ることができます：図4）．

　VB2Jのプロジェクトファイルやフォームモジュールの内容はとても単純ですが，VB5の方は少し複雑で，とても直接編集するなどということは困難なように思えてきます．しかし，よい方法があります．VB4-16とVB4-32でも同じ構造のプロジェクトファイルとフォームモジュールを作ってみましょう（VB2Jで作成したものをVB4-16でコンバートすれば簡単です）．それぞれのファイルの内容を並べてみてみると，どこを直せばよいのかは自ずと解ってくると思います．
　後はその規則性にしたがい，エディタなどで一括変換すればでき上がりというわけです．
　もちろん，これはあくまで“カスタムコントロールの貼り付け”を一括で行なうためのツールですから，コードの中身は別途修正する必要があることはいうまでもありません．
　今回は紙面の都合もあり，各ツールや筆者が作成したツールについて詳細な説明をすることはできませんでしたが，またいずれ本誌またはPC Developer's Networkにてご紹介させて頂くことにします．どうぞお楽しみに．

●最後に

　これからも開発言語のバージョンアップがある限り，過去の資産のコンバート作業は避けては通れません．今回の記事では触れませんでしたが，コンバートをより“お気楽に実現する”には，必要なドキュメントに事前に目を通すことも必須といえます．VB5の場合ならば，マニュアルのWhat Newの項はもちろん，readme.hlpやvb5dll.txt，そしてマイクロソフトのホームページやMSDNにより公開されているFAQやKnowleage Base，PC Developer's Networkなどの団体のFAQやNews Groupのログに目を通しておくことも必須といえるかもしれません．やはり「敵を知り己を知れば百戦危うからず」なのです．
　また，丁寧につくられたプログラムは意外と簡単にコンバートできるものです．たとえば，変数の型定義はもちろん，その型変換を明示的に行なっているプログラムとVBのバリアント型や自動型変換機能を使っているプログラムとでは，そのコンバートのしやすさは大きく違います．さすがに変数の宣言を省略するプログラマはいないでしょうが，正しいコーディング，推奨されているコードィングを心がけ，実践していくことが，次回のコンバートの助けになることはいうまでもありません． なにごとも基本が大切なのです．

Copyright (c) 1998 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp