碧落にて気まぐれに一言

2011/09/18

Windows Server 8。コマンドだけの世界で*nixへ挑めるのか、それとも。

Filed under: 未分類 — タグ: , — Suguru Yamamoto @ 16:15

マイクロソフトの開発者向けカンファレンス「//Build/」にて、”Windows Server 8 apps must run without a GUI – learn more now”というセッションがあったそうです。私はWindows Server用サーバアプリケーションを業務で開発していますので、刺激的ですね。なお題名に “must” とあるものの、必須ではなく強い推奨ですので勘違い無きよう :)

さて、セッション内で言われているリソースの話やセキュリティの話は「おっしゃるとおり」ですので議論の余地は無いと思います。ただ、捉え方によっては常にGUIを備えることで(言い方は悪いですが)技術的知識・経験の浅い人でも操作できることを最大の価値としてきたWindowsが、PowerShell上の「コマンドだけの世界」に戻ることになるのではないでしょうか。そして「コマンドだけ」という部分だけに着目するならば、そこは*nix(UNIXやLinux)勢の独壇場だと私は考えています。私にとっては、今でも実用に耐える*nixのコマンドライン環境は本当に優秀な環境であり、MS-DOSを引きずるWindowsのコマンドライン環境は「放置された廃墟」です。

*nixのコマンド環境を考えると、困ることがあっても探せば何らかの解決方法が見つかってきました。また基本機能は十分強力ですから、(機能面では)コマンドだけで業務をこなすにあたって不足は無いと感じます。ちなみに私が業務で*nix用サーバアプリケーションを開発する際にはWindows XPからTeraTerm (SSH)でリモートログインし、vimとmakeとシェルスクリプトで全開発作業を行っています。X Windowを使うのは、システム設定を変更する際に「設定ファイルがドコにあるのか分からないからGUIメニューで探した方が速い」場面だけです。実経験として、*nixではGUIが無くとも最初から何一つ問題がありませんでした。

Windowsのコマンド環境を考えると、第一にバッチファイルや標準コマンド群といった基本機能が貧弱すぎます。この点はPowerShellを導入することで改善しますが、まだまだWindows Server 2003などが主流で残っている現状ですからPowerShellが使えることを前提にはできません。第二に、コマンド操作用画面として使うCMD.EXEの多言語対応度合いの低さが問題です。日本語WindowsではShift_JIS以外を選択できず、レジストリを変更して無理矢理UTF-8に対応させたならカーソル位置が正しく表示されず妙な動きをします(無理矢理動かしているので当然ですが)。コマンドプロンプトでShift_JIS文字列しか表示できないため、C/C++で開発するコマンドを内部文字コードUTF-8とするのが無駄に難しくなり、多言語化もほぼ不可能です(Shift_JIS文字しか表示できない環境では日本語・英語以外の文字を表示できないので確認もできない)。第三は、権限昇格の仕組みがコマンドベースでは実現できない問題です。Windows 7などでは、特権が必要な場面に出くわすたびに特権で起動したCMD.EXEのインスタンスを再作成し、そちらで作業する必要に迫られます。もちろん最初から特権でCMD.EXEを起動しておけば手間的には良いのですが、それは「UNIXシステムへ常にrootでログインする」のと同じですから、そんなことを強制される環境は、とても使いたいと思いません。以上の問題はすべて、アプリの作り込みでは解決できません。こうした面があるため、魅力的なWindows向けのコマンドアプリを開発しても、その実行環境が魅力的で無いため、トータルで魅力が失われる気がしてしまいます。そして、コマンドアプリのニーズを実感として感じていないというトドメがあり、結局Windows向けのコマンドアプリにまったく投資してきませんでした。

GUIを考えるとWindowsに軍配が上がりますが、コマンドという観点では*nixに大きく軍配が上がると思います。そうだというのにコマンドベースのサーバアプリがWindows Server向けに求められるというのは、面白い話です。少なくとも私にとってのWindows Serverの価値を、少し考え直す必要があると思います。

2011/06/26

コマンドプロンプトでUTF-8の文字列をアドホックに表示

Filed under: 未分類 — タグ: , — Suguru Yamamoto @ 19:16

なぜか、コマンドプロンプトでUTF-8の文字列を表示できなくなってしまいました。「chcp 65001」でコードページを変更するのは当然良いのですが、レジストリを編集して追加したはずの日本語フォントがリストアップされず、英語フォントでの表示しかできません。この話をWeb検索するとおおよそXP時代かVista時代の情報が出てくるのですが、今日試した限りどれもうまくいかない…はて?
きっとWindows 7になってから仕様が変わったのだろうと勝手に納得して、代替案を捜しました。結局の所良い方法が見つからなかったのですが、とりあえずの応急処置策を見つけましたのでメモしておきます。

