2015年12月27日日曜日

C#での文字列switchとDictionaryとReflectionとで速度比較してみた

やる前から結論は見えているようにも思えますが、MSVS2015の最適化能力とはいかばかりか気になったのであえてやってみました。

今回のケースは次の通りです。
  • クラス1つにつき1回のデータが入っていて、データ(メンバ変数)数は500。
    イメージとしては1クラス/1レコードといった具合です。
    但しそのデータはクラス内クラスによって区分されて保存されている。
    たとえば、
    class a{
      class aa{
       public float val1;
       class aaa{
        public int val2;
       }
       ...
       class az{
        public int val99;
       }

    のように。こういう具合で細分化された項目数の合計が500あります。
  • そのレコードが数万程度リストとして保持されている。
  • そのリストを、メンバ名で(イメージとしてはカラム名で)で横ぐしで集計したい。
という具合です。

クラス設計が悪い?
まったくその通りですが、文句を言っても解決にならんので、とりあえずなんか考えてみたいと思います。

いろいろ手法があると思います。クラスの構造をのべたんに開いて、ってこりゃ方言かな?、構造を展開してしまうとか別にリストを作り直すとか。

ここでは、あえて強引にメンバ名で当該クラスにアクセスしてデータを取得するという手法をとってみることにすることにします。イメージとしてはXPath式でデータにアクセスするような感じで。

当然、この場合、考えつくのはリフレクションを用いることです。
そして、まさしく当然のごとくアクセスできます。便利です。

ですが、リフレクションは遲いというのがもっぱらの評価です。
そこで、今回の比較と相成ります。

Case1. switch( メンバ名 ) の場合。
public float get(string member)
        {
            switch ( member )
            {
                case "aa.val1":
                    return aa.val1;

のような延々と500ものcase文が続く壮絶な関数を作って時間を計測してみました。(時間はあとでまとめて書きます。)

Case2. Dictionaryを用いた場合。
dic = new Dictionary<string, float>() {
                    { "aa.val1", aa.val1 },
  といった具合に、データを保持しているクラスがデータを収集し終えた段階で辞書をこさえておいて、アクセスする場合にはその辞書に対してキーとしてメンバ名を渡して値を得る方法です。

Case3. リフレクションを用いた場合。
単純にInvokeMemberメソッドでGetFieldする方法です。

上記の3例でかかった時間をStopwatchクラスで計測しました。(Core i7/たしか4770)
  1. クラスから1回全要素を取得するループの実行時間
     switchの場合:     50ms
     Dictionaryの場合: 12ms
     Reflectionの場合: 1ms
  2. 10回全要素を取得するループの実行時間
     switchの場合:     83ms
     Dictionaryの場合: 11ms
     Reflectionの場合: 9ms
  3. 100 回全要素を取得するループの実行時間
     switchの場合:     137ms
     Dictionaryの場合: 15ms
     Reflectionの場合: 94ms
  4. 10000回全要素を取得するループの実行時間
     switchの場合: 1072ms
     Dictionaryの場合: 379ms
     Reflectionの場合: 7938ms
面白い結果になりました。
10回程度のループ処理ならInvokeMemberで値を取得したほうが早かったんです。

逆コンパイルしたらswitch文のコードは文字列のハッシュをとったりして涙ぐましい最適化処理をコンパイラがやってくれていました。
しかし、辞書とリフレクションを用いた関数を利用して取得したほうは書いたままのコードでした。

私はGCがあるような言語は業務で使いたくないので詳しくないのですが、今回のような結果が出るとは思いにもよりませんでした。

面白い!実に奥が深い!!

なぜ回数が少ないとInvokeMemberが早いのか。
今回は考察まで踏み込めませんでした。ごめんなさい。
でも、こんなことがあるから後期中齢者になってもプログラミングがやめられません。

2015年12月17日木曜日

UnityではSystem.IO.Compression.GZipStreamが使えない

UnityではSystem.IO.Compression.GZipStreamが使えない!!
シリアル化したセーブデータを圧縮・伸長したいのに!!

と思ったらきちんと代替手段が用意されていたで御座候。
それどころかbzip2まで用意されてござる(遅いから今回は使わないけど)。

しかも、(おそらく)セーブデータなどでの圧縮・伸長用に考慮されているとみえ、streamとして扱える丁寧なつくりです。

私事ながら現在手掛けているC:SL用MODはシリアル化するとかなり大きくなるデータを扱うMODなのでSystem.IO.Compression名前空間のお友達に会えないとわかった時にはどうしようかと思いましたが、このおかげでセーブデータ長制限に引っかかる率も格段に下がってありがたい限りです。

使い方は超簡単。例えばリストア先クラスfooがあったとして、速度重視でgzipで伸長してシリアルデータからオブジェクトに戻す場合は、
BinaryFormatter bf = new BinaryFormatter();
using ( MemoryStream ms = new MemoryStream( savedata ) ){
  using ( GZipInputStream gs = new GZipInputStream( ms ) ){
    foo = bf.Deserialize( gs ) );
  }
}
MemoryStreamをコンストラクタへの引数にするだけ。
間に一枚かぶせるだけで済みます。圧縮(GZipOutputStream)の場合もまた然り。

・・・確かに標準のライブラリより多機能かもしれないけど・・・メンドクセ

2015年12月11日金曜日

Cities: SkylinesのmonoランタイムにはSystem.Type.op_Equalityメソッドがない

ようやくロード・セーブの方式も確立して、多言語化もほぼサポートして、基本的な雛形が完成したので、さあこれからだ!というところでいきなり躓きました。

データ保持用のクラスに項目を追加しただけで急に動かなくなりました。

Cities: Skylinesでのデバッグは仮に例外が発生していても本体側で握りつぶしてしまうのでどこで起きているかわかりません。
そのうえ、Unityの仕様だと思いますが、プロセスにアタッチしてもソースレベルではデバッグが不可能。
デバッグコンソールか自力でエラーログをファイルに吐くしかなくて、さらにスタックトレースを出そうとしても、トレース情報がランタイムによって消去されてしまって表示不可能ときた。

提供されているクラスライブラリのドキュメントがどこにもない(どう探しても見つからない!!)ので試行錯誤や諸先輩方の公開されているソースだけに頼っている上に、いまどきprintfデバッグが必要というとんでもない代物なのでなかなか進みませんが、ただメンバを追加しただけなのに急に動かなるとかいったいどういうことが起きているのかさっぱりわかりませんでした。

とりあえず怪しそうなところをprintfデバッグで絞り込んでcatchしてみると
MissingMethodException: Method not found: 'System.Type.op_Equality'
なる例外が。

このエラーは追加したクラスのメソッドを呼び出す際に発生していることが分かりました。
呼び出されるメソッドはただコンストラクタから呼び出されて変数の初期化をするだけの変哲もないもので、そもそもこんなメソッドを呼んだこともないし見たこともないので面喰いました。

調べてみると、これは.Net Framework v4で追加されたものだそうですが、monoはv4に対応しているものの、Cities: Skylinesの採用するミドルウェア(Unity)が古いmonoを採用しているため、v3.5相当の機能しか使えないことがやっとわかりました。

VisualStudio2015でビルドまでしてしまっていたので、v4.6がターゲットになっていたため、このトラブルに見舞われました。

最初からきちんと調べるか、ビルドはCities: Skylines側が提供するバイナリで行えばこのようなトラブルは起きえないのですが、自分の粗忽さから招いた自業自得でした。

また一つ、恥をかいてしまいました。

2015年12月9日水曜日

Cities: Skylinesのmodを作ってみよう

ということで、昨日から作り始めました。

assetじゃないよ。
modとassetをごっちゃになさっている方はそのままブラウザの戻るボタンを押下してくださいませ。

C:SLのmodはC#で書くんだぜ、ということらしいので久しぶりにC#触ったけど、なんだか以前触った時よりものすごく進化していますねえ。びっくりしました。

まあ、別にC#に精通するつもりはないのであんまり深く追っかけないことにして、とりあえずひな形としてIUserModを継承したクラスを作って、NameとDescriptionを返せばとりあえずは体裁が整います。

でもこれだけじゃ意味がないので、UI画面を作るにはUIPanelから継承したクラスを作って、それをLoadingExtensionBaseを継承したクラスメンバのOnLevelLoaded()で、

UIView.GetAView().AddUIComponent( typeof( "UIPanelから継承したクラス" ) )

とするとUI画面ができました。

画面が出てしまえばもうこっちのものなので、今度はその画面に表示するデータをセーブファイルに紛れ込ませる方法は、ISerializableDataExtensionを継承したクラスを作るだけ。

C#のすごいところは、リストを含んでいようがインナークラスを含んでいようが、いとも簡単にシリアライズできてしまったところ。
これは実に驚きました。

うーん、なんて楽なんだ・・・

ポインタがある言語ではクラスや関数が多種類あるけど呼び出し形式もとれるデータ形式も同じだよ、というような場合の処理は関数やメンバ変数へのポインタが大変便利ですが、メモリ管理が自分でできない言語だと多少厄介です。
その点、javaと同様にC#もリフレクションが充実しているようです。
おかげで、メンバ名で直接メンバの値を操作できるような仕組みが実装できました(でもやっぱりポインタのほうが分かりやすいなぁ・・・)。

たとえば、

public class foo{
  public bar piyo ;
  public foo(){
    piyo = new bar();
  }
  public class bar{
    public int hoge;
  }
}

なクラスに"piyo.hoge"というメンバに"文字列で"アクセスしたいなぁ、といったときに

float getValueFromMemberName( object topobj, string member )
{
string[] arrays = member.Split( '.' );
object obj = topobj;
for ( int i = 0 ; i < arrays.Length ; i++ )
{
Type t = obj.GetType();
obj = t.InvokeMember( arrays[i], System.Reflection.BindingFlags.GetField, null, obj, null );
}
return (float)Convert.ChangeType( obj, typeof( float ) );
}
という関数をでっち上げて、topobjに new foo() したオブジェクトを指定して、memberに文字列で"piyo.hoge"と指定してやると、hogeの値が(intなのに)floatで頂戴できるという寸法。
まあ、ポインタが使えない苦肉の策なんですけども、javaとかC#のような言語ならではですねえ。

いまだにCSLのライブラリ群のドキュメントを見つけられていないんですが、VisualStudioのオブジェクトブラウザでメソッドやクラスを眺めているだけでだいたい見当がついちゃったのはこの手の言語ならではでしょうね。

基本的な表示とセーブデータへの私のmod固有のデータのセーブ・ロード方法が分かったので、あとはきちんとUIを作るだけになりました。
ドキュメントが全然ないフレームワークに乗っかっても1日でここまで来るとは思いにもよりませんでした。

あとは、同じようなmodが先に公開されませんように祈りつつコーディング作業を急がなくては。。。

2015年11月27日金曜日

opensslでこさえたオレオレ認証局からWindows向けのコードサイニング用証明書も発行する

現時点でオレオレ認証局を運用していて、当然クライアントにもオレオレルート証明書が入ってる人向けの、とても需要がないこと請け合いの記事です。

なお、EVコード署名証明書の話題ではありませんので念のため。
あれはWHQLが通らない開発元でもMicrosoftに署名してもらいたい時に保証人業者が自分のことを証明してくれてるから信じてね!、という提出用書類なのでこの話題とは関係ございません。

さて、最近はクラウドだとかで個人で使うにも敷居がどーんと下がってきて需要が下がってきていることとは思いますが、まだまだ現在でも個人や小規模なグループで、自分たちの存在を第三者に証明する必要はないが自分たちがサーバにアクセスする際には経路の暗号化は必要ですから、やっぱりオレオレ認証局と証明書は便利です。

それにタダですからね。
コマンドを打ち込む時間を抜きにすれば。

ところで、最近、Windowsはちょっとしたオレオレドライバも証明書を付けないとロードしてくれなくなっています。

ついにWindows10はカーネルモードドライバに限っては必ずMSの認証が必要になってしまって、あまり大きくない測器屋さんとかの独自ハードを作っておいでのところや、個人で大枚払ってコードサイニング証明書を買ってまで自作ソフトを公開していた方が、さらに新しい証明書を買わないとダメですよー的にごっそり切り捨てられて、一部界隈ではちょっとした話題になっちゃいまいた。

ソフト屋としては自由度が減れば減るほどちょっと寂しいのですが、一方で「なにもしてないのに」ウィルスにかかっちゃうエロおやじうっかりさんどころか、本当にまっとうと思われていたサイトにアクセスしても、広告が乗っ取られていてFLASHとかブラウザの脆弱性のせいでウィルスに冒されたり、サイバー攻撃を受けたら軍事的攻撃とみなす、とか、米中首脳会談の主要議題の一つにまでなってしまうとか、ことほど左様にコンピュータへの攻撃が激しい昨今ですから、笑い事ではありません。まさに生き馬の目を抜くような、という世界に一般の人までも巻き込まれてしまう情勢です。そこに「PCってなんスか?」とか、情報教育を受けたとか聞いていたはずの若者が雪崩れ込んで来て、もはや阿鼻叫喚の地獄絵図です(情報教育ってなんスかね。年寄りには想像もつかないわ)。

Microsoftだって商売ですから、自由にモノづくりができる環境と安心して作業できる環境とでは、もはや後者を優先せざるを得ないでしょうし、この流れはWindowsだけでは済まないだろうなあ、と思います。

話がずれてしまいました。
そんなこたぁオレオレ前提な以上、使う側はわかって使うのでどうでもいいわけで、実際にはWindowsでも起動オプションで署名されていないドライバでもロードできるわけです。

が、ちと、手続きが面倒くさい。

そこでオレオレコード署名証明書の出番となるわけですが、どうせテストだから、仮だから、とか言って適当に作りまくっていると証明書ストアが汚れていくのでなんかイヤ。

しかも、そういう向きにはオレオレルート証明書は使用しているクライアントに当然入っているわけです。

従って、そのオレオレルート証明書を発行した当のオレオレ認証局にオレオレコード署名も発行してもらえばいいわけです。

win-win, *nix-*nixなら別にどうということもないでしょうから、ここでは、opensslで構築したオレオレ認証局に署名してもらったコード署名証明書をWindowsのデバイスドライバに署名する方法を記述します。

やるこたぁ単純です。ですが、自分がどの立場で作業しているか、だけは意識してください。
※ 当然認証局がコード署名に対応していないとダメですよ!
opensslの定義体の [ v3_req ] の keyUsage  エントリで、codeSigningが指定されていることを確認してくださいね!
Ex). keyUsage = nonRepudiation, digitalSignature, keyEncipherment, codeSigning

具体的には以下となります。
  1. opensslで構築した認証局側で、オレオレコード証明書を認証してください、とオレオレ認証局に対して申請書を書きます。
    その申請書のために、まず秘密鍵を生成します。まあ、長さは2048でいっときましょう。

    # openssl genrsa -des3 -out オレオレコード認証秘密鍵 2048

    ※ オレオレコード認証秘密鍵は、せめてchmod 600しておいたほうがいいですね

    次に、実際のコード署名証明書の申請書を書きます。
    今はやりのSHA-256がいいかな、と。

    # openssl req -new -sha256 \
                -config  あらかじめCN等を定義しておいた定義体があるなら指定してください \
                -days 10000日くらい。どうせ近いうちにまた暗号強度がドーとか言われて作り直しさ \
                -key オレオレコード認証秘密鍵 \
                -out 認証要求のお願いの申請書
  2. コード証明認証要求が届いたので、今度は認証局側の立場で申請書を認証します。

    # openssl ca \
                 -config  認証局を作った時の設定ファイルを指定すると楽です \
                 -in 認証要求のお願いの申請書 \
                 -cert 認証局の証明書 \
                 -keyfile 認証局の秘密鍵 \
                 -out オレオレコード署名証明書
  3. オレオレコード署名証明書が届いたので、今度は申請者側に戻ってWindowsでも利用できる形式に変換します。

    # openssl pkcs12 -export \
                 -in オレオレコード署名証明書 \
                 -inkey オレオレコード認証秘密鍵 \
                 -out Windowsで署名するためのpfx形式のファイル.pfx
  4. 実際にWindowsでファイルに署名します。

    X:\signtool.exe sign  /a /f Windowsで署名するためのpfx形式のファイル.pfx  /p パスワード 対象ドライバ名.sys

    ※パスワードは平文です。。。

    なお、signtool.exeは各OSのSDKに入っています。
    Windows10 は こちら

    説明するのが楽なのでVisual Studio の Community Editionを推薦する人も多いんですが、自分がライセンス的に使えるかどうかだけはどうか意識してください。
    さもないと真綿で自分の首を絞めることになります。
    MSは確かに昔から開発者に対して親和的だと(個人的には)言って憚りませんが、不正利用が蔓延ってしまったら彼らだって手を引いてしまいます。
うーん、なんだか和文で書くとかえってわけがわからない感じになってしまった気もします。
そもそも、こんな話題、誰が読むんだろうか。
そして、読んでいただいたとして、まさに釈迦に説法ではなかろうか。

何でこんな記事を書いたかというと、某所で壮絶な勘違いを見てしまって。。。
いやまてよ、自分が壮絶な勘違いをしている可能性のほうが高いですね。経験上、バグを見つけたら原因は自分をまず疑うと解決が速まりますから。

なお、当然ながらsecdrv.sysの署名m




2015年11月24日火曜日

タスクバーが半ギレ

エクスプローラってしょっちゅうおかしくなるので、タスクマネージャでも特別扱いにされてほかのプロセスでは出来ない「再起動」というメニューが用意されてますから、いまさら驚くことではないのかもしれませんが、こればかりは本当に初めて見ました。
(Microsoft Windows 10 version 1511)

タスクバーの描画が面白いことになっています。


長すぎて見えませんねえ。

まず前半。



なぜかタスクビューボタン以後、アイコンの下半分が描画されていません。

で。

通知領域のほうはというと、


今度は上半分が描画されていません。

なんて器用な障害の作りこみをするんだろう。
見た時にスゴイ感心してしまいました。

思わずSSをとってしまったので、折角ですので記録しておきます。

オモチャオモチャといじめすぎておこなの?
激おこなの?

?・。・?

2015年11月23日月曜日

cpufreqにおけるondemand時での最大動作速度を指定する

恥の記録です。

前置きです。
CentOS5でHandBrakeで過去にmencoderでエンコードしたファイルをh265形式に一括変換するバッチを流して1日放置。

平均処理速度が1~2fpsしか出ていない。
・・・何かがおかしい。

こうして、自分の愚かさにまたもや向き合うこととなりました。

原因はcpufreqがondemandになっていて、ondemand時のcpu速度の上限が1.2GHzになっていたからです。

なぜ愚かかというと、以前仮想マシンの関係でクロックがコロコロ変わるとゲストOSの時計がひどく狂う問題があって、cpuspeedは停止設定にしていたのに、元に戻ってしまっている点と、HotSaNICの記録から、元に戻ったのは1年以上も前だったことが分かったことです。

仮想マシン上で動かしていたゲストOSはあるシステムの検証用に必要だっただけで、検証が済んだ後は起動していませんでしたから時計が狂うという点からは気づきませんでした。

重い日例、週末、月末バッチは、終了後に結果をメールで確認しますが、受信時刻を特に気にしたこともなく、ここからも気づけませんでした。

日常使う上でも、特に重い処理なんてでかいパッケージのmake作業くらいですし、時間がかかることは元からわかっていますから、まさかcpuの動作周波数が抑えられているとは考えつきませんでした。

以前のエンコードが遲くて気づかなかったのは、ぶっ壊れたサーバのCPUの上限周波数が1.6GHzだったので、1.2GHzとそう大して変わりがないので、これもやはり気づきませんでした。

今回の変換処理では変換記録をログに残すようにバッチを書いておいたので、処理時間を見てみると、最大8時間もかかっているのがあってびっくりしましたが、時刻を見ると日例と週末バッチが重なる時間帯だったのでこれは除外して、他を調べると、特に負荷がかかるはずがない時間帯の処理でも5時間半かかっています。

しかし、今回導入したTX1310 M1は2.7GHzのcpuを乗せています。
いくらなんでもオカシイだろう、とようやく気付いたのでした。

本当に自分は頭が悪いんだと思います。

で、/proc/cpuinfoを見てみると、cpu MHz : 1200.000 となっているじゃあありませんか。
こりゃあcpufreqだな、と、やっと見当がついたので
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
を見てみると、しっかり1200000と表示されました。

そこで、/etc/sysconfig/cpuspeedを開いてみるとMAX_SPEEDに1200000が指定されていました。。。

ファイルの日付を見ると、最終更新日時が2008/03/20 14:09:24でした。
うーん、2008年・・・前代のExpress5800が2007年だったからCPU速度は1.6GHzなのになぜ1.2GHzを指定してあるのか、さっぱりわかりません。
それ以前も、壊れたサーバからHDDを乗せ換えてそのまま利用していますが、そもそも1.2GHzのCPUなんて使ったことないんですよねぇ。

どのタイミングでondemandになったかもわからないし、そもそもcpuspeedは起動しない設定にしてあったはずだし、謎の周波数が指定されているしでわけがわからないのですが、どれもこれも確かに自分でやった所業のはずなのにすっかり忘れている挙句に、cpuが遲いから調べることとなるという愚かさは我ながら救いようがありません。

さて、ほとんど前置きで書いてしまいましたが、本題です。

私の場合は愚かさによるものでしたが、CPUの性能にかかわらずにCPUの周波数を変更したい場合はあると思います。
  • 長時間CPU資源を占有するプロセスを起動する必要があるが、速度は求めていない場合
  • 温度が上がりすぎるのを抑えたい
  • 電気代の節約
  • 重いプロセスが走るはずがない時間帯に突発的にクロックが上がることを抑止したい
などなど、いろいろ考えられると思います。
そんな場合はcpufreqのondemandガバナで対応できます。
/sbin/lsmod して cpufreq_ondemand  が読み込まれていればondemandが有効になっています。
なっていない場合は/etc/sysconfig/cpuspeedで
GOVERNOR=
の行の右辺に別のガバナが指定してあると思いますので、デフォルト値がondemandなのでカラにしておくか、明示的にondemandと記述し、cpuspeedを再起動します。

上限周波数は直接/sys/devices/system/cpu/cpu*/cpufreq配下のファイルを書き換えてもいいです。
時間帯ごとにcronでスクリプトから直接制御するなどの用途ならこちらのほうが簡単かもしれません。
scaling_max_freqを書き換えるだけです。

手動の場合はコア数が増えると面倒ですからcpufreq-utilsパッケージを導入したほうがいいでしょう。cpufreq-set というコマンドがありますので、それを使用すれば簡単です。

デフォルト値として上限を設定しておきたい場合は/etc/sysconfig/cpuspeedファイルにMAX_SPEEDという左辺値がありますので、右辺にクロック数を指定します。
指定可能なクロック数のリストは
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies 
に記述されていますので、その中から選択します。
scaling_max_freqを直接書き換える場合も同様です。

ただ、ondemandは最低と最大の2値しかとらず、瞬間湯沸かし器のようなヤツですので、本来であればconservativeをガバナに指定したいところですが、CentOS5は対応前のカーネルなので使えません。

普段は上限にソコソコの値を指定しておき、本当にcpuパワーがほしい時だけ手動でガバナをperformanceに切り替えたほうが筋としてはいいのかもしれません。

・・・万が一、これと同様の考えで2008年にcpuspeedの設定を自分で書き換えたとしたら、それをずっと忘れているんだからやっぱり愚かとしか言えません。

以上、恥の記録とおまけでした。

2015年11月22日日曜日

CPU資源を特定のプロセスに使わせない方法

HandBrakeって、昔はできたような気がするんですが、CPU資源を制限するオプションが消えてますね。記憶違いかなあ、ず~っと以前に使ってみてすぐだめだと思って採用を断念したときにはあった気がするんですが。

まあ、わざわざCPU資源を制限する場合というのもあまりないのですが、プロセスの優先度だけだと、結局全部の資源を持っていかれるので、高TDPを誇るCPUさんが搭載されているシステムで急がないけどほっとくと長時間高負荷になることが事前にわかっているプロセスさんにちょっと遠慮をしていただきたい時や、マルチスレッドだとかえって性能が落ちてしまうプロセスさんに指定するときに有効です。

で、コマンドラインでお手軽に特定のプロセスのCPU資源を制限する方法って意外に知られていないので、とりあえずご紹介します。

*Windowsの場合
Vista以後はアカウントごと制限をしてしまう方法と、プロセスごとに制限する方法があります。
前者の機能は当時Windows2000からのNT5.0系(XP含む)からVistaになってNT6.0に確かに進化した、と思った機能の一つです(Windows10はいきなりNT10.0になりましたが、機能より政治的理由がvernoのインフレを招いているように見えますが・・・ま、命名者の勝手ですからね)。確かにちゃんとOSに近づいたぞ、的な。

アカウントさえこしらえてしまえば、レジストリにちょこっと制限帯域を登録するだけなので、お手軽です。
しかし、アカウントごとまとめて制限してしまう方法は本当にすっっっっばラシイのですが、アカウントを作成したりする手間があるので、今回は臨時に指定する方法をご紹介します(意外に知られていないらしいのですよね。処理を早くするほうはみんな関心がありますがわざと遅らせるという方面の情報があんまり知られていないようです)。

起動後で制限するならタスクマネージャで可能です。詳細画面で対象のプロセス名を右クリックメニューから「関係の設定(F)」を選択するだけです。

コマンドラインから起動時に制限してしまう場合はstartコマンドを使います。
start /affinity オプションで指定しますと、使用するCPU(但し、HTT、ハイパースレッディングが有効なCPUは実コア数ではなくて仮想コア数で指定します)を制限できます。
バッチファイルなどで活躍してくれますのでこっちのほうの需要が多いでしょう。

ただ、ちと指定方法が特殊です。数を指定するのではなく、使いたいCPU(またはHTTによる仮想コア)をビットフィールドで指定します。

例えば、CoreI7機であれば実コア4,HTTのため8コアに見えてしまいます。
ここで、コア番号01234567があったとして、使いたいコアを1、使いたくないコアを0として2進数を16進数に変換した値を指定する必要があります。

例1: コア番号0と7だけ使わせたい
 -> 2進数で 1000 0001 なので 16進数に直すと81
     start /affinity 81 notepad.exe
例2: コア番号0から5まで使って2ツ開けておきたい
 -> 2進数で 0011 1111 なので3F 
     start /affinity 3f notepad.exe

といった具合です。

*linuxの場合
確かカーネル2.6からでしたか、こちらも実装されています。
taskset というコマンド名で、windowsと同じようにマスクを16進数で指定します。
tasksetはタスクマネージャとstartコマンドの機能を同時に実現できます。
つまり、pid指定で後追いでCPU資源を制限することも、起動前に制限しておくこともできます。
まあ、windowsとちがってmanページもありますから、コマンド名さえわかればもうどうにでもなるでしょう。

以上、HandBrakeがらみで思い出したので、記録しておくことといたしました。

2015年11月21日土曜日

HandBrakeCLI 0.10.2 をCentOS5向けにビルドする

まだlinux版ではQSVも使えませんし、こんな間抜けなことをするのは世界中でもわずかでしょうから一応メモ。もっとも、QSVはh264。Windows10で視聴するならh265でしょう!!

ってことで。

200x年代にエンコードしたタモリ倶楽部をもっと圧縮すべく、HandBrakeさんにお願いするとしましょう。
CentOS5ではFFmpegやらmencoderはしがらみが多すぎて最新版にするのが面倒くさいという事情もあります。FFmpeg vs libavの抗争に巻き込まれるのも面倒ですしね。

早速、HandBrake-0.10.2.tar.bz2を展開したら
./configure
すると./buildに入ってmakeしろという指示が出るのでmakeします。

すると、libdvdreadやlibdvdnavなどでコンパイルに失敗します。
CentOS5のautomakeが古いためで、この場合、configure.acでエラーが発生している場合、以下の4パターンが起きます。
  • aclocal -Im4 オプションなんか知らねえよと怒られる。
     -> configure.ac中に
           ACLOCAL_AMFLAGS = -Im4
        という行があるので -I m4 というようにホワイトスペースを挿入する。
  • AM_PROG_CC_C_Oが未定義と怒られる
     ->configure.acの適当なところにAM_PROG_CC_C_Oを追記。
    ま、要するに最近のautomakeでは廃止されるマクロを使わないでくれという要請に従っているプログラムがエラーになるので、廃止されるマクロをいちいち追記するということです。
  • AC_PROG_LIBTOOLが未定義と怒られる。
     ->configure.acの適当なところにAC_PROG_LIBTOOLを追記。
  • AS_CASEがどうたらと怒られる。
     ->configure.acのAS_CASEの行はlinuxとは関係ないので丸ごとコメントアウトしてしまう。
また、Makefile.amで docdir未定義、と怒られたら、
dist_doc_DATA = AUTHORS ChangeLog COPYING README TODO
という行があるのでコメントアウトしちゃっていいです。
我ながら乱暴ですが、まるで問題ありませんのでご安心ください。

ちょいちょい上記のようなエラーで止まりますが、コンパイルそのものはgcc4.1.2でも通ります。有難いことです。

但し、期待されているライブラリやファイルがなければ当然ヘッダがねーよとかライブラリがねーよ、というエラーは出ます。
私の場合は以下を追加で入れました。
baseリポジトリになければrpmforgeにあります。

libass-devel
libx264-devel
lame-devel
libogg-devel
libvorbis-devel
libsamplerate-devel と libsamplerate
fribidi-devel と fribidi
bzip2-devel
intltool
perl-Compress-Zlib
perl-HTML-Parser
perl-HTML-Tagset
perl-XML-Parser
perl-libwww-perl

まあ、ヘッダがないとかライブラリがないとか言い出したら適当にrpmを見繕って突っ込めばいいです。パッケージャの皆さんありがとう!!

但し、libtheora-develだけは残念ですが利用できません。
CentOS5向けのパッケージは古いのでヘッダもライブラリも足りないからmakeが通りません。
古いlibtheoraはgnomeやmencoderが依存しまくっているので消さずに残し、別途ビルドして/usr/localに突っ込みます。

今回はlibtheora-1.1.1.tar.bz2を利用しましたが、ビルド方法は、これまたありがたいことに./configureを実行後、make installするだけです。
defaultで/usr/local配下に展開してくれるようになっています。

あ、LD_LIBRARY_PATHはお忘れなく。DLLがないよ、と怒られますからね。

最後に
No package 'gtk+-3.0' found
No package 'gio-2.0' found
No package 'libnotify' found
No package 'dbus-glib-1' found
No package 'gudev-1.0' found
というエラーで止ってしまった場合ですが、GUI版がほしい人は要求に従ってください。
今回はHandBrakeCLI自体はできているので無視して終了です。
お疲れ様でした。

早速、以前にmencoderでオリジナルtsの1/3程度にmpeg4でエンコード済みのファイルを早速h265で再エンコードしてあげると・・・さすがにIntel(R) Celeron(R) CPU G1820 @ 2.70GHzでは4~5時間かかります。

同一ファイルを同一オプションでCore-i7機で処理すると3~40分です。
但しCPU温度は90度を越えます。G1820のほうは26度程度です(設置場所が違うとか諸条件がまるで違うのですが)。

そして、出来上がってみると音声がずれています。
オプションに音声をコピーするよう指示してあってもです。

ここからがHandBrakeの楽なところですよね。コマンドラインに--cfrを指定してあげるだけで固定ビットレートになるので音声がずれなくなります。

-q 28 の場合、実に 205 MB までスリムになりました( -q 20 の場合は 622 MB でした)。

すげえ...

これでタモリが100歳超えても大丈夫。
長生きしてくださいね!!

私が先にくたばること請け合いですが。

*** ご参考 ***
変換元ファイルを作成した時のmencoderのオプションは以下でした。
-demuxer lavf \
  -vf harddup,crop=0:0:0:0,scale=1440:-2 \
  -sws 9 \
  -ovc lavc \
  -lavcopts \
vcodec=mpeg4:vbitrate=6000:vmax_b_frames=0:vme=4:mbd=1:autoaspect:dia=1:vb_strategy=0:predia=1:last_pred=0 \
  -af volnorm=1 \
  -oac mp3lame \
  -lameopts aq=5:cbr:br=192

変換先を作成するHandBrakeのオプションは以下でした。
-e x265 --h265-profile main --modulus 2 -q 28 --cfr --aencoder copy

2015年11月19日木曜日

PT3が突然動かなくなった原因

以前こちらで記事にした、PT3が突然動かなくなった理由が今頃わかりました。
恥の記録として残しておきたいと思います。

たまたまWindows10のデバイスドライバに関連した事柄を調べていると、偶然このトラブルの原因が分かりました。

結論から言えば、PT3のドライバがミドルウェアとして採用しているWinDriverがWindows10上では試用版として作動したため、試用版の制限として30日後に使用できなくなるという仕組みによって、突然使用できなくなったように見えたもののようです。

最新のPT3用ドライバ4.0はミドルウェアもWindows10に正式対応したものを採用しているため、その後は問題なく使えた、ということでした。

要するに、対応していないOSで勝手に使って自滅しただけという、いつも通りの恥ずかしい行いが原因というわけでした。

ともかく、原因がわかって大変すっきりしました。
あの時は「何もしてないのに?!」とちんぷんかんぷんでしたが、実際には何もしてないどころか「1月前にOSを変えた」というとんでもない不始末をしでかしていたのでした。
我ながらなんと愚かな考えを抱いたことが恥ずかしい。

動作対象OSでもなんでもなかったデバイスなのに素早くWindows10に対応してくれたメーカにもあらためて感謝の念がわきました。

ところで、試しに、Windows10にPT3用ドライバを動かなくなった日の30日前にインストールしたのか調べようとすると、驚いたことにThreshold2に更新する前のイベントログが見事に消されていました。。。

クリーンインストールならともかく、更新前のログを消す必要がどこにあるのか、というよりログなんだから引き継がないと何の意味もないだろう、とマイクロソフトさんとの考え方の違いに思いを致しつつ、さすがにWindows.oldには残っていた(というより引き継がずに放置されていた)ログファイルで確認したところ、確かに、当方の場合は 2015/09/04 にPT3用ドライバをインストールしていました。
バージョンは以前に記しました通り、3.1(WinDriverのバージョンは11.6.0とリリースノートにありました)ですので、早朝5:30まで動いていたのは若干不可解ではありますが、9月は30日ありますから、31日目に起動しなくなったので辻褄は合います。

ただ、いまさらですが試用版として使用しているならその旨をユーザに表示するとミドルウェアの開発元のホームページにはありますが、当時そんなメッセージなどどこにも出ていませんでしたし、イベントログを再びじっくりと調べても一切そのような記録は残っていませんでした。これが機能していたらすぐにスッキリできていたのですが、ちょっと残念です。

2015年11月17日火曜日

Windows10 Threshold 2 でまたまた増えた回復パーティション

Windows10初の大型アップデートと言われるThreshold 2が世に放たれました。
なにしろここ最近のWindowsはアップデートと言いながら何をしでかすかわからないので、世間様の様子を見てから入れようと思ってアップグレードを延期していましたが、特に大きな問題も起きていなさそうなので本日アップデートしてみました。

表題とは関係はありませんが、試しに再起動を求められたときにWindowsUpdateの設定を「アップグレードを延期する」に戻してリブートすると、正しく更新に「失敗」しました。
これは今後うっかりダウンロードされちゃったけどしばらくPCが使えないのは困る!というときに助かることになるかもしれません。

しかしいやあ、驚きました。
アップデートというよりほとんどOSの入れ替えを行うようなシロモノじゃないですか、これ。
それほどの改良点が本当にあったのか?これ。。。

おまけにアップグレード直後は開けていたのに数分経つとスタートメニューも電卓も開けなくなってしまいました。
ユニバーサルアプリだかストアアプリだか知らないが、どっちもそっち系統のプログラムなのでイベントビュアを見てみたら、延々と

アプリ Microsoft.WindowsCalculator_(略)!App のライセンス認証がエラーで失敗しました: アプリは必要な時刻に開始されませんでした。。詳しくは、Microsoft-Windows-TWinUI/Operational ログをご覧ください。
とかいうメッセージが山ほど記録されていました。再起動したら直りましたが。。。テストしてんのかねぇ。
(ていうかWindows10の電卓、ユニバーサルだかストアだか知らないけど異常に起動が遲いので以前のcalc.exeに戻させてほしい・・・)

どうでもいいけどCortanaもさん付けしないとガン無視くれるし、たいていBingの検索結果が出るだけだし、しかも音声合成の名前が私と同じ名前ってのが妙に小馬鹿にされたような気がする(どういう僻み方なんだ?)。

で。
OSのアップグレード並みなことをしたってことは・・・
今回も。
期待通りに?

そう、期待通りに!
どどーんと回復パーティションが増殖いたしました!!
やったね!

でもなあ。500MBの回復パーティション(Windows10無印クリーンインストール時に作成したもの)ではダメなのかな。TH2に更新した際に新しく追加されてしまったのは450MBで、Windows10無印をクリーンインストールした場合に自動で作られる容量と一緒なんだけどなあ。

まあ一応念のため、どっちの回復パーティションを使っているか確認してみました。
X:\>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:
    Windows RE の状態:         Enabled
    Windows RE の場所:         \\?\GLOBALROOT\device\harddisk0\partition5\Recovery\WindowsRE
    ブート構成データ (BCD) ID: 58b89e97-52d3-11e5-af67-b1d0abcb4533
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0
新しいほうを使っているみたいです。
まあそうだわな。

不思議なのは、回復ドライブが増えてない人もいるんです。
というよりも、今回はそんな話は検索しても出てこないので、私だけなのかも。ちょっとだけ増量して500MBにしてあげたことがWindows10TH2さんの逆鱗に触れてしまったのでしょうか。

Windows8->8.1の時は350MBの回復ドライブの中身が空っぽにされていましたが、今回はどうなのかな、と思ってドライブレターを振って中身をのぞいてみると。。

パーティション1(Windows10無印の回復パーティション)
X:\>dir recovery\windowsre /a-
 ドライブ X のボリューム ラベルは Recovery です
 ボリューム シリアル番号は F4D5-A812 です
 X:\recovery\windowsre のディレクトリ
2015/09/04  16:19    <DIR>          .
2015/09/04  16:19    <DIR>          ..
2015/07/10  19:59         3,170,304 boot.sdi
2015/09/04  16:19             1,032 ReAgent.xml
2015/07/11  01:13       322,790,888 Winre.wim
               3 個のファイル         325,962,224 バイト
               2 個のディレクトリ     181,395,456 バイトの空き領域

あれあれ。今回はしっかり中身が残っていますね。
ついでにパーティション5の450MBの回復パーティション(TH2で追加されたもの)をみると
Y:\>dir /a- Recovery\WindowsRE
 ドライブ Y のボリューム ラベルがありません。
 ボリューム シリアル番号は 008F-E467 です
 Y:\Recovery\WindowsRE のディレクトリ
2015/11/16  21:32    <DIR>          .
2015/11/16  21:32    <DIR>          ..
2015/10/30  16:17         3,170,304 boot.sdi
2015/11/16  21:32             1,041 ReAgent.xml
2015/11/16  20:53       350,347,938 Winre.wim
               3 個のファイル         353,519,283 バイト
               2 個のディレクトリ     101,474,304 バイトの空き領域
だそうで。
しかしなんですねえ。多少大きめに作っておいても回復パーティションが増殖しちゃうんですねえ。
でもデフォルトの450MBのままの人でも増殖しない人がいる。

もうこれ、わかんないわ。

まあ、面倒なのでまだやってないけど、今回は容量的に元の回復ドライブに移してreagentc.exeで再指定するだけで済みそうではありますが、回復パーティションを利用するシーンもメディア作成ツールが公開されているおかげで思い浮かばないし、そもそもHDDがいかれしまえば回復パーティションも一緒にお星さまになるほうが可能性が高いし、今後もアップグレードのたびに同じことを繰り返すんだろうから、もう削除するだけにしちゃおうかなあ。

古いゲームはできなくなるし、相変わらずタブレットで使ってもらいたいのかPCでも使てもらいたいのかどっちつかずの半端なUIだし、OS入れ替え級の更新がWindowsUpdateでお気軽に適用されちゃうしで、なんだか迷走しているようにしか見えないんですよねぇ。
このままだと、やっぱりWindows11がリリースされちゃう事態になるんじゃないかなあ。

2015年11月16日月曜日

Cities: Skylinesをやってみた その3

ふと気づくと膨大な時間を費やしていて「自分はいったい何をしていたのだろう」と自問自答することがわかっているのにも拘わらず、やっぱり起動してしまうのは典型的な中毒症状なんでしょうね。

わざわざdespawnさせないmodを入れて数十キロに及ぶ渋滞を見事に解消できた瞬間の醍醐味はたまりません。

主に渋滞の原因となるのは道路も線路も貨物輸送です。
特に貨物駅前の渋滞は深刻になりがちですが、実は割合簡単に貨物駅前の渋滞は解消できます。渋滞してしまうのは主に

  1. 貨物駅から出た車両がスムーズに目的の商業施設に到達できずに途中で信号待ちや交通量の多い車線と合流させていて渋滞してしまう
  2. 輸入(市内移送を含む)に加えて輸出車両が多すぎて貨物駅への帰還と搬入速度が追い付かない
の2点が主な原因となりますが、項番1は単純に目的地近くまで遅滞なく到達できる道路を引けばそれでしまいです。というよりも、これを行うことがまず大前提です。なのでおいておくとして、深刻なのは項番2です。
こうなると貨物駅の増設が最も効果的ですが、小手先で何とかしたい場合は貨物駅へのアクセス口を若干工夫すると搬入速度が上がります。

例えば、以下のような直線道路に沿って貨物駅が敷設されている場合、計測してみると41両/毎分程度、貨物駅に入場できます(画面では速度3になっていますが、計測時は速度1でカウントしました)。
一方、以下のように搬入するトラックをなるべく減速させないように入口を工夫して計測してみると、47両/毎分まで搬入可能になります。
両者とも数回づつカウントしましたが、概ね誤差は0~1両でした。
20%弱の搬入量の向上が見込めますので、「あと少し搬入速度が速まればなんとかなる!」という場合には有効かもしれません。
ですが、やはり王道は輸出入量に合わせた貨物駅の増設ということになると思います。

まあ、道路は引き方次第で結構どうにでもなるのですが、貨物列車の渋滞はかなり厳しいです。
勿論貨客分離は当然のこと、さらに外部につながる貨物駅は限定する、渋滞した貨車が経路を分岐点を塞がないように線路を引くことを前提としていても、

たとえば、こーんなのや、

 こーゆーのや、
 こーんな具合に
画面が続く限りに貨物列車がイモムシの行列のように延々と画面に収まらない長さで連なってしまうと途方に暮れてしまいます。
まさに圧倒的な物量作戦で都市を破綻させる恐るべき事態に見えます。

しかし、原因は簡単で、貨物駅の荷捌き時間がかなり遅いにもかかわらず、一駅に集中させすぎているから列車を捌ききれずにこんなことが発生するわけです。

そんな時は、経路ツールmodで貨物駅から出場する貨物トラックが最も多く向かう先を調査して、その近くに貨物駅を設置すると、一気にイモムシの行列が激減します。

しかし、これらをすべて一つ一つ、地道に解決していった先に待ち受けるものがあります。
オブジェクト制限です。

たとえば、
左が本来の車両数、右が上限に達してしまった後spawnした車両です。
運転台がない電車が120km/hで疾走していきます。

貨物列車も同様です。貨車なんか1両も引いてないただの機関車が爆走してきます。
編成の長さゆえにあれほど苦しんだ配線なんぞお構いなしです。

結局こんなむなしい事態に陥ることが分かっているのに、やっぱりやってしまいます。
つくづく典型的な中毒症状を呈しているなあ、と我ながら思います。

2015年10月20日火曜日

Cities: Skylinesをやってみた その2

人口15万人程度の都市を2つほど作ってみました。

重い、重い、とあちらこちらで言われていましたのでどうなるかと思いましたが、ふたを開けてみればこの程度の人口では、ブラウザゲーで農場経営を片手間にやりながら新区画の成長待ちをしていても動作は軽快なので安心しました。なお、アセットはファミリーマートしか入れていません。

試しにsteamから人口30万人ほどのセーブデータをダウンロードしてみると、さすがにややカクつきは見られたものの、個人的にはどうってことはないレベルでした。
但し、f/sが気になって仕方ない人には悶絶ものかもしれませんが。

1つ目の都市はヨーロッパスタイルだったので、区画の形に従って隙間なく建物が並ぶロジックには大いに感銘を受けたものの、高密度区画が住居も商店もオフィスも、どいつもこいつも同じにしか見えなくなって飽きて放棄。

2つ目の都市は亜寒帯で作り始めましたが、現代的な建物にようやく巡り合えてホっとしています。
こちらの都市は15万人でやめたわけではなく、低密度を多めにしているため、開発面積のわりにあまり人口が伸びていません。低密度中心だとメガロポリス解禁までえらい時間がかかる上に財政上も割とシビア(それでも甘々ですが)になりますね。

ところで、地区を指定した上で、その地区に対してスタイルを指定(以下の画像の赤枠矢印のところで指定しています)すると、そのスタイルの建物だけが生えてくるという面白い機能があったので試してみると、以下のようになりました。



画面に映っている建物はほぼすべて高密度な住居なのですが、手前側はヨーロッパ風建築だけが立ち並んで風致地区のような感じになり、奥は近代的な高層建築となってメリハリが出てきた感じがします。
しかし、改めて画像をみると、陰になっていたりヨーロッパ建築地区にハイテク住宅条例を適用したせいか太陽光だか太陽熱パネルが汚らしいですね。
山など正月の澄み切った空気の時にかろうじて高い建物から富士山か筑波山が見えるようなところで生まれ育ったもので、つい山の稜線にヤられてしまったのかもしれません。。。

steamのworkshopでもdistrict styleで検索してみると、なかなかよさそうなものがありますので、メモリが許してくれる範囲内で試してみたいなと思っています。

ところで、現在悩んでいることが一つ。
やたらとこのゲーム、フィルタが白っぽくありませんか?
フィルタなしだと以下のようにむやみに白っぽくなります。



温帯フィルタやヨーロッパフィルタはまだマシなのですが。
アドリア海沿岸じゃないんだから、とか思いながらもうちょっと落ち着いた色調なフィルタを求めてあれこれ試しているのですが、それでもまだ白っぽく感じてしまい、どうもしっくりくるものがありません。
逆に言えばフィルタだけでいろいろな種類が出るくらい自由度が高いソフトウェアなので,
自由度と引き換えに制御権を得ようとして失敗したEAとかが歯噛みして悔しがってるんじゃないかしら、などといらんことを思ったり。

このゲーム、渋滞対策に飽きたら街並みを眺め、街並みを眺めるのに飽きたらズームアウトして大局的な拡張計画を立て、拡張計画に煮詰まったら住人視点(Enhanced Zoomは夜間もチラつかないのでお勧めです)で移動中の景色を楽しみ、それに飽きたら街並みを拡張し、渋滞対策にまたもどる、と、SimCity2013のようなイマイチ感もなく、SimCity4RushHourの時のような楽しさと虚しさ(長時間渋滞対策や区画設計と向かい合った後の「なにやってたんだろ、自分は」というあの虚しさ・・・お分かりいただけますでしょうか)を十二分に満喫できます。

こないだ本体をsteamで50%offセールで買いましたが、近いうちにハロウィンかクリスマスでどーんとセールしてくれるんじゃないでしょうか。もともと安いにもかかわらず、定価で買いたくないでござる病(私です)に罹患していてもそのシーズンは期待できるので、After Dark、10%offでもいいから来ないかなあ。
背中を押してくれればいいのでござる。

2015年10月8日木曜日

Cities: Skylinesをやってみた

Steamで半額セール中だったので買ってみました。

確かにスバラシイ。私はこの手のゲームが大好きなもので、思わず時間を忘れてプレイしてしましました。
ですが、それこそあちこちの紹介記事やblogなどで大絶賛されているほどのものかと、現状では正直微妙でした。

たしかに、SimCity(2013、以下年号を省きます)をやっていると大変に不満に思う点はマップサイズなのですが、その点に関してはまるでSimCity4の時のような自由な開発が可能なのと、SimCity4より優秀なのはいちいちマップを切り替えなくても、マシンスペック次第(とオブジェクト数)では広大な地域を切り替えなしで開発できる点は、やっぱりゲームとしての楽しさとして重要な要素だと強く再確認しました。

ですが、どうも・・・うーん。

SimCityで満足している点がCities: Skylinesでは行えず、Cities: Skylinesで満足している点がSimCityでは行えなくて、というモヤモヤ感はどうしてもぬぐえません。

正直言ってSimCityで不満な点はマップサイズと椅子取りゲーム。それがないからCities: Skylinesは優れている!
というわけにはいかないのが困ったところ。

各種データの見せ方や操作方法、遊び心(犯罪率が上がると建物に落書きが増えるとか)などはSimCityが一日の長どころか断然優れています。その他も含め、まさにこなれたつくりです。
一方、まだまだ路面電車はないし高架の駅もモノレールもありませんが、Cities: Skylinesはマップ内で鉄道が意味を持つとか(日本の首都圏に住むと鉄道の重要性を災害が起きるたびに再確認させられるのもあってか、道路だけだと味気ない)、I/Fの改善も含めてコミュニティレベルの開発が活発でSimCity4でいうMODとかBATが多くあるのも魅力ですし、そもそもマップが広く田舎町と都会を表現できるのはこの手のゲームとして極めて重要だということは論を待ちません。

それに価格差。SimCityとCoTを定価のまま買ってしまったのに、もともとの価格がCities: Skylinesは安いのに今回は半額で買ってしまったので、もう何をか況や、ですが、この手のジャンルを担うのは現在のところこれしかないのです。

SimCityはもうMaxisが解散していますし、CD版SimCity4もDRMの関係で動きませんし(Windows10にした私が悪いのです)、もうEAがなぜか本気になってMaxis以外に作らせてSimCityを復活させる、なんてことはまず期待薄ですから、このCities: Skylinesが育ってくれないと、この手のゲーム好きにとって甚だ困りますが、作っているスタジオはそれこそ零細ですから、Paradox次第です。パブリッシャとしてのParadoxにそこまでの気合と体力があるのかどうか。

なんだかCPUとGPUのファンのうなりがものすごいことになるゲームなんて久しぶりで(ミドルウェアが無駄に使ってんだろうと思いますが、各OS向けに同時開発出来て低価格でリリースしてくださってるんだから文句のつけようがありません)、愉しくてしょうがないのですが、やっぱり自分の街づくりのセンスがないことに真正面から向き合うマゾいゲームなのはSimCity4から変わらず、選挙も経ていない市長として強権を発動しまくって市民の皆さんには大変申し訳ございません(が思い通りに都市開発しちゃいます)。

市議会がなくてよかった。

2015年10月5日月曜日

PT3が突然動かなくなった

今朝5時半の番組までは録画できていたのに、お昼に行われるはずの番組情報取得ができなくなってしまいました。
試しにシステムの再起動を行ってもダメ。
Spinelのログを参照すると「チューナーをオンラインにできませんでした。」と記録されていました。

Spinel経由ではなく直接BonDriverで開こうとしても、やはりチューナが開けません。

その間、何が起きたのかとイベントログを見ても特に何も記録されていません。
WindowsUpdateがかかっているわけでもありません。
デバイスマネージャで見ても特に異常が見当たりません。

FPGA更新ツールで試しても、
★エラーが発生しました。Bus::Run() (0x00000200)
続行するには何かキーを押してください . . .
上記のような表示が出るばかり。

これはついにご故障あそばされたかと、暗澹とした気分で臨時の出費とWindows10の再認証を覚悟しましたが、アースソフトのホームページに行ってみると、ドライバのバージョン4.0が2015/9/25にリリースされていたようでしたので、使用していたPT3のドライバ(3.1)を削除して新バージョンをインストールすると、何事もなかったように動作しました。。。

デバイスマネージャで正しくドライバがインストールされているように見えているにもかかわらず、ドライバがインストールされていない挙動を取るのも初めてでしたし、システムに改変を加えていないのに、さらに最後の録画から半日の間に再起動もしていないのにドライバが使えなくなるという事態に初めて遭遇しました。

PT3ドライバ3.1までで使われていたWinDriverそのものはWindows10に未対応だったようですが、朝の五時半までは正常に動いていたので、混乱中です。

いったい何が起きたんだ!?

*** 以下 2015/11/18 追記 ***

上の記事は2015/10/05 14:14に記述したものです。
たまたまWindows10のデバイスドライバに関連した事柄を調べていると、偶然このトラブルの原因が分かりました。

結論から言えば、PT3のドライバがミドルウェアとして採用しているWinDriverが試用版として作動したため、試用版の制限として30日後に使用できなくなるという仕組みによって、突然使用できなくなったように見えたもののようです。

要するに、対応していないOSで勝手に使って自滅しただけでした。相変わらず愚かなことをやっており恐縮至極です。

長くなりましたので、結論以外の駄文は別項として建てました

2015年9月28日月曜日

TvRockをいじり倒していたらBSODに。

Windows10で初のBSODに遭遇いたしましたので、記念に記録いたします。
BSODはブルースクリーン・オブ・デスの略で、要はカーネルパニックみたいなもんです。

ここのところ、いろいろな経緯から録画管理ソフトのTvRockというソフトウェアをいじくり倒しています。

とうの昔に開発が終了しているソフトウェアなのですが、これが実に使い勝手が良いので、Windows10に更新して発生した事象について調べたりしているうちにBSODが発生してしまうようになりました。

具体的には、TvRockのバージョンをいろいろ差し替えたり、有志の方がパッチを当てたバイナリを入れてみたり、ごちゃごちゃやっているうちに、スリープからの復帰時に予期せぬ再起動がかかってしまうようになりました。

びっくりしましたが(びっくりしたのは、再起動がかかったことではなく黙って再起動されたことに対してです)、BSODが発生してもWindows10か、もっと前からかもしれませんが、BSODを表示せず即座にリブートをかけて何事もなかったようにシレっと証拠隠滅を図るのがマイクロソフトさんの進む道のようです(設定によって変えられますが、規定値がそうなっているということです)。

よほどへんてこなソフトを入れた挙句に苦情をマイクロソフトさんに持ち込まれて散々痛い目に合ったものとお察しします。
「何もしてないのにおかしくなった」なんてセリフを平気でのたまっちゃう厚顔無恥な奴ってどこにでもいますから、心からの同情を禁じえません。何もしなければ何も起きません。何かすれば何かが起きます。

が、そういうユーザが、BSODが発生したために再起動になった、という情報も知らされずいきなり再起動してしまってさらにわけがわからない状況に追い込まれるという悪循環を作り出していて大変興味深いなあ、と思いました。
もう、この愚民政策はマイクロソフトさんだけでなく、どこもかしこもやってることですから、止められない流れなのでしょう。
まあ、Windows10からはWindowsUpdateも止められないというほどに、どこぞの国の特別委採決も真っ青な強硬っぷり(Homeエディションは設定すら不可)なので、より一層MSさんは責任重大ですね。それこそ「知らないうちにおかしくなった」という主張が正当性を帯びますもんね。

それはさておき、今回のケースでは、手動でスリープに入らせても自動(時間経過)でスリープに入らせても、必ずBSODを引き起こしました。

スリープ解除要因も、例えばマウスやキーボードを動かしたり押下してもBSODになりますし、録画時刻になってスリープが解除される時刻にもBSODになったりと、要因が分からなければ泣きたくなるような事象でした。
イベントログを見ても、KP41問題とかでやけに著名ですがソース:Kernel-PowerのイベントID:41の、

「システムは正常にシャットダウンする前に再起動しました。このエラーは、システムの応答の停止、クラッシュ、または予期しない電源の遮断により発生する可能性があります」

ってやつが記録されているだけです。

わあ、KP41問題だあ!!

・・・ってなわけがないんです。
なんだか巷では大流行になっちゃってますが、KP41問題とか言っている大半の事由は本当に電源に由来するものではありません。
よほどしっかりした設計のサーバ機ならともかく、そんなことまできっちりとログからトラブルシュートできるAT互換機がお手頃価格で市販されているなんてのは幻想と思ってもいいです。

当然、今回もTvRockをガチャガチャいじくっていることが問題であることは明白です。

サバを読んでいきなりNT6.2から10に数字を変えましたが、この辺はWindows2000から私は信頼出来るなあ、と思っておりますので、慌てずまずダンプが残っているかどうかを調べますと、やはりいきなり再起動したように見せていても、きちんとメモリダンプは残されていました。

そのダンプをWinDbgで解析してみると、pdc.sysでVIDEO_SCHEDULER_INTERNAL_ERRORを吐いてBSODに至ったことが分かりました。電源管理に関するドライバです。
もっと言えば、スリープ時に関連するドライバのド直球です。

従って、直前にいじっていたTvRockをアンインストールして、そのうえでアンインストール時にTvRockがレジストリから削除してくれない情報を手動で削除しただけでこの現象は収まりました。

こんなふうに開発者でもないのにイジくるようなことをする人はほどんどおられないと思いますが、TvRockをもてあそんでいて、BSODを見せないということを知ってびっくりして思わずこんな記事を書いてしまいました(TvRockがきっかけであって、TvRockが悪いとかどうとかではないことはここで闡明しておきます。まあ、このblogでしょっちゅう記述していることの繰り返しなんですけどね)。

誰の役に立つかわかりませんが、TvRockには2019年問題もありますので、入れ替え作業などでもしもこんなトラブルが発生するかもしれません。
もしかしたらどなた様かに役立つこともあるかもしれないと思い、記録しておく次第です。

Internet Explorer 11 でOutlook.comが文字化けする場合

本当はOutlook.com以外でも発生するのですが、マイクロソフトアカウントがらみで特に利用されていそうなサインイン画面を例にご説明します。

Internet Explorer 11でしか観察されていませんが、Outlook.comのサインイン画面で以下のような文字化けを起こす場合があります。

この現象はChrome、Opera、Firefox、Edgeでは発生しません。
ご覧のように英字がことごとく豆腐化しています。

別にIE11を単独で使わなければいいじゃないかとおっしゃるかもしれませんが、実際にはVisual Studioやらなんやら、IEのコンポーネントを利用しているアプリケーションは結構あるので地味に困ったりします。

IE11を単独で使っている時には一時的に文字化けを抑える手段があります。
インターネットオプション画面を開き、左下にある「ユーザー補助(E)」ボタンを押下して、「Web ページで指定されたフォント スタイルを使用しない(S)」チェックボックスにチェックを入れれば豆腐になってしまっている文字は正しく表示されるようになります。

しかし、この方法ではコンポーネントとして使われているアプリケーションからは設定できませんし、他のサイトでもスタイルを無視されてしまいます。

フォントの表示がおかしくなった場合の定番の対応法である「フォントキャッシュ(%SystemRoot%\System32\FNTCACHE.DAT)を削除して再起動」をしてもなお、この現象がおさまらない場合は、古いバージョンのフォントがシステムに残っている場合があります。

この例ですと、この日本語版のサインイン画面の場合はメイリオですので、古いバージョンのメイリオが何らかの拍子で残っていることが疑われます。
そこで、コマンドプロンプトを起動して次のコマンドを入力して確認します。
cd %WINDIR%\fonts
dir meiryo*.ttc
すると、Windows10の場合、正常ならば次の2ファイルだけがリストされます。
2015/07/11  01:30         9,524,020 meiryo.ttc
2015/07/11  01:30         9,740,576 meiryob.ttc 
もしそうではなく、上記に加えてファイル名に_0とか_1とかついているファイルがリストされてしまったら、それは古いバージョンのメイリオです。
例えば以下のようなファイルです。
2012/06/24  08:24         9,737,516 meiryob_0.ttc
2009/10/27  17:06        17,159,388 meiryob_1.ttc
2012/06/24  08:24         9,506,456 meiryo_0.ttc
2009/10/27  17:06        16,710,176 meiryo_1.ttc
これらのファイル名に_0とか_1とかついているファイルは不要なので、削除するなり移動するなりして%WINDIR%\fontsディレクトリから排除してから先ほどのサイトを表示すると、正常に表示されるようになります。

古いバージョンのフォントが残っていることもレアケースでしょうし、さらに輪をかけてInternet Explorerでしか文字化け(英字が豆腐)が発生しないので、輪をかけてレアなトラブルですが、なかなか気づきにくいかも知れないと思い、あえて記述した次第です。

2015年9月26日土曜日

タスクスケジューラから起動されたプロセスの優先度

恥の記録と、ついでと言っては何ですが、表題の件を変更する方法をご紹介します。

前置きです。

タスクスケジューラから起動されたプロセスの優先度は通常以下のCPU優先度が割り当てられます。
つまり、他に忙しく仕事をしているプロセスがいると、実行権が回ってきづらくなります。

さらに、Windows Vistaからは低優先度IOという機能が導入されましたが、タスクスケジューラから起動されたプロセスは、IO優先度も低くされます。
これまた他のプロセスが盛大に読み書きを行っているとお鉢が回ってこなくなります。

デフォルト設定としてはそれでいいですし不満はありませんが、いまさらこんなことを書くのはWindows10に移行した折、うっかりこのことを失念していたため、恥の記録として残します。

私の場合、ログオン時に段階的に起動していきたいプロセスのためのバッチファイルをタスクスケジューラでトリガを「ユーザのログオン時」として起動しています。

例えば、単純にSpinelとTvRockをスタートアップ起動に登録していた場合、両者が同時に起動しようとして、さらにTvRockから起動されるRecTestがSpinelの完了まで延々再起動されて邪魔臭いので(録画中に再起動するなって言われそうですが・・・番組情報取得中とか長い番組とかでたまーにやってしまいます)、Spinelの起動を待ってTvRockを起動する、とか、スタートアップに登録しておくと一斉に起動されて操作の邪魔だからちょっと時間をおいて起動する、とかが目的です。

Vistaのころは、それに加えて実行に管理者権限を要求するプロセスをスタートアップに登録しておいても起動させてくれなくなったため、それを回避するという目的もありましたが、現在では常駐していてほしいけど管理者権限を要求する、というようなプロセスはあまり見かけなくなりました。
たしかNECのSmartVisionかIOデータのmAgicTVだったような・・・なんだか録画がらみばかりですねえ。

で、だから何だというと、重い処理をしている間に録画を開始する時刻になってRecTestが起動されても、Spinelになかなか実行権が回らないのでプロセス間通信がうまくいかず、挙句にRecTestが起動をあきらめてしまう場合があります。

そういう時に限って全画面で作業やゲームをしていたり、無人でバックアップやタモリ倶楽部のエンコードを行っていたりするので起動をあきらめたことに気づかなかったりします。

そこでそのような事故を減らすべく優先度を通常にしていたのですが、Windows10に移行したとき、そのバッチファイルを手動でタスクスケジューラに登録した時に、優先度の変更をすっかり忘れていました。

さて、優先度の変更方法ですが、残念ながら設定画面からでは変更も確認もできません。
そのため、
  1. GUIから優先度を変更したいタスクをエクスポートします。
    →UTF16で記述されたXMLファイルとして保存されます。
  2. エクスポートされたXMLファイル中のPriorityの値が優先度を示しますので、その値を変更して保存します。
  3. 名前の重複でエラーとなるため、エクスポート元となったタスクを削除します。
  4. 変更を加えたXMLファイルをインポートします。

Priorityの値が示す意味は以下のようになります。
CPU優先度IO優先度
6通常通常
7通常以下
9最低
通常の手段で作成されたタスクは、Priorityに7が指定されています。
なお、6未満の数を指定しても、実際には通常以上のCPU優先度にはなりません。また、IO優先度はそもそも「通常」が最高の優先度となります。なんせ機能名が低優先度IO(Low Priority IO)っていうくらいですからねえ(正確には、メモリマネージャには「重大」という特権的優先度がありますが、カーネル内部の話です)。
また、CPU優先度とIO優先度を個別にも指定できません。

以上、恥の記録と、おまけでした。

2015年9月25日金曜日

富士通 PRIMERGY TX1310M1を買ってみた

この記事でサーバがぶっ壊れた悲しみをご報告しましたが、9/11に新サーバが到着以来、今日までの使用感をご報告いたします。

PCとして利用しているわけではないので、その手の情報を期待して検索に引っかかってしまったらごめんなさい。

結論から申しますと、大変満足しています。

いまどきCentOS5で運用しているのですが、初期設定でSATA接続のHDDが内蔵ソフトウェアRAIDにぶら下がっているという前提なBIOS設定でしたのでAHCIモードに切り替えただけで、故障したサーバからHDDを移設するだけであっさりと起動。
Windowsだったら七転八倒の苦しみを味わうところでしたが、Linuxだったのも幸いでした。

もちろんチップセットの違いからNICドライバとVGAドライバとセンサーチップのドライバが異なってそのままでは使用できませんでしたが、NICはIntelのI210ドライバ(igb)をUSBメモリ経由でmake installして(運用が落ち着いてからlspciしましたが、この機種にはNICが2ポートありまして、もう片方はe1000eでいけましたので、これはExpress5800の時と同じですから第二ポートでLANに接続していたら最初からNICが使えたかもしれません)、VGAドライバはXの設定をし直すだけでした(Xは特に必要でもないのですが、PCがぶっ壊れた時にブラウザが使えると大変重宝します)。

ただ、困ったことにセンサーチップのドライバがありません。
正確には、カーネル3.0以後で使えるソースは存在したのですが、CentOS5は2.6。GCCのバージョンの違いやカーネルオブジェクトの構造の違いからコンパイルすら通りません。
まあ、CentOS5もあと1,2年でサポートが終了するため、いつかはOSのアップグレードを行わなければならないと覚悟していますが、膨大な量のinitスクリプトをsystemd用に移行せねばならないことと検証の手間を考えると、手が止まってしまいます。
特にiptablesに過去うちのサーバに攻撃を加えたipアドレス(その数、実にン十万件です。システム起動時にLANを有効にする前の再読み込みする処理に数十分かかります)をdropさせる処理と攻撃者のipを記録して保存する処理の移植と検証が・・・

それに加えて自作のアプリが山ほどあり、gccのバージョンも大きく異なり、さらにDBからなにから大幅にバージョンが変わってしまうので、さらにやる気が・・・

いつかはやらねばならないのですが、過去10年以上運用してきただけあって相当量の遺産がネックになってどうしても二の足を踏んでしまうのが現状です。もっとも、これはTX1310とは関係のない話ですが(なお、2台目のぶっ壊れたサーバからデータを吸い出すためにCentOS7のライブDVDで起動してRAID5の再構築などを行ったのですが、VGAもLANも問題なく稼働しましたので大変楽ができました)。

次に気に入った点は、ミニタワーにしてはコンパクトに出来上がっている点です。Express5800に比べて高さが5cmは低い。これはありがたいです。今までは入らなかったようなところに押し込めるからです。
廃熱設計のためだろうと思いますが、HDDのマウント位置が筐体下部に2本分あって、そのために高さが必要なかったのでしょうか。地味ですがとても有難い特徴です。

次いで、困ったというわけでもないのですが、この機種は今流行のHDDをネジ止めしないでホルダに突き刺して使うタイプなのですが、HDDの端子がケース横に向くようになっています。

これはケース横の鉄板を外すだけ(ネジ止めではなくてハンドルで簡単に側板をあけて内部にアクセスできる点も大変素晴らしい点です)でHDDの脱着が簡単に行えることになるわけですので、保守性からみるととても有難いし、事実楽なんですが、(こんなことサーバでやるかよと言われればごもっともですが)IDE接続のHDDにSATA-IDE変換器を刺してしまうと、ケースの蓋が閉まりません。

この点は「格安サーバなので古いHDDの再利用をしてやろうか」と思って買うと痛い目を見ますので特記しておきたいと思います。なんせHDDケースより安いんですからねえ。

もう一点は、PS2コネクタが用意されていないことです。マウスもキーボードもUSB接続のみです。
実は、この点だけは私は完全に見落としていました。このブログは恥の記録として記述するのが主な目的ですが、まさにその目的通りに間抜けを演じてしまいました。
まさかタワー型のサーバでももうここまで割り切っているとは・・・今時USBKVMが主流でしょうからやむを得ないコストカットでしょう。
今は余っているモニタをつないで、KVMを挟まないで運用していますが、やはりちょっと不便です。
そのうちKVMを買い替えなければならないのは地味に痛いです。

あえて特筆するとすれば困った点といえばこの二点だけで、音は静かだしRS-232Cポートはついているし、これで2万円ですからもう何も言うことはありません。

さらに個人的な事情では、いま利用しているPCがHaswell世代のCore-i7なので、もしかしたらPCを買い替えるときにCPUを付け替えちゃったりして遊べちゃうかも・・・なんてな不埒な妄想を膨らませてしまいます。

残る懸念材料は、やはりなんといってもPRIMERGYの最大の特徴であるところの電源の特殊性ですね。
一時期ものすごい勢いで粗悪品のコンデンサが流通したおかげでポンポン破裂する事故が多発していましたが、そうでなくてももともと電源は消耗品なので、ぶっ壊れた時に再度入手できれば良いのですが、こればかりは運否天賦ですねえ。

Windows10でTvRockのタスク登録が失敗する

あまり頻繁に録画しないので今日まで気づきませんでしたが、Windows8.1までは何の問題もなく稼働していたTvRock(0.9t8)がWindows10にして以後、スリープ状態からの復帰に失敗して録画予約が失敗する場合があることが分かりました。

「場合」と保留付きなのは、全ての予約に失敗するわけではなく、一部の予約だけ失敗するためです。

まず、録画できない原因は、tvrock.logによると”タスク登録でエラーが発生しました”という文言が記録されているので、タスクスケジューラへのタスクの登録に失敗しているため、スリープが解除されず、結果として録画できないという流れのようです。

確かに当環境では「復帰処理をタスクスケジューラで行う」チェックボックスをチェックして運用していましたので、このチェックボックスを外せばいいのでしょう。
先ほど一度だけですが、チェックを外した状態で5分後からの録画予約を行って直ちにスリープボタン押下によってスリープ状態に移行後、設定どおり録画3分前にスリープから復帰し、powercfg.exeで復帰理由を表示させてみても
C:\Windows\system32>powercfg /LASTWAKE
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 1
  スリープ状態の解除元 [0]
    種類: スリープ解除タイマー
    所有者: [PROCESS] \Device\HarddiskVolume5\local\bin\TvRock\tvrock.exe
と表示されたので、チェックボックスのチェックを外したままで運用できそうです(念のため当分様子を見たほうがよさそうですが)。

しかし、遺憾ながら、なぜタスクスケジューラへタスク登録が失敗しているかまではロギングされておらず、原因の特定ができません。
せめてGetLastError()やHRESULTの値だけでも出してくれていれば重要な手がかりになったのですが、そもそも開発終了どころかホームページも消えているという代物を勝手に使い続けているわけですから文句は言えません。

なぜWindows10のせいだと言い切るかというと、録画環境ではWindows10の稼働開始日時が2015/09/04 16:59:12なのですが、その直後から直ちにtvrock.logに”タスク登録でエラーが発生しました”という文言が現れるからです。
それ以前のWindowsVistaやWindows8.1時代のtvrock.logには一切そのような記録はありません。

疑問なのは、Windows10になってからなぜすべてのタスク登録に失敗せず、一部だけが失敗するようになったのか、です。
イベントログを見ても何のエラーも記録されていませんし、権限や設定ミスの問題であれば例外なく失敗または成功しなければ理屈に合いません。「一部だけ」というのが極めて不可解です。

この手のAPIを変更するなんてことは考えづらいのですが(手を加えるなら変更ではなくてAPIを追加するはず)、APIの変更があったのかと念のためにMSDNに当たってみても、WindowsVista時代の機能追加以後、ドキュメントは更新されていませんでした。

まあ、tvrock.logからは結果しか読み取れないので、タスクスケジューラに登録する前の手続きで躓いている可能性もありますので、タスクスケジューラだけ疑っても仕方がないのですが。

いずれにせよ、Windows10になって急に失敗するようになったので、こりゃあ例のごとくドキュメントにない変更を加えた挙句にバグを仕込んだという可能性が高そうです。WindowsUpdateの時などにも時々やらかしてくれるので困ります。

もうメンテナンスされる見込みがないTvRockを使い続けるほうにも問題がありますが、Windowsを使い続ける大きな理由の1つが後方互換性なのですから、やはりこういったことがないように注意深く仕上げてもらいたいところです。

Windows10がリリースされてからまだ日が浅いですが、「どうしてこんなところで?」と言いたくなるようなところでバグを見つけてしまうことが多いように思います。
InsiderPreview参加者がアルファ版テスタで無償アップグレード利用者がベータ版テスタという位置づけなんですかねえ。
従来も、サービスパックがいくつか出るまではこんな調子でしたから、いつも通りといえばいつも通りなんですが。。。まだまだ完成度は低いようです。
まだアップグレードしていない方はもうしばらく様子を見たほうがいいと思います。

2015年9月16日水曜日

Windows10無償アップグレード版を2週間使ってみての率直な感想

マイクロソフトさんには散々お世話になっておりますし、個人的にもロハで新OSを8.1と10の2つも頂戴しておいてこんなことを言うのは誠に心苦しいのですが、現時点における率直な感想を申し上げたいと思います。

前提として、電話、タブレット、ノート、デスクトップすべてをターゲットとしているWindows10なのですから、まず、どういうことにWindows10を利用しているかという点を明らかにしないといけません。

私はタワー型PCで96dpiのモニタを利用し、PCにはHDDをはじめとしたデバイスを割合頻繁に付けたり外したりします。
そのPCにインストールされたWindows10の用途はゲーム、ブラウザを使ってのwebアプリの利用、Windows,*nix,Androidなどを対象としたプログラム作成のための各種環境の操作、書類作成、オンライン決済、PT3で録画したタモリ倶楽部の鑑賞です。

そのため、ゲームとWindows用しかデバイスドライバが用意されていない機器の使用(今つながっている機器だけ列挙しても、ラベルやディスクプリンタとかスキャナとかカードリーダとかゲームコントローラとかwebカメラとかBluetoothアダプタとかRS232C変換器とか、こうしてみると本当に多いです)と書類作成と過去のドキュメントや客先からいただくドキュメントの参照のためのMS Office、Visual Studio、Spinel、TvRockといったWindows版しかないアプリケーションの利用がWindowsでなければ「ならない」理由です。

MUSTではないにしても、Windowsで「あってほしい」理由となると山ほどあります。
代替品はあったとしても、エディタをはじめとした「使い慣れたツール群」がWindows版しかなかったり、各種OS用にあったとしても一番出来のいいのがWindows版であったり、MS-DOSのころからお世話になっているため何か不具合が起きた場合に原因を探る勘所がある程度掴めていたり(ここまではWindowsであるかどうかではなくて「使い慣れたOSであってほしい」と言い換えることもできますが)、掴めなくてもユーザ数の多さからくる情報発信量の多さで問題の解決が容易であったり、最新の機器のドライバが真っ先に用意されるのがWindowsであったり、クライアント向けOSであるにもかかわらず長期間のサポートを実現し続けており、さらに、後方互換性に対して尋常ならざる努力を重ねている点への信頼感であったり。
枚挙に暇がないといっていいのではないかと思います。

ここまで言っておいてなんですが、前述の環境で利用している私には無償アップグレード版Windows10にアップグレード「すべき」メリットを、一つを除いて見つけることができませんでした。

その一つのメリットとは、デバイスが壊れない限り、サポート期間がさらに延長されることです。
デバイス(とマイクロソフトさんが見なすPCの一部のパーツ)が壊れてしまえばライセンス切れになるわけですから、サポートが切れるより早くデバイスが壊れる確率のほうが高いわけです。しかしながら、それだけ長い期間のサポート期間を、パーツが壊れない限りは設けているわけですから、やはりこれは相当なメリットと見なしていいと思います。

デバイスを交換するとライセンスが失効してしまいます。

但し、やむを得ない故障によるパーツ交換であればライセンスを再発行してもらえるケースがありうるようです{Microsoftフォーラムでマイクロソフトの Answer Deskに問い合わせた方のご報告がこちらにあります。セットアップ窓口(平日午前9時~午後6時、土日午前10時~午後5時) 0120-54-2244に電話し、自動音声ガイド1->3->1->2 だそうです。ただし、私は検証していませんし、真偽を確認する権能を有してもいませんし、このフォーラムそのものが権威あるものではないことは申し添えておきます}。
勿論、HDDを大容量のものに換装したとかVGAをいいものに変えたといったケースではダメだということは明らかにされていますし、「やむを得ないケース」の判断はあくまでマイクロソフト側にあるため、明白な基準が示されるわけでもなく、どうしてもオペレータの判断によってケースバイケースになってしまうようです。
とはいえ、これは無償アップグレード版ではなくリテール版を購入すればいいことなので、ここでは措きたいと思います。
ケチるなら来夏まではWindows8.1から再度アップグレードをしてWindows10にするという選択肢も依然残されています。

従来通り動くソフトは山ほどありますが、動かないソフトも結構できました。
後方互換性を重視しているとはいえ、さすがにダメなものはダメです。
Windows8の時もそうでした(MSVisualStudio2005は管理者権限で動かせば何とかなりましたが、SimCitySocietiesは即死でした)が、加えて今回のWindows10はSafeDiscとかSecuROM採用のゲームが動きません。そのため、お気に入りのMSFS、光栄の三国志とか信長の野望、Simsなどが軒並みこの手のDRMを採用していたため全滅です(MSFSが特にイタイ。Steam版FSXがあるからって言っても・・・)。今となってはさすがにめったにやらないにしても、たまにやると面白いのでボチボチやっていました。結構高額なので「動かさない」と「動かせない」ではやっぱり違いにヘコみます。
さすがにSteamやOriginなどオンライン認証なゲームは全部OKでした(信長の野望・創造PKってSteamなんですよ。ご存知でしたか?価格は相変わらずKOEIプライスでしたけど)
まあ、Windowsに限らず、メジャー番号が上がるということはこういうリスクはあるわけですし、OSどころではなく電子入札とか応札先の省庁ごとに必要なJavaランタイム(これも仮想マシンですから見方によってはOS以上なんですけどね)のバージョンが異なるなんて笑うに笑えない実例もこの国にはありますので、この辺りはやむを得ないところはあるわけですが、メリットではなく紛れもないデメリットではあります。

巷で言われているところの使い勝手が変わるとか見た目の統一性がないとか同じ設定項目でもあちこちで設定できてしまうとか、Windows8に輪をかけたUIの統一性のなさは目を見張るものがありますが、これはまあデスクトップPCからタブレットへとメインストリームが移り変わる(とMSは思っていると勝手に私が思っていますし、半ば同意するところではありますが)変わり目の半端なOSである上、先ほども申しましたが電話からタブレットからノートからデスクトップまで、ありとあらゆるデバイスを巻き取るべく設計された野心的(野心的ではあるが現段階ではどっちつかずの日和見UI)なOSであると私は思っているので、言い出すとキリがないのでこれも脇に措きましょう。これこそ枝葉末節過ぎて語るに足りません。

ソフトウェアと同様、ハードウェア面でも使えない(今回はBluetoothアダプタでした)、あるいは接続しているとスリープに入らないデバイスが出てしまいました。
いずれもWindows8.1では問題なく使えていたのですが、これもまあ、新デバイスがある一方、古いデバイスは切り捨てられていくのはある程度は仕方がないのですが、やはりメリットではなくデメリットと言わざるを得ません。

では、新機能はどうか。

Windows10の目玉中の目玉、CortanaとEdgeはどちらも未完成です。
おまけに、Edgeの完成の暁にはブラウザの選択肢が広がるから歓迎できるとしても(MSさんはIEを捨てなくてなくてもいいんじゃないかなあ?と個人的には思いますが)、Cortanaに至っては・・・デスクトップ中心で利用しているユーザというより、WindowsPhoneのユーザ以外にどうせえっちゅうんじゃ、というのが率直なところです。
SiriをMacOSでどうしても使いたいユーザっていますかね。そりゃ一定数いるでしょうが、なんでまだ実装されてないんでしょうね?(私個人の見解としては、iOSが使われるシーンよりMacOSを必要としている人の利用シーンではiOSに求めるよりも遥かに複雑な使われ方をしていて、Appleのお仕着せのサービスだけでしか完結できないSiriでは現状のままでは手に負えないからではないかな、と思っています)

デスクにどっしりと構えて24インチモニタに向かって(正確にはマイクに向かって)「おーけー!!ぐーぐる!!!」「コンピュータ、私のスケジュールは今日はどうなのおーー??」なんて叫ぶのってUSS1701乗組員(マイクに向かって「アールグレイ。ホット。」というだけで配送を手配されたらもっと困るんですけどね)か ヒーローものの主人公ぐらいじゃないっすかね。手や目が不自由な人が使うなら話は変わりますが、明らかにそのためだけの機能じゃないですからね。

もし私がSiriやGoogle Nowの中の人だったら、そういう人にこういうでしょう。
「目の前にあるアイコンをダブルクリックしろ」

スマホとかタブレットだとちょっとした入力でも苦痛ですが、PCだと山ほどボタンがくっついてるキーボードとマウスがあるんですよね。そのため、そっちのほうが圧倒的に早いんです。前提条件としてお示しした通りの前提で話していますから電話やタブレットなら便利だよと言われても困るんですが、PCでは超目玉であるはずのCortanaやEdgeはどっちもモノになっておらず、現時点では話にもならないと言わざるを得ません。
もっとも、今後どうなるか、は、見ものです。
AppleもGoogleも、デスクトップ分野でのこの手のサービスは成功しているとは到底いいがたいところです。

最後発のマイクロソフトがどういうアプローチを行い、また、存在感を示せるかは、本当に未知数です。こればかりは未来のことですので何とも言いかねますが、現状では価値がないと断ぜざるを得ません。

しかし、3社のうち2社はデスクトップPCを見放し、携帯端末(スマホやタブレット)に特化したサービスを打ち出し、好評を得ています。
方や、マイクロソフトはノキアを買収したとはいえ、先行二社に大きく水をあけられていることは隠れようもない事実と指摘せざるを得ません(マウスやトラックボール、キーボードなどのデバイスではハードウェアメーカとしても信頼も実績もあるメーカである側面はあるのですが・・・新デバイスではSurfaceは一部界隈で大好評ですが、過去のRT版の存在のおかげで混迷感が出てしまっているのは否めない事実ではないでしょうか)が、後発であるからこそ見えてくるものがあるでしょうし、後発であるからこそ自由に動けるという利点があることも確かです。
デスクトップ分野やサーバ分野で巨大な市場を形成してきたMSがどのようなアプローチをとるのか、彼ら自身もおそらくせいぜい「臨機応変に」といったところではないかな、と拝察しますが、過去の例からするとある意味「挑戦者」の立場になった時のMSは面白いことをしてくれてきていますから、今回も期待するや切ではあります。

が、わたくしが提示した前提において今回の表題の結論を申し述べますと、上記の通り「現時点では価値が認められない」という一点に尽きます。

/***
  @date 2015/9/16
  @auther ayumi
  @comment
 Windows の携帯端末には、それはそれはお世話になりました。利用者ではなく、開発者としての視点です。古い話になります。
 今は亡きWindowsCEは、それはそれは素晴らしいものでした。なにしろWindows上での開発経験さえあれば(さすがにVBじゃだめですが)携帯端末なのにGUI作成も容易、さらにはTCP/IP経由で違和感なくC/Sシステムを簡易に構築できるほど洗練されていたのです。
 モバイルなくせに一般の人が容易{比喩でなく、実際に作成した例でいえば、コンピュータに縁もゆかりもない(インターネットが一般に普及する以前のことです)農家の人が農閑期に臨時で農協の選別場に来て直ちに業務を開始できる程度の容易さ}に扱えるようなGUIを表現できる上に、Win32APIをほぼそのまま使用してプログラムが書けるので、お客様にも喜ばれ、VC++での開発経験さえあればいいので、開発要員の確保も容易で工数も削減できるという夢のような時期がWindowsのおかげで確実に存在しました。
 現代ではAndroid搭載の格安端末に自称Javaプログラマを雇って似たようなこと以上のことをできますが(どこでメモリが確保されて解放されるか理解しようともしないし理解できないアホどもが多いのはなぜでしょうね?)、当時の組み込み機器において多数あるライバルを蹴散らして、破格な敷居の低さを実現したのはマイクロソフトとパートナーのデバイスメーカでした(今でもATMやらレジがWindowsでびっくりした、なんて話がよく聞かれるのは偶然ではなくそれだけの実績があるからです。もちろんCEでもなく一般で使っているWindowsでもなくて組み込み用に特化されています)。
 デスクトップで使う前提でまるで本文では腐したような書き方になってしまいましたが、今後もぜひ、マイクロソフトさんに、あのようなブレイクスルーを期待するや切であるゆえに、あえてこのような書き方になってしまったことをお許しください。
***/

2015年9月10日木曜日

Firefoxのサイドバーのブックマークと履歴のフォントを変更する方法

*** 2018/10/25 追記 ***
当記事コメント欄でご紹介したブックマークの行間を狭める方法ではFirefox63から狭まらなくなったので、新たにこちらの記事でご紹介いたします
*** 追記ここまで ***

前置きです。

最近、何年かぶりにWindowsでFirefoxを使ってみました。

Linuxにはインストールしてはあるのですが、通常telnetやsshでログインしますので、そんなゴージャスなアプリってなかなか使わないんですよねえ。

使ってみて驚きました。
昔使った時より大変使いやすくなっているんじゃないでしょうか。(使えないと思ったからOperaを使っていたわけです)
すぐ気に入りました。

MosaicからNetscapeに乗り換えた時の驚きを懐かしく思い出しました。
別に今回は驚いたわけじゃないんですが。

今までメインで使っていたOpera12からすぐに乗り換えました。

現在でもOpera12にほとんど不満はないのですが、いかんせんOpera12では表示できないサイトがぼつぼつ増えてきて、どうしようかなあ、と思っていたところです。

Chromeがシェアを伸ばしているようですが、Chromeはどうしても馴染めません。
やたらともっさりしてるし、メモリ食うし、文字がやけににじむサイトがあるし、UIが特殊すぎるし、タブタブうっせーし、Google製だし。
GoogleアプリとFlash専用ブラウザとして活用させていただいています。
GoogleさんはFlashを根絶したいようですから、ちとGoogleさんにとっては不本意でしょうが。

Chromeといえば、Chromeにログインしないと拡張機能の移行をさせてくれないんですね。
現在、Windows10へWindows8.1で使っていた環境の移行作業中なのですが、ブックマークは素直に個人プロファイルディレクトリのコピーだけで取り込めましたが、拡張機能ははじかれてしまいます。
セキュリティ上の理由だとかGoogleさんはおっしゃいますが、手元に丸々残っているユーザプロファイルを受け付けてくれないのはちょっと不便ですねえ。

ところで。

Windows10でFirefoxを起動して驚きました。
サイドバーに並べたブックマークの文字のにじみがひどい有様になっています。

原因はお察しの通り、Windows10から採用されたフォント、游ゴシックUIとClearTypeと、デスクトップPCの場合の標準の解像度、96DPIという絶妙のコラボレーションが織りなすハーモニーの結果です。

游ゴシックって高DPI環境じゃないと表せないような曲線が多用されているので、たった96DPIしかないモニタにフォントスムージング技術をかぶせるとぼやけるのは当然です。
前のOSのメイリオの時も同様の理由でボケましたが、游ゴシックよりは直線的なフォントだったため、ボケかたが游ゴシックに比べれば軽微でした。さらにその前のMS UIゴシックではさらに直線的なフォントなのでほとんとボケません。

要するに、Windows10は高DPI環境を前提にしているわけです。そこら辺のスマートフォンだって400DPIや500DPIは当たり前ですから、その環境できれいに見えるフォントを持ってきちゃったら、たった1インチに96ドットしか打てないモニタできれいになるわけがない。
結局、このブログでこれまでも指摘してきましたが、今回も「タブレットのことで頭がいっぱい」なわけです。

いずれはそうなるにしても、どんなDPIでも同一フォント、同一レンダリングエンジンっちゅーのは、ちょっと強引すぎると思うんですがねえ。
まだまだデスクトップ環境はすたれないでしょうし、デスクトップではほぼ96dpiで表示するのが一般的であり続けるでしょうからねえ。

Windows8から(7からだっけ?)、システムフォントを変更するインタフェイスも廃止するほど強硬な態度をとるMSですが、奈辺に意図があるのでしょうかねえ。
挙句にユーザに「メイリオは汚い」「游ゴシックは汚い」とか印象を持たれてしまう始末です。
フォントに汚名を着せて頬かむりしている態度は遺憾です。
不適な用途に使われているフォントがかわいそうですよ。

で、本題です。

Windows10上で稼働するFirefoxは、タイトルバーやブックマークなどの表示に游ゴシックが使われます。
で、ぼやけ、にじみが出ます。

単純な対応方法は、高DPI環境で運用するか、低DPI向きのフォントに変更するか、です。

今回はフォントを変更して対応する方法を紹介します。
なお、対象Firefoxはこの記事を書いている時点の最新であるFirefox40とします。


まず、Firefoxフォルダのプロファイルフォルダを開きます。
場所は%appdata%\Mozilla\Firefox\Profiles\*.default\ですが、これでは何を言っているかわからない方はFirefoxから開く方法があります。

方法は、

  1. Firefoxを起動します。
  2. メニューの「ヘルプ(H)」から「トラブルシューティング情報(T)...」を選択します。
  3. 「アプリケーション基本情報」テーブルに「プロファイルフォルダ 」という項目がありますので、その横の「フォルダを開く」ボタンを押下します。
さて、Firefoxのプロファイルフォルダを開いたら、その中にchromeというフォルダがない場合は手動で作成し、chromeフォルダを開いてください。

chromeフォルダを開いたら、userChrome.cssというファイルがなければ新規に作成してください。
エクスプローラで拡張子を表示しない設定のままで作成して「反映されねぇ~騙しやがったなぁ~」とかのたうち回らないようご留意ください。

テキストエディタでuserChrome.cssを開いてください。
テキストエディタってなに?って方はノートパッドで開いてください。
文字かければいいんだろ、とか言ってWordとか一太郎とかWriteとかで開かないでください。

開いたら、以下のインデントされている部分をコピーペーストして保存してFirefoxを再起動してください。

1) サイドバーのブックマークと履歴の表示フォントをメイリオUIヘ変更し、9ポイントで表示する場合は次の通りです。
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
#bookmarksPanel, #history-panel {
 font-size: 9pt !important;
 font-family: "Meiryo UI" !important;
}
2) とにかく游ゴシックを駆逐して全部MS UI ゴシックにしたい!という方は以下をコピーペーストしてください。
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
* {
 font-size: 9pt !important;
 font-family: "MS UI Gothic" !important;
}
フォントやポイント数をいろいろ遊んでみると、MS UIゴシックだと滲まないけどいまいちきれいじゃないし・・・とか、いろいろ出てくると思います。
ご自身で納得できる落としどころを探ってみてください。

