本日の成果

タグ: Computer

  • 仮想マシンを作りまくった

    仮想マシンを作りまくった

    本日の成果：仮想マシンを作りまくった

      ふと思い立って、手持ちのOSをひととおり仮想マシン化してみたよ。右のスクリーンショットは、左上がDR-DOS(笑)、左下がMS-DOS、中央がWindows 3.1、右下がWindows NT 4.0だ。(右上はVMware Fusionの管理ウィンドウ)

      Windows 3.1までは、ネットワークが使える状態まで行かなかった。DR-DOSはネットワークサポートもあるようなのだけど、試してない。MS-DOSとWindows 3.1は、ドライバは見つかったもののMS爛漫本体を持っていないので無理だった。
      Windows NT 4.0はTCP/IPレベルでは問題なく動作したものの、ファイル共有でLinuxサーバを見に行ったときに本来見えるべき共有が見えないという現象が発生してしまった。まぁこれはウチのサーバが、接続するユーザのユーザ名に応じて見せる共有を制御するという特殊なことをやってるせいもあると思うけど。ただ、Windows 95や98、2000以降では問題なくて、コイツだけ発生するというのが不思議。
      あれ? スクリーンショットにWindows 2000がないぞ。ああそうだ、仮想マシンは作ったのだけど、スクリーンショットの状態からさらに起動しようとしたら、物理メモリが足りないとゆうて蹴られたのでした。(ウチのMac Miniのメモリは1GB)

      上のスクリーンショットをとった時点で、手持ちの古いOSはアレで全部だったのだけど、なんとなく間を埋めたくなって、秋葉原の怪しいお店でWindows 95と98を探し出してきた。午後6時半に末広町に着いて怪しいお店を1軒平均1分ぐらいで探していったところ、箱入りでライセンス的にも問題なさそうな良品はみなプレミアついて馬鹿みたいに高い! どんなに安くても1万円以下で買うことはできないようだ。
      でコレは結局ズダーンな品をそれでも2千円ぐらいで買ってきたもの。正直Win95なんて数百円で投げ売りされてると思ってたのが甘かった・・・。
      VMwareの場合、セットアップディスクが仮想マシンのCD-ROMを認識しないらしく、CD-ROMの内容をあらかじめ仮想マシンのHDDに転送しておく必要があった。VMware Fusionの場合、簡単に仮想マシンのディスクをマウントすることができるので助かった。
      もう、インストール作業からして懐かしい。そうそう、95では「アダプタ」「プロトコル」「サービス」というカテゴリで分けられてて、それを「バインド」するのだった。「The Microsoft Network」なんてのもあった。IE4.0にはひどい目に遭った。なんか当時はディスク容量と戦ってた気がするけど、今にして思えばこんなにコンパクトだったんだねぇ。

      そして一緒に怪しいお店で手に入れたWindows 98。うわっ、ズダーンな証拠が起動画面にモロに!!!・・・見なかった事にして下サイ。
      Windows 98からは、 WINDOWS  OPTIONS  CABSあたりにセットアップファイルが丸ごとコピーされるようになったので、仮想ディスクイメージもぐっと大きくなった。でも普段使う分にはそのファイルは全く使わないので、削除したり退避したり、当時やってた人は多いはず。

      あと仕事でしばらく使ったことがあるので、Windows NT 3.51も欲しいところなのですが、おそらくWindows 95や98よりも入手困難であろう。

      や、でもさらにOS/2とかMINIXとかSolarisとか、そっち方向には行かないですよ? Linux系はフツーにLive USBとかあるからいつでも試せるし。(完)

  • clipboard.exeを作った

    本日の成果：clipboard.exeを作った

      コマンドプロンプトで、dirの結果をエディタに貼り付けたりしたくなることがありませんか。ワードプロセッサで切り取った文章を、ちょっとしたフィルタにかけたいと思ったことはないですか。いわゆる、クリップボードと標準入出力とでデータをやりとりするニーズですな。個人的にはこれが標準で提供されないのが不思議でならない。

      例によって、そういうコマンドはフリーソフトその他ゴロゴロあるのだけど、

    • 標準入力→クリップボード と クリップボード→標準出力 の動作が1つのプログラムでできること
    • 純粋にクリップボードの内容だけを出力し、改行1個たりとも余分なものを出力しないこと
    • コマンド名が、思い出しやすいものであること(そう頻繁に使うものでもないので)

      などのこだわり条件を満たすものが見つけられなかったので、作ってみました。

      ドキュメントはありません。標準入力がファイルにリダイレクトされていると、それをクリップボードに格納します。それ以外の場合、クリップボードの内容を標準出力に出力します。以上。

    clipboard.zip

  • StartDaemon

    本日の成果：StartDaemon

      PCをお使いのみなさんは、便利な常駐ソフト的なツールをいろいろお使いのことと思います。フリーソフトとか、同じような機能のツールでもいろいろ種類があって、聞いてみると皆様それぞれ無駄にこだわりがあるのが面白いところ。
      ところでそういうツールが5つも6つも増えてくると、Windowsのスタートメニューのスタートアップフォルダの中身が結構うるさくなってくるんだよね。そして、ログインするとそれらが一斉に、よーいドン! で起動されるから、実行間隔や順序が指定できない。その辺を改善してくれるツールもあるけれど、普通そういうのはバッチファイルを作って対応するよね、昔のAUTOEXEC.BATみたいに。・・・私だけですかそうですか。

      というわけで、そのようなログオンスクリプト的なバッチファイルをスタートアップフォルダに入れているのであるが、ひとつ問題があった。このバッチファイル、後々トラブルが発生したときに問題解決に役立つように、自分自身の出力をログファイルにリダイレクトするようにしてある。そうすると、そこから起動されたツールも、子プロセスなので親プロセスの開いているハンドルを引き継ぐのよね。つまりログオン処理が終わってもそこから起動されたツールが終了しない限りログファイルがオープンされたままになってしまうのだ。
      あと、起動時のカレントディレクトリも同様に、例えばエクスプローラで、新しいフォルダをつくって、コマンドプロンプトを立ち上げてそこに移動して、なにか適当な常駐ツールを起動したとすると、その後コマンドプロンプトを閉じても、さっき起動した常駐ツールを終了させない限り、最初に作った新しいフォルダを削除できないのだ。(ツールがカレントディレクトリを掴んでいるため)
      分をわきまえた(笑)ツールなら自ら標準入出力をクローズしたり、自分自身が格納されているディレクトリに移動したりするように作られているものだが、そうでないものも当然あるわけで、そのようなプログラムを、標準入出力をリダイレクト中のバッチファイルから問題なく呼び出すことは、バッチファイルの書き方の工夫だけでは無理だった。

      というわけでその辺を改善するツールを作ってみました。その名もStartDaemon。大したことはしてなくて：

    • 親プロセスのハンドルを引き継がずに、子プロセスを起動する
    • その際、起動するプログラムのあるフォルダに移動する
    • プログラムを起動する際、ウィンドウを最小化した状態で起動する

      というだけのもの。でもおかげで前述の問題が解決されてスッキリしたよー。(完)

    StartDaemon.zip

  • WinMerge Portrable 改造版を作った

    WinMerge Portrable 改造版を作った

    本日の成果：WinMerge Portrable 改造版

      テキストファイルの比較は開発現場では頻繁に必要になります。Word/Excelべったりの人海戦術な現場でもないかぎり。(^_^;
      なので、比較のためのツールはCUI/GUI問わず長い歴史がありまして、私もWinDiffやDFやRekisaなどいろいろ試した果てに、今はWinMergeを愛用しています。というか、それのポータブル版のWinMerge PortableをUSBメモリに放り込んで持ち歩いています。
      Rekisaには劣るかもしれませんがそれなりに綺麗な表示で、差分を表示するだけでなくそのまま編集することもでき、プラグインでWordやExcelの文字部分の比較もできちゃうあたりが気に入っております。

      ところがそのWinMerge Portableですが、起動してオプションを変更しても、一旦閉じて再起動するとその変更したオプションがデフォルトに戻ってしまうという問題がありました。最初は、ああポータブル版だからレジストリとかに形跡を残さないようにしてるのね、それなら仕方ない、などと思っていたのですが、その後いろいろ試していたらどうも設定が残る項目とそうでない項目とがあるみたいなのです。なんだか腑に落ちないのでソースも覗いて調べてみたところ、作った人の思いとしては終了時に設定をファイルに保存した上でレジストリからは証拠隠滅(笑)して、次回起動時にファイルに保存しておいた設定を読み込むようなロジックは入ってるようでした。
      さらに調査を続けたところ、レジストリの中身をファイルに書き出すときは、それ用のライブラリを使っているのに対し、ファイルからレジストリに読み込む時には、同じライブラリではなくreg.exeを使っているために、最後まで読み込まれていないということが判りました。だいぶ昔のバージョンからずっとそうなっているらしいことを考えると、日本語環境独自の問題かも。そもそもなぜ、読み込むときだけreg.exeを使うようなコーディングになっているのかも謎です。reg.exeを優先して使うなら使うで、読み込みだけでなく書き出しにも使うようにするべきではないでしょうか。
      それともう一点、これは不具合か仕様か判りませんが、WinMerge Portableでは、ポータブル版独自の設定ファイルに、追加のオプションをあらかじめ書いておくことができます。できますけど、追加のオプションが毎回コマンドラインの末尾に付加されるので、一時的に打ち消すことができません。例えば、普段はいつも○○のフィルタを使いたいが、今回だけ××のフィルタを使いたい、という時に、設定ファイルを書き換える必要がありました。
      普通は、設定ファイルに書いたオプションと、コマンドラインで与えたオプションとでは、後者の方が強いべきではないかと思うのですが。

      というわけで、上記2点とあといくつか改善した版を作ってしまいました。1つ目の問題については、reg.exeを使わず、書き出し/読み込みともにライブラリ側の命令を使うようにしました。これにより、前回終了時の設定が復元されるようになりました。
      2つ目の問題については、コマンドラインを組み立てる時の文字列の連結の順番を変えただけ。

      せっかく作ったので、GPLに基づき公開します(笑)。

  • Cromium OS試した

    Cromium OS試した

    本日の成果：Cromium OS試した

      なんかBitTorrentで誰かの作った仮想マシンが出回ってたので試しに動かしてみたよ。

    起動したところ
    ログイン中
    Gmailキター
    とりあえず自分のホームページを表示させてみた
    Twitterもフツーにいけそう
    ニコ動もいけました

      しかし、ウチのマシンが非力なせいか、仮想マシンとVMwareとの相性が悪いのか、とっても遅いです。そしてすぐハングします。これが専用のハードとそれに合わせてカスタマイズされたOSとの組み合わせならどれくらい軽くなるのか気になるところです。個人的には少なくともWindowsよりは軽く速くならなければ使う理由はないわけで。あと変なツノ生やさなくても常時接続できるようにならないと、コンセプト上つらいのではないでしょうか。もしくは「どこでも無線LAN」の類か。

  • 昔のVisual SourceSafeのプロジェクトをSubversionに移行した

    昔のVisual SourceSafeのプロジェクトをSubversionに移行した

    本日の成果：昔のVisual SourceSafeのプロジェクトをSubversionに移行した

      2002年頃から、仕事で手掛けた、数少ないVBやVC等のプロジェクトは、Visual SourceSafeでバージョン管理してました。残念なことに、大部分のプロジェクトはMS-Accessで出来ているので(はい、ここ驚愕するところ)、そっちは人力でバージョン管理していたというかバージョン管理という概念自体がないというかそんなありさまの現場だったので、自分で勝手にローカルでリポジトリ作って一人で管理していただけなのですが。
      機械でバージョン管理することの効果は甚大で、毎回時間をかけてバックアップを取る必要がなく、それ以前にバックアップを取り忘れることも原理上なく、また旧バージョンとの差分も直ちに確認できるし、間違いなく旧バージョンに戻すこともできるため、ソース中に修正前のコードをコメントアウトした状態で残しておく必要がなくなります。これは大きい。
      で、なんでSourceSafeだったのかというと、単にVisualStudioにバンドルされてたからというだけで、個人的にはSubversionを使ってます。これのWindows用のフロントエンドであるところのTortoiseSVNがもう、感動的に使いやすくてたまりません。
      そして今、業務の都合上、SourceSafeの入ってないマシンで仕事をしてるもので、つまり昔の成果物が自分でも見られない状態になってしまっているのです。それはイヤだ。というわけでvss2svnというプログラムがあるようなので、これを使わせてもらってSourceSafeのリポジトリをSubversionのリポジトリにコンバートしてやるぜ！

      と、はりきって始めてはみたものの、かなり手間取りました。なんつーか日本語との戦いでした。ていうかプロジェクト名に「○○集計表」とかつけていたもので例のこの「表」のせいでいろいろとダメなことに(汗)。結局しばらくソースを追いかけてみたもののperl初心者なので対策方法が判らず、やむなくレポジトリの方を「表」を含まないものにリネームして移行することで逃げました。リネームの履歴は管理できないSourceSafeのおかげで助かった・・・(笑)

  • お手軽ソートマクロを作った(3)

    本日の成果：お手軽ソートマクロを作った(3)

      前回改善したソートマクロに、バグというか問題点が見つかった。大文字小文字を区別しないで比較するために、全部大文字に変換してから比較するようにしたんだけど、それだと、いくつかの記号([]^_`)がアルファベットより後に並んでしまう。他の多くの記号はアルファベットより前に並ぶのでどうも違和感がある。というわけで全部大文字に変換してから比較するのではなく、全部小文字に変換してから比較するようにした。これで先述の6字は、アルファベットより前に並ぶようになった。

      しかしこれを機会に文字コード表を改めて見直してみると、記号と数字とアルファベットの並び順って実はかなり入り乱れていて醜いことになっていることが判った。個人的には、記号→数字→アルファベット の順になっているのが一番直感的かなと思うのだけど、実際には、記号→数字→記号→アルファベット大文字→記号→アルファベット小文字→記号 という具合に並んでいて、もういやーんな感じですよ。なのでこれに対する対策はとりあえず諦めることにしました。orz

      ダウンロードはこちらから。(URL前回と同)

  • スタートメニューを整理した

    スタートメニューを整理した

    本日の成果：スタートメニューを整理した

      Windowsのスタートメニューとタスクバーは、Windowsを使いにくくしている主な原因のひとつではないかとも最近思いつつあるのだけど、じゃあこうすればいい、という説を唱えるまでにはまだ至っていないのでそれはまたの機会に。ちなみにおぱはまだ「クラシック」スタートメニューを主に使っています。

      スタートメニューについては、ソフトが増えてくると次第に探しづらくなって、設定で「頻繁に使用するものだけを表示」するようなこともできるのだけれど、「頻繁」の定義がよくわからないせいか、出てきてほしい項目が隠れたり、1回試しに使っただけの項目がその後ずっと表示されたりと、自分で制御できないので、この機能は使っていない。というかそれ以前の問題なのである。例えばこんな。

    イヤなスタートメニューの例1 : 無駄に深い階層 (イメージ図)

      大分類→小分類とキレイに分類したい気持ちがあったのだろうと思うけど、ソフトを使う側としてはそんなツリーを毎回辿るのは面倒くさくてしょうがない。そして、このような場合は上記の「頻繁に使用するものだけを表示する」ようにしていても面倒くささは変わらない。(但し、XP以降の新しいスタートメニューなら、何度か使っていれば一番上の階層に現れる)

    イヤなスタートメニューの例2 :
    アンインストーラが同列に表示される (イメージ図)

      間違ってアンインストールしてしまいそう。上の例などは、ソフト本体よりもアンインストーラの方が先に表示されてしまっていて、まるで一番最初にアンインストールしてほしいかのようだ。

      で、冒頭に戻るけど、これをスマートに解決する方法はまだ思いつかない。XP以降の新しいスタートメニューを使って、かつ頻繁に使用するものだけを表示する設定にすれば済むのかというと、私の場合、ある程度頻繁に使用する、すぐ手の届くところにあってほしいものがツール含めて20～30は下らないので、それがズラッと表示されても探すのが大変だし、探して見つからなければまた普通にスタートメニューの奥深くを探すことになるのだ。

      で結局、全部人力で、右のようによく使うものだけ別枠でスタートメニューに纏めておくことにした。これはよく使うwebサイトを、webアプリケーションの形でスタートメニューに入れてあるところ。他のフォルダには、アプリとかツールとか各種設定ソフトとかを分類して入れてある。
      これでもう迷わない・・・といいな。

  • Macマウス問題

    本日の成果：Macマウス問題を解決した(ような気がする)

      私も含めて、WindowsとMacとでマウスカーソルの感触というか、動かしたときの感覚というかがどうも異なっていると感じる人は多くいるようで、各人さまざまにその理由を分析している。しているのだけれど結局最後の結論としては、Windows→Macの人はWindowsの挙動が使いやすいと言い、Mac→Windowsの人はMacの方が使いやすいと言う。ということはつまり慣れればどっちでもいいということか。

      多くの人が書いてるけれども、「Macのマウスカーソルには加速度がついているがWindowsのマウスカーソルには加速度がつかない」というのは微妙に誤りで、コントロールパネル-マウス の「ポインタの精度を高める」という名前のオプションでオンオフを設定できる。よく覚えていないがデフォルトでオンではなかっただろうか。

      それにしても(私はWindows使用暦の方が長いので)Macのマウスカーソルの動きには違和感があった。なんというか、マウスカーソルを10cmほど右に動かしたいとして、いつものWindowsの感じで右にマウスを動かすと、思ってた量の半分ぐらいしか動かない。あれ? と思って脳が勝手に足りない距離を補おうとして反射的に素早くマウスを動かすと今度はピューと遥か彼方へ行ってしまう。その繰り返し。

      つまり加速度のつき方がなんだか異なるのではないかということは何となく感じていたのだけれど、このたびそれを裏付ける論文を見つけた。

      Mac OS X のマウス加速問題

      なるほど私がこれまで漠然と感じていた現象を見事に説明するものだ。そして、嬉しいことにいくつかの解決方法も紹介されている。MouseFixのGUI版のiMouseFix、USB Overdrive、SteerMouseと3つとも試してみて、一番違和感なく設定できたSteerMouseを使うことにした。
      うむ、快適である。めでたし、めでたし。

  • Apple Remote リモコン問題

    Apple Remote リモコン問題

    本日の成果：Apple Remote リモコン問題を(ある程度)解決した

    　この前2009/09/21のエントリで書いたように、新しいMac Miniを買ったのだけど、この新しいMac Miniにはリモコン受光部がついていて、リモコンで音楽を聴いたりDVDを再生したりできる。
    ただし、リモコンは標準では付属しない。おーい。

    　でも大丈夫! 実は私、前にiPod Touch用にUniversal Dockを買ってあったのだ。コイツにはAppleリモコンが付属する。そもそも、私はiPodに入れた曲をDockに挿したままiPodで聴くということはしないので、只の充電スタンドがなんでこんなに高いのか、リモコンなし版はないのか、とブツクサ言いながらもそれを買っていたのでした。で、充電台としてだけ使って、リモコンの方は、使わないのでお蔵入りしてたのでした。しかしこのたび新Mac Miniが来たのでリモコンにもやっと日の目を見る機会が!

    　というわけでワクテカしながらリモコンをMacに向けて再生ボタンをカチ! おお! iTunesで見事に音楽が流れだしたよ! ついでに同時にiPodを乗せたDockもリモコンに反応して、こっちからも音楽が流れだしたよ! 違う曲が! ダメじゃん!!

    　そう、初期状態ではすべての機器が全てのリモコンに反応するようになっているので、Mac Mini本体もDockも両方とも反応してしまうのであった。で、一応それを回避するための方法というのが用意されてはいるのだが：
    　1. 初期状態では、どのリモコンにでも反応する。
    　2. 特定の紐付け操作を行うと、そのリモコンだけに反応する。
    というルールなのだ。OK、それならばMac Miniとリモコンを紐付けすればOKだよね。と私も最初そう思ったのですがダメでした。
    「特定の紐付け操作を行うと、その機器はそのリモコンだけに反応する」のであって、「特定の紐付け操作を行うと、そのリモコンはその機器だけに利く信号を送る」のではないのがポイントだ。つまり、Mac Miniとリモコンを紐付けしても、Dockの方は相変わらず、どのリモコンにでも反応する設定のままなので、結局両方とも反応しちゃうのは変わらないのだ。そしてDockには、「リモコンに反応しない」ような設定をすることはできない。

    　解決方法としては、リモコンをもう1個用意して、反応してほしくない方の機器をそのリモコンと紐付けすればよいのだが、そのためだけにリモコンもう1個買ってくるのはさすがにもったいない。そこでおぱ、受光部にリモコンの光が入らないように覆ってしまえばいいと思って、試しに紙を置いたり手で覆ったりいろいろやってみたところ、このDockのセンサ、やたらと感度がよくて、受光部を指で押さえても上からでも後ろからでも、全然フツーに反応してしまうということが判った。もう「ホントに赤外線か? 実はコッソリBluetoothなんじゃないか?」とか思った。
    　もう、正面にぺたっとシールを貼れば済むとか、そういうレベルでは済まないということは判ったのだけど、とはいえせっかくリモコンがあって新しいMac Miniがあるのにそのリモコンが使えないのはとっても悔しい。ましてウチのMacはリビング兼台所に置いてあって食卓からリモコンでピッと音楽がスタートできるとヒジョーにカッコよくて便利なのだ。しかしそこでiPodまで反応して別の曲が同時に流れだしてしまっては台無しだ。ゲンナリだ。

    しょうがないのでとりあえず分解した。(えー)

    　リモコンの光はこの写真右側に写ってる白いプラスチックケースは簡単に透過してしまうみたいなので、このケースの外側でいくら光を遮ろうとしても、全体を真っ黒に塗り潰しでもしない限り効き目はなさそうだ。だから、ケースの内側、センサーそのものをガシッと覆ってやろうという魂胆だ。

    アルミテープでガシッと覆ってみた。
    その拡大図。

    　これで元通りにフタ閉めて試してみたところ、なんと! 前より反応しにくくはなったものの、ここまでやってもまだ10cmぐらいの距離で正面からリモコンを操作すると反応してしまう。呆れたが実際10cmぐらいの距離から操作することはないだろうし、そのうち電池が消耗して光が弱くなったらさらに反応しにくくなるだろうから、ということで諦めました。orz