コマンドプロンプトは、どうも起動した方法(起動時のウィンドウのタイトル文字列?)によってまとめて設定が切り替わる仕組みになっているようです。逆に考えると、ウィンドウのタイトル文字列ごとに表示方法などの設定項目が一式どこかに保存されている、ということになります。今回私が採った方法は、この設定を直接書き換えてしまうことで起動時のコードページとフォントをアドホックに変更する、というものです。

起動した方法ごとの設定は、HKCU\Consoleキーの下に並んでいます。たとえばcmd.exeを直接起動した場合は「C:\Windows\system32\cmd.exe」といったタイトルになります。私の環境では、これに相当する「%SystemRoot%_system32_cmd.exe」というキーがありましたので、それを開いて次のように変更しました。

  • CodePageを65001
  • FaceNameを「MS Gothic」に
レジストリエディタのスクリーンショット

レジストリエディタのスクリーンショット

応急処置ですが、これで起動した時点でUTF-8表示できるような状態になりました。なおこのようにUTF-8モードにした場合、文字幅の計算が正しく行えていないようで、たとえば入力した日本語の上をカーソル移動すると…変な位置にカーソルが移動します。Unicodeで文字幅という概念を扱うのはきわめて難しい上コマンドプロンプト自体レガシーと考えているであろうMicrosoftの立場からすると労力をかけられないのでコマンドプロンプトだけは表向きにもUnicode対応を前面に出さないのだろうなと勝手に理解しています。

2011/04/24

VirtualBoxでシリアルポート(COMポート)を使う

Filed under: 未分類 — タグ: , , — Suguru Yamamoto @ 14:13

マシン仮想化ソフトであるOracleのVirtualBoxで、シリアルポート(COMポート)を使う場合の設定方法についてメモします。使えることは昔から分かっていたのですが、設定方法などを調べることができていなかったので本日実施。備忘録です。なお、使用したVirtualBoxのバージョンは4.0.4です。

最初に設定画面のスクリーンショットを掲載しておきます。
VirtualBoxでのシリアルポートの設定画面例
さて、おそらくゲストOS(仮想マシン)がホストOS(物理マシン)のシリアルポートを直接使いたい、というケースが一番多いのではないかと思いますが、ここではあえて一般的に説明してみます。VirtualBoxのゲストOSの設定画面を開いたら「Serial Port」を選択し、各設定項目を次の通り設定します。なお設定画面のタブは「Port 1」でも「Port 2」でも構いません。2つの仮想シリアルポートをゲストOSで使いたい場合は、両方のタブを設定すればOKです。

  • Enable Serial Port: 該当画面の設定を有効にする=仮想シリアルポートをゲストに見せる場合はチェックします
  • Port Number: ゲストOSからこの仮想シリアルポートが何番目のシリアルポートに見えるかを設定
  • IRQ: (普通は標準通りで良いです)
  • I/O Port: (普通は標準通りで良いです)
  • Port Mode: (後述します)
  • Port/File Path: (Port Modeの指定によって意味が変わります)

Enable Serial Port、Port Numberは説明不要だと思います。IRQとI/O Portについては、これらの値が決まらないと「OSがシリアルポートを使えない」ことだけ理解すれば問題ありません。Port ModeとPort/File Pathは、Port Modeの選択肢ごとに次のような意味になります。

  1. Disconnected: 何も接続されていないシリアルポートがあるように見せかける方法です。シリアルポートを列挙するプログラムをゲストOSで開発・検証する場合など、とりあえずダミーであってもポートが存在していて欲しい場合に使います。Port/File Pathの値は無視されます。
  2. Host Pipe: ホストOS上の名前付きパイプをシリアルポートに見せかける方法。高度な使い方ですので普通は使いません。ホストOS上で動いているプログラムとリアルタイムで通信したい場合で、しかもTCP/IPなどの通信が使えないような場合などに使います(おそらくこの設定を使うのはOS自体を開発する場合ぐらいではないかと思います)。Port/File Pathの値には名前付きパイプの名称を指定します(Windowsならば\\.\pipe\mypipenameなど)。
  3. Host Device: ホストOS上で使えるシリアルポート(=物理マシンの物理的なシリアルポート)をそのまま使わせる方法。まさに「そのまんま」な方法ですが、ポート番号、IRQ、I/O Portアドレスといったパラメータを変更することもできます。Port/File Pathの値には、COM1を使う場合は「COM1」、COM2を使う場合は「COM2」などと指定します。
  4. Raw File: ホストOS上のファイルをシリアルポートに見せかける方法。使ったことがないため憶測ですが、指定したファイルにホストOS上で何かを書き込むとその内容がゲストOSに送信され、ゲストOS側でシリアルポートに何かを書き込むとその内容が指定したファイルに書き込まれる、という形になると思われます。Port/File Pathの値には、このような用途で使いたいファイルのパスを指定します。