Windows10でHID準拠ゲームコントローラが接続されているとスリープできない

Windows10をクリーンインストール後、2日目になってもスリープ状態に移行しなかったので調査したところ、上記の結果が得られました。

もっと言えば手動でスリープ状態に移行させることはできるのですが、時間経過によってスリープ状態に移行しません。
スリープはおろか、モニタの電源も落ちないし、スクリーンセーバすら起動しません。

本来であればOSのアップグレードやインストールを行う際には当然USB機器などは取り外し、さらに出来れば最小構成でインストールすべきというのがこれまでの常識でしたが、Windows10無償アップグレード版は人にではなくデバイスに対してライセンスが付与されるということでしたので、今回はあえてWindows8.1で利用しているデバイスを全部接続した状態でアップグレードとインストールを行いました。

そのため、スリープに入らない原因を突き止めるのに時間がかかりました。
では恥の顛末を早速。

まず、真っ先に疑ったのは周辺機器の電源管理オプションです。
デバイスマネージャを開き、接続されている機器の一つ一つのプロパティを開き、「電源の管理」オプションを見て回りましたが、すべて「電力の節約のため、コンピューターでこのデバイスの電源をオフにできるようにする」チェックボックスはチェック済みとなっていました。

次に、Windows10用デバイスドライバが用意されていないデバイスのせいでスリープに入れないのではないか、ということです。
PT3、ADBドライバ、プリンタ、ラベルプリンタ、CDラベルプリンタやスキャナなどのドライバはOSインストール直後にすべてインストールしておいたのですが、デバイスマネージャを開いてみると、確かに、

  • SMバスコントローラ
  • 不明なデバイス
