2008/10/15(Wed)VistaからMessengerサービスが消えたらしい

2008/10/15 2:38 Software::Windows
先日、泣く泣くXP x64システムの不安定さ*1からVista x86に戻ってきたのですが、「チューンして高速化♪、まずはサービス当たりから~」とか考えつつサービスを開いてみると……

disappear_messenger_service.png


あれ、見慣れたMessengerサービスが居ない……。


今回Vista x86に戻したPCは、XP x64の時代から毎朝バックアップジョブが走っており、その完了通知を別PCにMessengerサービスで投げていたので、使えなくなるとちょっと困るなぁ。

と思ったものの、これはMSのセキュリティ対策なんですかね、Alerterとかも居ませんし。

そもそも、net sendコマンドが存在しなくなったようです。

C:\Users\Kero>net help /?
このコマンドの構文は次のとおりです:

NET
[ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
  HELPMSG | LOCALGROUP | PAUSE | PRINT | SESSION | SHARE | START |
  STATISTICS | STOP | TIME | USE | USER | VIEW ]


というわけで、某端末のIPPプリンタのMessengerサービスによる印刷通知、Vistaにシステムが変わったら別の方法をとらざるを得ないようですね……。

*1 : というか、Kasperskyとの兼ね合いでよくBSODになる

2008/10/13(Mon)MSゴシックの数字の2

2008/10/13 3:58 Software::Windows
Vistaで標準で、XPもWindows UpdateのJIS2004対応フォントをインストールすると、MSゴシックの9ptと10ptで、数字の2だけおかしな形になるという問題があります。
比べてみれば歴然。

▼正常
strange_font_1.png

▼おかしい
strange_font_2.png


ちなみに画面は、Vistaのメモ帳のフォント設定ダイアログです。
なぜこんなことになったかというと、小数点を表すドットの位置が右に寄ったことで、数字の2の左下と隙間がなくなるため、こういう措置になったらしいですが……。
小数点の位置だけを比べてみても、明らかに「正常側」のほうが自然に見えますよねえ?
Vistaでは多くの部分がアンチエイリアス処理がかかっているので、この2を見る機会はそうないといえばそうなのですが、ダイアログ系にはまだ多く使われているのが現状です。

続きを読む

2008/10/12(Sun)Vistaの管理共有にアクセスする

2008/10/12 3:20 Software::Windows
Windows 2000やWindows XP Professional、Windows Vistaに搭載されているファイル共有には、「管理共有」という特殊な共有がある。

Sambaネットワークでは、共有名の末尾に$を付けると隠し共有となって、一覧に現れないのだが、管理目的のためデフォルトでドライブレター+$という名前で、全固定ディスクのルートディレクトリが共有されている。
つまり、コンピュータ名をワークグループで見つけられれば、\\ComputerName\C$でCドライブが丸見えと言うわけだ。
勿論、セキュリティ的には保護されていて、管理者権限がないとアクセスできない。
Administratorのパスワードが空だとドライブ丸ごとがそのまま見えたりということもあり*1、やはりセキュリティ上の観点からか、Vistaではローカル以外からは、たとえ管理権限を持っていたとしても参照できなくなったようだ。

というわけで、再度自分でドライブごとに共有を作る*2しかないかと思っていたのだが、やはり面倒。
閉じた家庭内LANなどでファイルをやり取りする場合は、やっぱりドライブごと共有していた方が楽ということもある。
そういうときには、このレジストリエントリを追加すれば良い。
手早くやりたい人は、share_policy.regをどうぞ。
キー名
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
名前
LocalAccountTokenFilterPolicy
種類
DWORD(32ビット)
1
ちなみに0に戻すかエントリを削除すれば、デフォルトの動作に戻る。

*1 : XPでは空パスの場合は拒否されるはずだが、2000は通ってしまう

*2 : ただし管理共有で使われているC$, D$, ...という名前は使えない

2008/09/24(Wed)MTPモードのトラブル

