先日の
RealVNCに超やばいセキュリティホール
があったので、最新版のバージョン4.1.2にアップデートしたら、x2vncと組み合わせてつかったときに、winvnc4.exeがメモリをばかすか占有するという、非常におかしな挙動をするようになりました。
今朝も、使い始めて5分もしないうちに、このメモリ馬鹿食い現象が発生しました。
あーっ！！もうダメダメ。RealVNCはゲームオーバー。さよーならーーー
というわけで、昔使っていたTightVNCに戻ることにしました。とりあえず今日一日使ってみた限りでは、何の問題もありません（当然ですね）。
☆ ☆ ☆ ☆ ☆ ☆
前から思ってた不満な点に、RealVNC、TightVNCどちらも、
Windowsの日本語変換のオン・オフができない
という問題がありました。海外で開発されたソフトですし、こういう特殊なキーは、特別扱いされてて、やっぱり、普通には使えなくてもしかたないかな～～～と思って、我慢してました。ま、我慢することもなくて、たとえばMSIMEの設定を変更して、F12キーとかへ、かな漢字変換のON/OFF機能を割り当ててしまえば、VNC経由で、かな漢字変換のオン・オフができるようになります。
ちょっと、ネット検索してみますと、
TightVNC Ver.1.2.9 漢字キー対応3
なんてものを作っておられる方もおりました。これを使っても、いいですね。
ただ、私は、FreeBSD上でx2vncを実行し、Windows上のVNCサーバに接続するという使い方をしたいため、上記の改造版TightVNCを使っても、うまくいきません。
なんで、オリジナルのVNCではできないのかな～、と思って、ソースコードをのぞいてみました。
おおっ！VNCのプロトコルって、X Window Systemのキーシンボルをそのまま流している！！
なるほど。もともとUnix上で開発されたのかな？まあ、あたりまえのことですかね。
というわけで、［半角／全角］キーを押すと、x2vncからは、Zenkaku_HankakuというキーシンボルがそのままVNCサーバ（WinVNC）へ渡されています。じゃあ、Windows版のVNCサーバのソースコードを見ればいいわけねっ・・・ってことで、さっそくTightVNCのWindows版のソースコードをダウンロード。ソースコードが公開されているソフトって、こういうときに、とってもうれしいですね。
で、ソースコードを、３分ほどながめていて、気づきました。
あれ？なんか、これだったら、動いてもおかしくない気がするんですけど・・・
なんだか、Kanjiキーを扱えるらしき定義が、VNCサーバに入ってるんです。「これで動くかわかんね！」、みたいなコメントもソースコード中に入ってたりしますが。
なんで、これで動かないのだろう？？？と不思議に思いながら、もうちょっと注意深くソースを追っていったり、xevでXのイベントを観察したり、x2vncにデバッグ用処理を組み込んで実行させたり・・・
あー、わかりました。
- たしかに、VNCクライアントからVNCサーバに対して、漢字キー（Kanji key）というキーシンボルを渡すことができるようなプログラムになっています
- 漢字キー（Kanji key）ってのは、たぶん、［Alt］＋［半角／全角］キー のことなんだと思います
- しかし、この２つのキーを押す場合は、Xサーバ上では、Kanjiキーのシンボルが発生するわけではありませんでした。「Altキーを押したイベント」と「［半角／全角］キーを押したイベント」との、２つに分かれてしまいます。
- よって、VNCクライアントからVNCサーバへ送られているのは、Zenkaku_Hankakuキーのシンボルでした。
- ですが、VNCサーバが認識するのは、Kanjiキーのシンボルであって、Zenkaku_Hankakuキーのシンボルではなかった。
- というわけで、いくら［半角／全角］キーをたたいたところで、Windows側では完全に無視されていて、かな漢字変換のモードも切り替わらない・・・
なるほど、そういうことがおきてたんですね。じゃあ、どうすればいいかっていうと、X Window Systemは、xmodmapコマンドを使って、キーボードのキーを押したときに、どのシンボルが発生するか好き勝手に再設定できますので、
［半角／全角］キーを押したときに、［漢字］キーのシンボルが発生するようにしてしまえっ！
というわけです。
私は、106/109日本語キーボードを使っていますが、［Esc］キーと［半角／全角］キーを入れ替えるのが好きなので、これまで、
keycode 9 = Zenkaku_Hankaku
keycode 49 = Escape
という風に設定していました。この2行を書いたファイルを、たとえば、$HOME/.xmodmapという名前で作成しておき、
% xmodmap $HOME/.xmodmap
と実行すると、［Esc］キーと［半角／全角］キーが入れ替わります。
keycodeのほうが、キーボードのキーに対応するコードです。Escと刻印されたキーを押すと、キーコード9番というデータが発生します。で、キーコードに対して、「キーシンボル」を、自由に割り当てられる、ってわけ。
今回は、［半角／全角］キーではなく、［漢字］キーに変えてしまうので、
keycode 9 = Kanji
keycode 49 = Escape
という風にしました。［Esc］キーと［半角／全角］キーを入れ替える必要のない場合は、
keycode 49 = Kanji
になるのかな？
あ、ちなみに、ファイルを作らずに、
% xmodmap -e 'keycode 9 = Kanji'
みたいな実行方法もあります。
以上のようにして、xmodmapで［漢字］キーのキーシンボルを割り当てることで、改造版ではないオリジナルのTightVNCを使って、かな漢字変換のオン・オフができるようになりました。
２つのWindowsパソコンで、TightVNCを使って、かな漢字変換のオン・オフができないのは、［半角／全角］キーを押したときに発生するキーシンボルを、VNCクライアント、VNCサーバともに、認識できていないから、ってことですね。もしも、キー１つ押すだけで［漢字］キーのキーシンボルを発生できるような、そんなキーボードがあれば、オン・オフができると思います（が、そんなキーボードは見たこと無いです）。
☆ ☆ ☆ ☆ ☆ ☆
（2006年5月25日 追記）
［漢字］キーを割り当てるようにしたら、今度は、VMware Server Consoleの中のWindowsで、かな漢字変換のオン・オフができなくなってしまいました。
（参考） VMware Server ConsoleをFreeBSDで無理やり実行する
VMware Server Consoleのインストール先ディレクトリの中の、lib/vmware-server-console/xkeymap というディレクトリの中に、jp106とjp109というファイルがあって、これを書き換えればいいみたいです。
jp106とjp109のどっちのファイルが使われているのかわからなかったのですが（どうやらjp109が使われていたらしい）、以下のようなふうに、「Zenkaku_Hankaku」となっているところを、
# grep Zenkaku ./xkeymap.org/*
./xkeymap.org/jp106:Zenkaku_Hankaku = 0x029
./xkeymap.org/jp109:Zenkaku_Hankaku = 0x029
以下のように「Kanji」へ書き換えて、vmware-server-consoleを立ち上げ直すと、on/offが可能になりました。
# grep Kanji ./xkeymap/*
./xkeymap/jp106:Kanji = 0x029
./xkeymap/jp109:Kanji = 0x029
＝の左辺がXのキーシンボルで、右辺が、VMwareの中で使われるキーコードなのではないかと予想されます。
☆ ☆ ☆ ☆ ☆ ☆
(2006-11-02)
昔、なぜ、TightVNCからRealVNCへ乗り換えたかの理由を、思い出しました。なんか、TightVNCって、ときどき、サーバとの接続がブチブチ切れるんですよね。
FreeBSD上のvncviewerとXvncとの間の接続が、よそ見している間に切れて、vncviewerが終了してしまいます。もう一度接続すればいいんですが。
Windows同士でTightVNCを使った場合も、接続が切れたりするし、あと、なんの操作も受け付けられなくなることもあります（マウスでドラッグしているときになることが多い気がする。マウスポインタにアイコンが張り付いたまま剥がれなくなる）。これも、もう一度接続すればいいんですが・・・