の2つがドライバが適用されていない状態でした。
これだけでは何のことかさっぱりわからないのでデバイスマネージャのイベント欄から手がかりを調べてみると、何のことはなくて単純にMSがチップセットドライバを端折って入れていただけでした。
ちなみに、これらは
  • Intel(R) Management Engine Interface
  • Intel(R) Smart Connect Technology Device
のことでした。
しかし、これらのドライバを入れてみてもスリープせず、無関係でした。

次に疑ったのは当然Windows10です。何せ今回、一番変わったのはコイツです。
そこで、ひとつづつプロセスをkillしては数分待ち・・・というようなことを延々繰り返していましたが、やっぱりスリープする気配がない。

かなりな数のプロセス数なので、さすがに途中で飽きてしまったところ、ちょっと思いついたことがあって、起動直後にロック画面のまま何も触らなければどうなるのか試してみました。

スリープしました

では一度ログインすればダメなのか、と思って、ログインしてスリープ状態に移行しないことを確認した後、再度ログオフして待機してみました。

スリープしました

いろいろ試すうちに、ログインしていなければスリープするが、ログイン中はスリープしないことが分かりました。

え?ログオン?え??サインインですか?そうですか。

一度ログインしてスリープしない状態になっても、ログアウトさえすれば、設定時間経過後に正しくスリープ状態に移行するのです。

