2016-02-05

ximimm

windows用の日本語入力ソフトATOKをLinuxのX11上で動かすためのソフトウエアです。コードはソフトウエアのダウンロードにおいてあります。

2010年の製品版のATOKで動作確認しています。これ以外でも動くものがあると思うのですが確認はしていません。2014年の体験版はインストールができず動作させられませんでした。

これはwine上で動かします。プログラム構造はwindows側とX11側の２個のスレッドを用意して通信しながら動作します。本当はシステムコールselectを用いて１スレッドで衝突がない安全なコードを書きたかったのですが、ちょっと調べた感じだとwindowsはselectで1スレッドでファイルディスクリプターを用いて振り分けて動作させることができないような感じでした。selectを使うことはできるようですが実際はウインドウ操作のイベントループのコードをdefineで差し替えてなにか複雑な状態で実現しているようで、windows3.1のスタイルを拡張したもののようです。

完全に調べたわけではありませんが本当の意味のselectがOSとして実現できていないのであればwindowsは構造的に不安定であるということになります。ウインドウ操作だけの範囲においては安定です。

2018-09-05追記

windowsはselect()を独自の苦肉の策な方法で実装しているようだと書きましたが、2018年秋のwindows10のアップデートで疑似端末(pty)を追加するという記事で内部構造が解説されていて現状が伺えます。

"windows-command-line-introducing-the-windows-pseudo-console-conpty"で検索するとその情報が見つかります。

selectは複数のptyや、それに似た構造をしているデバイスのうちバッファーにデーターがたまっているものを選択するためのコマンドです。

秋のアップデートで、ConPTYと言う物が追加されるようで、その図を見てみると予測ですがptyを使うためには通信用のmapしないwindowを１つ作りそのプロパティーを使ってカーネルと通信するようで、アプリケーション側からカーネル側へ文字列を送る場合はAPIを通して専用のプロパティーに文字列を書き込むと、そのイベントをカーネルがキャッチして対応する別のアプリケーションへ文字列を送るようです。逆方向はカーネルがメッセージを発生させてそれをGetMessage()でキャッチしたアプリケーション側のAPIがメッセージから文字列を抜き出してアプリケーションへ送るという仕組みのようです。

select()は相変わらず苦肉の策の実装なのではないかと思います。

このアップデートでは移植性を重視したようで、うまくすれば無変更でコンパイルできる可能性がありますが処理速度の低下はさけられないようです。また、操作用のウインドウを出すにはやはりselectとGetMessageの二重構造の問題がありselectをGetMessageに書き換えなければいけないようです。

ウインドウに関係ないptyやttyのイベントさえもウインドウを介してメッセージ通信をおこなうことでシステムとしての整合性を保ち安定化させているわけですが、どうしてもオーバーヘッドが多くなるのでサーバー用途には不向きなようです。この状態を打破するにはウインドウイベントインターフェース用のミニカーネルをアプリケーションに1対1対応で起動する構造にしてUNIX(posix)型のデバイスインターフェースをもつカーネルとミニカーネルをsocket形式で接続するようにするといいのではないかとおもいます。サーバープロセスではミニカーネルは不要で、アプリケーションの仕様によって3.1用とかXP用とかのミニカーネルを選択できるようにすれば互換性も確保できます。