ホスト側の設定は以上です。ゲストOS側については、おそらく正しく設定した状態でOSをインストールすれば認識されるはずだと思います。もし後から追加する場合、ゲストOSの側でシリアルポートの設定を追加してください(たとえばWindows 2000ではコントロールパネルから「ハードウェアの追加と削除」を選択し、「デバイスの追加/トラブルシューティング」、「新しいデバイスの追加」、「いいえ、一覧からハードウェアを選択します」、「ポート(COMとLPT)」、「製造元=(標準ポート)、モデル=通信ポート」と選択して、IRQをVirtualBoxのIRQの設定値に合わせ、I/O範囲の開始アドレスをVirtualBoxのI/O Portの設定値に合わせます)。Windows 2000で設定した画面例を次になります。
Windows 2000でのシリアルポートのプロパティ画面
なお、VirtualBox側でCOM1として見えるよう設定した場合でもゲストOS側でCOM1と認識されるとは限りません。このあたりの理由はまだ分からないのですが、実用上は問題ありませんので「そういうものだ」と理解しています。

シリアル通信の開発を経験されている方の中にはHost DeviceモードでCOM1を指定する場合とRaw FileモードでCOM1を指定する場合にどう違うのか疑問に思われる方もいらっしゃるかと思います。詳細は未確認ですが私としては、Raw Fileモードでホストからデータを送信する場合はVirtualBoxが定期的に指定ファイルの更新日付を監視し、更新を検出するたびにゲストOSへ送信することになる(つまりリアルタイム通信にならない)と想像しています。実際にRaw Fileモードで\\.\COM1など指定して通信してみたところ通信速度が猛烈に遅くなりましたので、物理シリアルポートを使う場合はHost Deviceモードを選択した方が良いことは間違い無いようです。

2011/01/15

xenメモ

Filed under: 未分類 — タグ: — Suguru Yamamoto @ 18:39

今からxenを使う人は少ないんじゃないかと思いつつ、仕事場でxenを設定していたときにつまづいたことを備忘録。

ホストOSはCentOS 5.3で、インストール時にオプションでxenを選択して構築したところ、ゲストOSは標準でNAT構成になりました。しかし都合によりブリッジネットワーク(ゲストOSをホストOS=domain0と同じネットワークに所属させる)にしたかったのですが、管理用のGUIには設定項目が無く、設定ファイルを直接書き換える必要がありました。

  • /etc/xen/ゲストOS名 をテキストエディタで開く
  • eth0=[...bridge=virbr0...] という記述のある行を探す
    (eth0はゲストOSの一つ目のNICだと思っています)
  • virbr0xenbr0に変更
    (virbr0はNATを構成するための仮想NIC、xenbr0はマシンの物理NICへブリッジするための仮想NICだと思っています)

とりあえず上記変更でブリッジネットワーク接続になったのですが、ゲストOSのWindows Server 2003に会社規則のウイルス対策ソフトをインストールしたとたん、ブルースクリーンが頻発するようになり使えなくなりました。結局xenを使うのは諦めて、紆余曲折を経てWindows 7上にVMware Serverを入れてその上でWindows Server 2003を動かすという奇妙な構成に。なんだかなぁです。

2010/04/15

VisualStudio、Itaniumのサポートを停止

Filed under: 未分類 — タグ: , , — Suguru Yamamoto @ 19:53

InfoQ – Visual StudioはItaniumのサポートを中断する

Visual Studio 2010をもって、Itaniumプロセッサのサポートが終わるそうです。未だかつて一度たりともItaniumプロセッサのマシンを触ったことが無いのですが、IA64というフレーズは今後聞かれなくなっていくのでしょうね。開発者としてIA64用バイナリの資産を持っておらず、ほっとする気持ちもありますが(苦笑)

「そこそこに良い」ものがすでに存在する場合、その分野で新しい何かを普及させることは難しい。UNIX世界の「Plan 9」を思い出しましたが、これはいろんな分野でいつも起こっていることですね。どんな分野でも、これからも、きっと。アーキテクチャの話だけではもちろん無く、あらゆるものの価値に言えることでしょう。

Powered by WordPress