再度ログインすると、またスリープしなくなりました。
スリープしないことを確認後、ログオフすると、今度もやはり正しくスリープに入ります。

ここで、ログイン中に起動されるプロセスを重点的にkillしては様子を見て、ということをやってみたのですが、相変わらず阻害要因となっているプロセスを特定できませんでした。

もちろんその間、powercfg.exeでも原因を探ってみましたが、彼の報告によればスリープを無効にする要因はハードウェアからは全くなし、ソフトウェアからはWindows Updateの予約や録画予約ばかりで、いま、まさにスリープに入らない原因が全くない。
常にpollしてるんだろうから、動作ログ見せてくれれば一発なんだけどなぁ・・・

また、タスクスケジューラも全エントリを調査しましたが、スリープを解除してしまう悪い子は見当たりませんでした。

とにかく、ログアウト中はスリープするのにログイン中はスリープしないという奇妙な行動を突き止めることがなかなかうまくいかないため、さらにログオフ中とログイン中の稼働プロセスの違いをはっきりさせるため、後日ログオフ中でも稼働中のプロセスリストを取るサービスを書くことにして、次の確認項目としてUSB機器の取り外し試験を開始しました。

え?ログオフ?サインアウト?そうですか。

そこで、1つ抜いては数分待機、を繰り返した結果、表題の通り、「HID準拠ゲームコントローラ」が接続されていた場合にスリープしないことが分かりました。

