■Windows 3.0の日本語処理

★MS漢字API

MS漢字APIは、日本の16ビットパソコン(MS-DOS)の時代に開発された日本語入力FEP(フロント・エンド・プロセッサ)を利用するために、マイクロソフトが策定したAPI。MS漢字APIは、日本語入力FEPのアダプテーション仕様を規定したもの。MS漢字APIは、「MICROSOFT KANJI APPRICAITON PROGRAM INTERFACE」の略称。当時、かな漢字変換をアプリケーションソフトが利用するためのインターフェースであるAPI(アプリケーションI/F)は、あまり公開されていなかった。そこで、マイクロソフトはかな漢字のアプリケーションI/Fを決めようと動きはじめ、当時は24,5社あった日本語FEPメーカーにあたって、色々な意見を集めた。当初のきっかけはQuick BASIC用のAPIだったが、その時点からMS-DOSの標準的なAPIにするつもりで、周到に準備していた。
実際に、MS漢字APIが完成するまでには、かなりの開発者達の知識や経験が投入された。そして、当時MS-DOS用にマイクロソフトが販売していたアプリケーションソフトや開発言語のエディタ機能などは、すべてMS漢字API仕様を採用していた。MS漢字APIとは、アプリケーションソフトが日本語入力FEPを使うときの、インターフェース仕様。つまり、アプリケーションと日本語入力FEPを結び付けるソケットの形を指し示す用語だった。

★IME

IME(インプット・メソッド・エディタ)は、日本語MS-Windows 3.0で採用された新しい日本語入力の技術だった。日本語MS-Windows 3.0で、MS漢字APIとIMEを比較すると、以下のようになる。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【MS漢字API経由型】(デバイスドライバ方式)
┌──────────────────┐
│ＷＩＮＤＯＷＳ　対応アプリケーション　　　　　│
│　　　　　　　　　　　　　　　　　　　　　　　　　　　│
├──────────────────┤
│ＩＭＥインターフェース　　　　　　　　　　　　　　│←──┐
├──────────────────┤　　　　　│ＭＳ漢字．ＥＸＥが
│ＷＩＮＤＯＷＳ　３．０　　　　　　　　　　　　　　　│　　　　　│この仲を取り
│　　　　　　　　　　　　　　　　　　　　　　　　　　　│　　　　　│持つ
├───────┐　　　　　　　　　　　　　　　│　　　　　│
│ＭＳ−ＤＯＳ　　　│　　　　　　　　　　　　　　　│　　　　　│
└────┬──┴───┬──────┘　　　　　│
　　　　　　　 │ＦＥＰ　　　　　　│ＶＪＥ−βなど ←───┘
　　　　　　 　└──┬───┘
　　　　　　　　　　　　│
　　 　　　　　┌──┴──┐
　　　 　　　　│ＫＥＹ　　　　│
　　　　 　　　└─────┘

【IME型】(プロセス方式)
┌──────────────────┐
│ＷＩＮＤＯＷＳ　対応アプリケーション　　　　 │
│　　　　　　　　　　　　　　　　　　　　　　　　　　　│
├──────────────────┤
│ＩＭＥインターフェース　　　　　　　　 　　　　　│
│日本語処理プロセス　ＶＪＥ−γなど　　　　│
│　　　　　　　　　　　　　　　　　　　　　　　　　　　│
├──────────────────┤
│ＷＩＮＤＯＷＳ　３．０　　　　　　　　　　　　　　　│
│　　　　　　　　　　　　　　　　　　　　　　　　　　　│
├───────┐　　　　　　　　　　　　　　　│
│ＭＳ−ＤＯＳ　　　│　　　　　　　　　　　　　　　│
└───────┴─┬────────┘
　　　　　　　　　　　　　　　│
　　　 　　　　┌────┴┐
　　　　　 　　│ＫＥＹ　　　　│
　　　　　　　 └─────┘
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
IMEとは、INPUT METHOD EDITORの略称。これは、日本語MS-Windows 3.0が取得したキーコードを、仮想キーコードに直してから、アプリケーションに受け渡す働きをするプロセス処理。
キーボードからの具体的な入力コードを、メッセージという形でアプリケーションに渡す処理を行う部分で、この部分に日本語処理が組み込まれると、直接文字を渡す前に、日本語入力FEPのフロントエンド処理のように、プロセスが一端漢字変換を行い、その結果をアプリケーションに渡せるようになる。
IMEは、日本語MS-Windows 3.0の一プロセスなので、複数のアプリケーションで共用できる。これは、今までのMS-DOSではありえなかった利用環境。
図の2つの処理の具体的な違いは、変換ロジックの核となるプログラムコード部分が、MS-DOS上のコンベンション・メモリにあるのか、日本語MS-Windows 3.0内の拡張メモリ内にあるのかということ。
MS-DOS上で利用していた、従来のデバイスドライバ型を日本語MS-Windows 3.0で利用するためには、MS漢字APIとIMEインターフェースを中継するMSKANJI.EXEが必要になる。このMSKANJI.EXEが働くことによって、IMEが取得したキーコードをMS漢字API経由で日本語入力FEPに渡し、変換結果を再びMSKANJI.EXE経由でIMEが受け取り、最終的にアプリケーションに結果を伝える。この形式の最大のデメリットは、貴重なコンベンション・メモリが消費されている点。
それに対して、プロセス型では、IMEそのものに変換機能が組み込まれる。その結果、日本語MS-Windows 3.0では、独立したプロセスとして機能するIME型としての日本語処理システム開発が可能になった。
デバイス型とプロセス型の大きな違いは、MS-DOS上で利用できるか否かにあった。一見すると、MS-DOSと日本語MS-Windows 3.0の双方で利用できるデバイス型のほうが、便利なように感じられる。実際に、デバイス型であれば、MS-DOSのCONFIG.SYSで指定しておくだけで、日本語MS-Windows 3.0上でも利用できる。さらに、MS-DOSプロンプトに移動しても、そのまま日本語入力として使える。
しかし、この方法は危険を伴う。
単一の日本語入力FEPが、複数のプロセスから一つの辞書をアクセスするので、最悪の場合は辞書が破壊されてしまう。日本電気の日本語MS-Windows 3.0では、MS-DOSプロンプト機能を利用中に、日本語入力FEPを使っている最中は、タスクの切り替えができないようにロックされていた。また、東芝の日本語MS-Windows 3.0では、Windows 3.0専用のプロセス型ATOK7/Wの他に、MS-DOSプロンプトで利用しても、辞書破壊などの問題を回避できる、新しいATOK7が用意されていた。
IMEによるプロセス型では、日本語MS-Windows 3.0内で、独立したプロセスである日本語変換処理を、複数のタスクが利用する。そのため、複数のアプリケーションで日本語処理を利用しても、辞書アクセスなどの衝突がない。こうした経緯を経て、日本語MS-Windows 3.0からはじまったIMEは、Windowsにおける日本語入力システムの主流として普及していった。


(著者:田中亘 wataru@yunto.co.jp)