2008/09/24 16:18 Software::Windows
最近の携帯電話やポータブルプレーヤーには、「MTP(Media Transfer Protocol)モード」という転送方法が数多く採用されている。先日のSH906iにもこの方式が実装されていた。
MTPはMicrosoftが開発した技術仕様で、それぞれのデバイスドライバを必要することなく、マルチメディアデータを標準インストールされているWindows Media Playerで転送することが出来る。DRMもサポートしていることから、マスストレージモードを搭載していない物などにもこのモードがあることが多い。(パナソニック等の製品にはSD-Audioという規格があり、これとは別。)


非常に便利なMTPモードであるが、Windows Media Player絡みのアップデートでうまく動作しなくなることがあるようで、実際に私がハマったので、そのトラブルシュートをご紹介。

現象

Windows Media Playerからは同期デバイスとして認識せず、デバイスドライバでは!マークが表示されている。
(IEEEコントローラが×になってるのは、ノートPCの消費電力削減のため、給電を停止しているからであり、本題とは関係ない。)
mtp01.png

mtp02.png


「ドライバの再インストール」を選んでみると、一見インストールが成功したように見えるのだが、最後に「このINFのサービスインストールセクションは無効です。」と難しいエラーメッセージが表示される。

mtp03.png


解決方法

先ほどもちらっと書いたように、これはWindows Media Playerをアップグレードしてしまうと問題が起こる模様。
色々とググってみたところでは「XPの修復インストールで直った」という情報が出てきたが、さまざまな部分が元に戻ってしまうのでこれは避けたい。
半ば勘に頼ってだが、私の場合は、WMAのエンコーダーに同梱されていた「Windows Media Format 11 runtime」をインストールしてしまったのが原因らしい。
Windows Media Player 10を使っているのに、11用のランタイムを間違えてインストールされてしまったのが原因かな?
Windows Media Player 11を使ってる人はこれをアンインストールしていいのか良く分からないが…。

▼これをアンインストール
mtp04.png



メッセージに従って、どんどん進む。
mtp05.png

チェックをつけて続行。ここのメッセージによると、保護されたファイルのライセンスは削除されるので再度取得せよ、とのこと。私はDRM保護されたファイルは管理していないので問題なし。
mtp06.png

mtp07.png

mtp08.png


ここで再起動

仕上げ

この段階ではトラブルを起こしているドライバが読み込まれているので、デバイスマネージャから一旦問題のデバイスを削除する。
それから、USBケーブルを挿しなおし、今度は認識されることを確認。

mtp09.png

mtp10.png

2008/09/14(Sun)screenでデタッチできない 解決編

2008/09/14 21:21 Software::Linux
screenでデタッチできないというのを書いたが、解決法発見。
デタッチできないというよりも、むしろアタッチできないという方が正しい表現だったようだ。

これはscreenの問題ではなく、回線が切れたときにsshセッションが切れず、sshdプロセスが生きたままで、その応答待ちでscreenがattachedから変化しない模様。

以下、対処法。
$ ps x | grep pts | grep sshd
13819 ?        S      0:00 sshd: kero@pts/2
13985 ?        S      0:00 sshd: kero@pts/8
14595 pts/2    S+     0:00 grep sshd

grepが走っているpts/2が現在操作中のポートなので、pts/8を落とす。

$ kill -KILL 13985

$ screen -ls
There is a screen on:
        9120.pts-0.spinel       (Multi, detached)
1 Socket in /var/run/screen/S-kero.

$ screen -r
これで自動的にdetatchされ(autodetatchがonの場合)再アタッチ可能になる。


が、いちいちこんな事やるのが面倒なので、自分以外のsshセッションを片っ端から強制終了するスクリプトを書いてみた。
最近Perlの正規表現にハマってたりなので…。/bin/sh+sedかawk…と思いつつも、慣れてる方が書きやすい。
だいたい検証したけど、killのとこだけは検証してない…。たぶん大丈夫。ちゃんと動きました。
screenの内側から実行しないように注意。
#!/usr/bin/perl
use strict;

(my $tty = `echo -n \$SSH_TTY`) =~ s/\/dev\///;
my $dead = `ps x | grep pts | grep sshd | grep -v $tty | grep -v grep`;
foreach(split(/\n/, $dead)){
    $_ =~ s/^\s*(\d+).+$/$1/;
    print qq|Kill pid=$_...\n|;
    `kill -KILL $_`;
}

参考元:http://subtech.g.hatena.ne.jp/cho45/20070517/1179373075