まっさきに「HID準拠ゲームコントローラ」をデバイスマネージャで電源の設定を確認しましたが、これには「電源の管理」タブがありません。
しかし、その下にぶら下がっているコントローラ本体の「USB入力デバイス」では正しく「電力の節約のため、コンピューターでこのデバイスの電源をオフにできるようにする」チェックボックスはチェック済みとなっています。

そもそも、ログアウト中はスリープするわけですから、デバイスの設定としては正しいわけですよね。

powercfg.exeでスリープを拒止するプロセスもつかめないし、ログアウト中ならスリープするという点を見ると、どうもこりゃあ長丁場になりそうなので、今はとにかく、これを抜去しておきゃスリープはするわけですから、抜本的解決には至っておらず、まことに恐縮ですが毎月ン万円も電気代をTEPCOに支払う身としてはいまはこれまでとしておきたいと思います。

sleepに入るロジックの動作ログを見られればすぐわかるんだろうなぁ。。。

2015年9月9日水曜日

Windows10クリーンインストールが継続できない

豪華三本立ての回復パーティションを成敗して、さっそくクリーンインストールを開始してみました。
ものの見事に躓きました。
さすがわれらがマイクロソフト。期待を裏切りませんねぇ。
ちなみにアップグレードにかかった時間は3時間程度でした。

さて、そういうわけでインストールを開始したわけですが、ここで躓きました。
(写真が汚くてごめんなさい)


誰が所有してようがお前には関係ないだろうがボケ。とか思いつつ「私が所有しています」を選択しても何も起きない。
いや、正確にはHDDのアクセスランプが結構長い間バリバリに輝くのですが、次の工程に進まない。

では、というので今度は「自分の組織」を選択してみたところ、今度もHDDのアクセスランプが結構長い間バリバリに輝くのですが、やはり次の工程に進まない。

どっちを押しても、HDDのアクセスランプが結構長い間バリバリに輝くだけで何も起こらない。

アクセスランプが止まった後、しばらく放置して様子を見てみたのですが、やはり次の工程に進みません。

ほとほと困じ果ててしまいました(びっくり。今知ったけどMS-IMEでは「こうじはてる」が変換できなくなってる!昔はできたと思ったけど・・・)。
そもそもこの画面が問うている意味が分からないうえ、先にも進めないし後にも戻れない。そもそも写真をご覧いただくとわかるように、画面上に「次へ」ボタンも「戻る」ボタンもない。

それらのボタンが画面外になっちゃっているのかな、と思い、マウスカーソルを下や横へ持っていこうとしても、マウスカーソルは画面の縁から外へは移動できない。つまり、表示可能領域自身はシステムは正しく把握している様子。

さらにリターンキー連打とかALT+Nとか押してみても何も起きない。

なお、クリーンインストールを開始してからこの段階までで、1時間50分程度かかっています。

ちなみに、写真の画面を再現しようとして仮想マシン上で同一のDVDメディアからインストーラを起動して同一の画面を表示させてみると、「次へ」ボタンがしっかりあるではありませんか。



更新プログラムとか関係なく、完全にインストーラの不具合でした。
少なくともうちの環境では。

拝察するに、少しでもきれいに見せたいために余計な計算をして、最適な表示方法を見つけた「つもり」になっていて、変な描画処理を行った挙句に画面下部が切れているんでしょう。

マウスカーソルの移動範囲が画面内に限られるところから察するに、もう描画処理の問題としか思えません。
英語版前提のプログラムに日本語をのっけたからサイズ計算ミスっちゃったてへぺろ。とかそういう程度のくだらない理由で発生した障害に思えてなりません。

さすがは我等がグレイトでビッグでゴージャスなMS様です。確かWindows95だか98だかMeだかXPだか忘れましたが、同じように画面が表示しきれずインストールできないというトラブルがありました。
全く期待を裏切りません。さすが信頼のMS品質。
最初から小細工せずに従前通りVGA前提にしときゃいいのによ。バカジャネ?

しかも。
ALT+Nが効果がないはずですよ。
この画面だけ「次へ」ボタンにキーアサインがなされていないじゃないっすかあー。
すげーぐれーとっすねーまいくろそふとせんぱいーあこがれるっすー。

スクリーンショットをご覧になられるとお分かりいただけるかと思いますが、通常「次へ(&N)」となっているところ、&Nが抜けています。(画面表現上は&NはNにアンダーバー、つまり「次へ(N)」に見えます)。
端からキーボード+マウスでの操作がされることをこの画面「だけ」考慮からすっぽ抜けているわけです。

後から追加した画面なのかもしれませんね。
タブレットのことしか頭にないとこうなるというスバラシイ実例をまたもやご披露いただき感激の極みです。

ALT+Nも効かない、マウスで選択しようにも見えないどころか画面外にマウスカーソルが移動できないとなると、TABキーでまぐれ当たりを期待してフォーカスを変えまくって改行キー連打してまぐれ当たりを期待するということになりますが、そもそもこういう画面だということを知らないと極めて困難でしょうなあ。
バカジャネ?

以後も写真に撮っていればよかったのですが、かなりうんざりしながら作業していたので写真を撮ることをすっかり失念してしまっていました。ごめんなさい。
とはいえ、これだけへぼいインストーラですから、仮想マシンでも再現してくれることは期待度MAXです。
以後は仮想マシンで撮ったスクリーンショットを使用していこうと思います。

さてと、ともかく、この段階から進まないことには話になりません。
この前の画面でネットワーク経由でアップデートモジュールをインストールするからちょっと待てや、とかインストーラが言ってたことを思い出して、偉大かつ優渥なるグレイトなマイクロソフト様が言われてもいないしする必要もないアップデートをおかけくださったのかもしれないと思い、今度はLANケーブルを外して再チャレンジすることにしました。

再度DVDから起動し、Cドライブ予定地をフォーマットしなおしてインストール先に指定すると、また変な症状が発生しました。

こいつは仮想マシンでもばっちり再現しました。こんな具合に。


どっちもWindows10、しかも選択可能なパーティションも同じ。
つまり同じものが2つも選べて超お得!!!
この上ないゴージャスでリッチな感覚を味わうことができるのです。

こんなにおとくなういんどうずじゅうをせんたくしないわけにはまいりませんわー。
どっちがいいのかなーどっちでもおなじだけどなーてすとしてんのかなーしてねえよなー。
超品質たけえじゃん。

なお、さらにもう一度Cドライブ予定地をフォーマットしてインストールしようとすると、この選択肢は3つに増えました。もう気分はエグゼクティブぅ。

とか言ってても始まりませんからまあとにかく選びます。

すると先ほどと違って、誰の所有するPCか、などと聞かれずに、いきなりアカウント設定画面に進みました。
但し、この画面も実機ではまたもや「次へ」ボタンは表示されていませんでしたが、仮想マシンでは次のような画面です。




察するに、先ほどの誰の所有するPCか、などと聞いてくる画面は、マイクロソフトアカウントがらみのものだったんでしょうな。
正直、マイクロソフトアカウントというマイクロソフト様からのご優渥かつご寛大でゴージャスでジーニアスでクレバーでびゅーてほーなるお申し出を受けてPCを運用するという栄光に浴するには、私めなどは度胸も気力も体力も不足しているので、あのヘボ画面をスキップできてかえってラッキーだったようです。

こちらの画面も、繰り返しになりますが、実機では画面下にあるボタンが切れていたので、正直かなり困りました。
仕方がないので各項目欄に入力して、バンバン改行キーをたたいたりTABを連打したりしてたら次の行程に進みました。

この仮想マシンでのスクリーンショットを見て納得しましたが、偶然に「次へ(N)」のところにフォーカスがあるときに改行キーをたたけたんでしょうか。
これを幸運といっていいのかわかりませんが、まあ、幸運だったのでしょう。マイクロソフト様のお恵みかもしれません。

次の工程と書きましたが、この画面の後は、もう何もすることもなく、ちょっと待て、とか、もうしばらくだよ、とかさあはじめましょう、とか意味不明なご宣託が続いたのちにいきなりデスクトップに放り出されてインストール完了と相成りました。

LANケーブルを外しての再インストール時間はおおよそ40分でした。

手っ取り早くインストールするなら、アップグレード(ライセンスを獲得するときはやむを得ないかもしれません)やLANにつながった状態でインストールしてインストーラにアップデートさせるようなことはせずに、LANから切り離した状態で行うと1時間未満で処理が終わるのでお勧めです。

インストール完了直後の感想は「ほんとにテストしてんのかよ?」というものでした。

Windows8の時も同じようなことをこのblogで書かせていただいておりますが、あれから2年たってもおんなじ印象を抱かせるマイクロソフト様ってブレがないっすね。
どこぞの国も、野党からのツッコミ対策に、政府首班は見習われたらいかがかしらねぇ。


Windows10でもやっぱり増殖する回復パーティション

サーバが死んで絶望の淵に立たされている間に、Windows10へのアップグレードは一応完了したみたいでした。ライセンスさえ取れればいいので、ライセンスが取れていることを確認した後は特に動作確認もしませんでした。

しかし、とても期待していることがあるので、ライセンスが取れているかどうかはそっちのけでまず確認したのが以下の画像です。

ご覧ください、この実にばかばかしいスバラシイ有様を。


回復パーティションが豪華三本立てですよ奥様!!!

300MBの回復パーティション: Windows8のクリーンインストール時に作成されます。
450MBの回復パーティション: Windows8.1からのアップグレード時に作成されます。
363MBの回復パーティション: Windows8からのアップグレード時に作成されます。

Windows8から素直にアップグレードを重ねると、今なら回復パーティションが、もれなくなんと3つもついてきてお得です!!!

・・・もう、あまりにあほらしくて何と言っていいのかわかりません。
今なら、というより、必ず、なんですけどね。回復パーティションが3つできちゃうのって。
(Windows8をインストールする段階からでかい容量を回復パーティションに割り当てている人にはこのような現象は起きないでしょうが、Windows8をクリーンインストールするなど最低限の回復パーティション容量でインストールした人は、こうなります。)

もう馬鹿馬鹿しいし、一度ライセンスされたらインストール時にあの長ったらしいライセンスキーを入れずに済むという話を検証したかったので、ライセンスが取れていることを確認した後、即、クリーンインストールを開始しました。

なお、同一の物理ディスクにCドライブとDドライブがあっても、
  • Windows8で作成された回復パーティション
  • EFI用パーティション
  • MSR(マイクロソフト予約)用パーティション(GUIではなぜか表示されませんが実際には存在します)
  • Cドライブに指定していたパーティション(ここにWindows10が入っています)
  • Windows10で作成された回復パーティション
  • Windows8.1で作成された回復パーティション
を削除して、手動でパーティションを切ればDドライブは無事なままWindows10をクリーンインストールできましたので安心してください。

言うまでもありませんが、クリーンインストールを前提としておりますので、Windows10が入っているCドライブを削除しますとアップグレードした結果はすべて失われます
失って困るデータやアプリがある場合には作業の前にバックアップを取るなどの準備が必要となりますし、後戻りはできませんので十分にご留意ください

それではパーティション整理の手順を書きます。

手順の前提として、UEFI経由でブートするシステムで、Windows10をインストールする予定のドライブがDISK0、GPT形式であると仮定します。
MBRな方はちょっとばかり手順が変わりますが、現在でも由緒正しいMBRからブートされているほどの気合が入った方にはこのような説明など不要でしょうから割愛します。

さて、まず、Dドライブの前に配置されているパーティションを全部削除します。
ツールは何でもいいのですが、この際は事前に焼いておいたWindows10のDVDなりなんなりで起動し、コマンドプロンプトを立ち上げ、diskpart.exeを起動します。
コマンドプロンプトを起動する手順はインストールメディアからコンピューターを起動して、「コンピューターの修復」を選択し、「トラブルシューティング」を選択することで可能です。

diskpart.exeが起動したら、select disk 0 と入力してDISK0を選択し、list partitionと入力すると、次のようになっているはずです。
DISKPART> select disk 0
ディスク 0 が選択されました。
DISKPART> list partition
Partition ###  Type                Size     Offset
  -------------  ------------------  -------  -------
  Partition 1    回復                 300 MB  1024 KB
  Partition 2    システム             100 MB   301 MB
  Partition 3    予約                 128 MB   401 MB
  Partition 4    プライマリ           230 GB   529 MB
  Partition 5    回復                 450 MB   231 GB
  Partition 6    回復                 363 MB   232 GB
  Partition 7    プライマリ           699 GB   232 GB

上記の例だと、 Partition 7がDドライブに相当します(ディスクアドミニストレータでは見えなかったMSRも、ここではPartition3として正しく表示されています)。
従って、Partition 1から6を削除します。なお、パーティション番号だけは他と違って1から開始されます。MS-DOSから連綿と続く、極めて長い伝統の名残がここにも残っていますねぇ。

削除の手順はパーティションを選択後、削除、を6回繰り返します。
なお、パーティション4はCドライブですが、特にシステムに保護されていないのでdelete partition時にoverrideは不要です。それ以外の1,2,3,5,6番目のパーティションはoverrideが必要です。
DISKPART> select partition 1
パーティション 1 が選択されました。
DISKPART> delete partition override
DiskPart は選択されたパーティションを正常に削除しました。
DISKPART> select partition 2
パーティション 2 が選択されました。
DISKPART> delete partition override
DiskPart は選択されたパーティションを正常に削除しました。
DISKPART> select partition 3
パーティション 3 が選択されました。
DISKPART> delete partition override
DiskPart は選択されたパーティションを正常に削除しました。
DISKPART> select partition 4
パーティション 4 が選択されました。
DISKPART> delete partition
DiskPart は選択されたパーティションを正常に削除しました。
DISKPART> select partition 5
パーティション 5 が選択されました。
DISKPART> delete partition override
DiskPart は選択されたパーティションを正常に削除しました。
DISKPART> select partition 6
パーティション 6 が選択されました。
DISKPART> delete partition override
DiskPart は選択されたパーティションを正常に削除しました。
先頭から削除しても再起動しない限りパーティション番号は変わりません。
繰り返しになりますが、パーティションの4はCドライブで保護されていないのでdelete partition時にoverrideは不要です。それ以外の1,2,3,5,6番目のパーティションはoverrideが必要です。

さて、余計なものどもを成敗しましたので、今度はパーティションを再分割してあげます。
必要なパーティションは、

  1. 回復パーティション
  2. EFI用パーティション
  3. MSR用パーティション
  4. Cドライブ用パーティション
の計4パーティションとなります。

以後は煩瑣になるといけませんから、diskpart.exe上で入力するコマンドだけを記述します。
インデントされている行がコマンドを表し、1行で1コマンドです。

まず先頭に回復パーティションを作成します。Windows10の場合、容量は450MB必要です。但し、この例では今後のこともあり、嫌な予感がするので50MBおまけしてsize=500としました。4コマンド(4行)あります。
create partition primary size=500
format quick fs=ntfs label="Recovery"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
なお、以後作成するパーティションに共通しますが、formatコマンドにおけるlabel=は特に必要がありません。打鍵が面倒なら省いても構いません。また、HDDのチェックも同時に行いたいならquickを省いてください。

MBR形式の人はidが27なので楽ですが、今回の例ではGPTっていうくらいですからGUID形式でidを指定するため強烈に長いですが、この値がPARTITION_MSFT_RECOVERY_GUIDを示し、とても重要なので気を付けて入力して下さい。
また、属性値もやたらとゼロが続きますが、GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER(0x8000 0000 0000 0000)と
GPT_ATTRIBUTE_PLATFORM_REQUIRED(1)のOR(論理和)値を表していて、これも重要なので気を付けて入力してください。4桁の数値が連続して4つあることを考慮に入れて入力すれば、単純にゼロの個数をカウントするよりもミスも少なくなるでしょう。

次はEFIパーティションを作成します。容量は100MB必要です。
create partition efi size=100
format quick fs=fat32 label="ESP"

これだけでいいです。
次はマイクロソフト予約パーティション(MSR)を作成します。容量は128MB必要です。
create partition msr size=128

さらに行数が減って1行だけです。
最後に、Windows10をインストールするためのCドライブとなるべきパーティションを作成します。
create partition primary
format quick fs=ntfs label="cdrv"
サイズを指定していないので、Dドライブまでに空いている残り容量のすべて(Dドライブがなければハードディスクの残り容量全て)がこのパーティションへ割り当てられます

この段階でlist partitionを行うと次のようになっています。

DISKPART> list partition

  Partition ###  Type                Size     Offset
  -------------  ------------------  -------  -------
  Partition 1    回復                 500 MB  1024 KB
  Partition 2    システム               100 MB   501 MB
  Partition 3    予約                 128 MB   601 MB
  Partition 4    プライマリ              230 GB   729 MB
  Partition 7    プライマリ              699 GB   231 GB

パーティション番号の5,6が抜けていますが、気にすることはありません(Partition7は繰り返しになりますが温存しておいたDドライブです)。
なぜなら、この番号は現在起動中のシステムが認識した番号だからで、再起動してしまえば番号が振りなおされます。
つまり、この作業中に再起動してしまったらパーティション番号が変わるということです。ご留意ください。

こののちは、diskpartを終了しシステムを一度終了させ、再度Windows10のインストールメディアから起動して先ほど作成したCドライブの予定地を指定してインストールするだけです。

お疲れさまでした。

2015年9月8日火曜日

Windows10にしたらサーバがお亡くなりに。

先に申し上げますが、表題はまるっきり言いがかりです。
死因は全部私の責任と経年劣化によるものです。
ただ、Windows10にしようとしたことで始まる一連のくだらないドタバタ劇を一言で表そうとしたら、今回の表題となりました。

先日、PCの定例フルバックアップが終わったので、ちょうどよい機会だと思ってWindows10にアップグレードしてライセンスを取得しておこうと思いました。
一度やって、手順を確認しておきたかったというのもあります。

アップグレード中、退屈だし、アップグレード後にいろいろ試してみたりするだろうから当分サーバにはアクセスすることはないな、と思い、サーバ(Express5800)で稼働させているLinuxのカーネルのアップデートを行って再起動すると、何やら普段とは違うビープ音が。

驚いてモニタをつないでみると、CMOSチェックサムエラーが発生していたための警報音でした。
アア季節ノ変ワリ目ダナア、今回ハCMOSノ電池切レカ、随分長持チシタナァ、などと余裕ぶっこいてそのままOSを起動させようとしても起動処理途中で再起動してしまう。おまけにそのあと画面が真っ暗になったままBIOSも立ち上がらない。

電源を切って、再度入れると、やはりCMOSチェックサムエラーが発生。
リブート直前までは何の問題もなく稼働していたのだから、ナントカ起動してくれないかと思って何度も再起動を繰り返していると、今度はメモリスロットを検出したりしなくなったりしはじめてしまいました。それも、再起動するたびに見失うメモリスロットが異なる。

起動途中で停止してしまったり、インストールされているメモリを見失ったりするのは、これはCMOSの電池切れで発生しうる事態なのだろうかと考えると、ちょっと怪しいかもしれません。

現在もう一台のサーバ(こちらもExpress5800)も故障中なのを放置してあるため、ついにサーバが0台という非常事態となってしまいました。
しかもPCはWindows10へアップグレード中。思えばこのBloggerさんに間借りさせてもらうことにしたのは、PCとサーバが同時期にぶっ壊れたためでした。今回はまだPCは壊れていませんが、とても嫌な予感を感じてなりません。
思わず連れ合いのWindows7機を咄嗟に見たのは、内心いざとなったらあれを分捕ろうと思ったからかもしれません。

しかし、このサーバも、これまで何度か故障したとはいえパーツ交換で延命し続けてもう8年目。震災直後の計画停電時の故障から4年。前回の電源ユニットの故障からでも丸2年。よく頑張ってくれました。
いまだに性能的に全く不満を感じていないのでとても惜しいのですが、仮に電池交換でなおったとしても、これ以上の使用は危険かもしれないと思い、新規に調達することにしました。

最初は中古も考えたのですが、やはりサーバの中古だと24時間運用され酷使されていただろうからファンなどの可動部品などが心配だなあ、と考え直して、新品でリプレース機を検討することにしました。
とはいえ、最近は格安サーバって見かけないなあ、急な出費で憂鬱だなあ、とかぶつぶつ言いながら検索していると、驚いたことに2店で2万円程度で買える新品のサーバがありました。

まず一方はPentiumG3420/メモリ2GB/HDD250GBで17800円。ただし納期は一か月後。
もう一方はCeleronG1820/メモリ4GB/HDDなし+送料1000円で20980円。納期は1週間後。
どちらもPRIMERGY TX1310 M1。

うーん・・・PRIMERGYか・・・とほんの少し考えてしまいました。
というのは、あれって電源コネクタが独自仕様だから、HDDの次にぶっ壊れるはずの電源がへたったら本体より高い電源を買うか、またサーバを丸ごと交換するかの悲しい択一を迫られるわけです。また、その時に格安サーバが運良く見つかるかどうか。
しかし、それを勘案しても魅力的な価格ですのですぐ買うことに決めました。ともかくサーバが長期間ないととても困ります。

前者の店は価格が魅力ですが納期が不満でしたし、もともとHDDは不要なので、まずは後者の店で1台調達することにしました。
もし具合がよさそうだったら、今度は前者も検討してみたいと思っています。

先に故障していたサーバは単なるファイルサーバ用途でしたが、この年齢になるとHDDを組み付けたら20Kgを超えてしまうサーバ機を持って右往左往するのも随分きつくなってきたというのが、正直なところです。
もう今後は外付けHDDケースでもいいかな、とも思ってケースの値段を見てみると、HDDを4台収容可能なケースはこのサーバよりもお高いのでした。

まあ、経験上ではACアダプタがすぐ壊れるという懸念材料もありますし、下手に多数搭載できるケースは危険かもしれません。

故障中のファイルサーバは余ったHDDをRAID5でまとめていただけ(それでも4台で計1TBにはなっていましたのであながち馬鹿にできません)だったので、最近は大容量HDDもかなりお安いですし、USB3.0の普及で外付けHDDでも十分な速度が期待できますから、4TBのHDDを2台、ケースを2台買って、USB3.0でつなげてソフトウェアRAIDでも構築すればいいんじゃないかな、と思って調べてみると、Windows Vista以後は外付けHDDにはソフトウェアRAIDを構築できない制限が加えられているそうです。

もっとも、外付けHDDでRAIDを組もうなんて話、笑われちゃいそうではあります。
ですが、前提がファイルサーバの代用ですから、HDDが飛んだらハイオシマイ、では話になりませんよね。

だからと言って、RAID機能付きケースを買うという選択肢は、今回購入した格安サーバの数台分はかかりますから論外です。

若返ったつもりでサーバ機の質量を無視すれば別にこだわる必要はないのですが、ここはあくまでもケースにこだわるとした場合、今回購入した代替機でもLinuxが稼働予定ですので、こちらに外付けHDDで(すでにこちらのサーバもシステム1+データ2(RAID1)で計3台のHDDがあるので、さらに2台も内蔵できません。また、拡張SATAカードを増設するとした場合、電源容量が250Wの上、組み付ける場所があるかどうか、さらには組み付け後の通気も懸念材料となってしまいます)RAIDを組んでsambaで公開する、ということになりますが、やはりACアダプタな機器を24時間運用が予定されているサーバにくっつけておくというのはちょっとどうかと。

あくまでもケースにこだわるなら、自分で定期的に2台のHDDを同期してやるのが一番手っ取り早そうです。

手間と時間を惜しまないなら、まあ手動での同期でも構わないとは思いますが、素直にファイルサーバを立てたほうが、結局のところ楽ができるような気がするという、とても間が抜けた結論に達しました。

もうこの際、ファイルサーバを立てずに全部PCに取り込んでおいて、ファイルが必要になったらWoLか手動でPCを立ち上げてもらう運用にしておいて、共有ファイルは定期的に外付けの大容量HDDにバックアップを取るというのが一番楽かもしれませんね。
バックアップ間隔で障害が発生したら泣いて諦めるものと割り切る勇気があれば、ですが。

まあ、これがとりあえずドタバタ劇その1です。
こんなくだらない話がまだまだ続きます。

2015年8月28日金曜日

Goodgame Big Farm オーガニックマーケット:バリューレベルとボーナス値

続けざまで恐縮ですが、Big Farmにおける、あんまり意味がない情報です。

オーガニックマーケットにおけるバリューレベルとボーナス値の相関をグラフにしてみました。


何やら途中がやけに直線じゃねえか、と思われた方はさすがと申し上げます。
本来なら折れ線グラフで示してはならないデータを、さらに折れ線で示すとしても補間せずに結んじゃいけない点を結んでいるからです(バリューレベル20~57まで飛んでいます)。
何だか知りませんが、かれこれ実装以後結構長いことデータどりをしてみたものの、バリューレベルの30,40台がまるで出てきません。

まあ、式を立ててグラフ化すんの大げさだし、一目瞭然で脳内補間可能だからいいかなと。

で、生データは以下です。
バリューレベルボーナス(%)
00
11.92
23.43
34.69
56.69
78.26
88.93
99.55
1010.12
1110.65
1311.6
1412.04
1512.44
1612.83
1713.2
1813.55
2014.21
5721.14
5821.26
5921.38
6021.49
6121.61
6221.72
6421.94
6522.05
6622.16
6722.26
6822.36

バリューレベルが60を超えるとボーナス値の鈍化が際立ってきますが、ドル以外のオファーも目立ってくる傾向があるようです。

このデータの使い道はご覧の皆様次第でございます(丸投げ)。