前提条件として、ドメインなしActive Directoryなし、Workgroupのみの環境です。
smb.confに明示的にserver roleディレクティブを指定しない場合、server roleディレクティブの規定値はautoですが、samba4.8からserver roleがautoの場合の判定方法が変わって、security = userと設定してあっても、従来はWindows95用にdomain logons = yesという記述を残しっ放しにしていた場合でもROLE_STANDALONEと判定されていたケースがROLE_DOMAIN_PDCと判定されるように変更されたようです。
故に、記述を削除するか、または、smb.confに明示的に
server role = standalone
を記述すれば4.7以前の挙動に戻ります。
まあ、Linux同士(というかsamba同士)ならほっぽいておいても問題なく接続できます。
Windows10からつながらないことで原因調査に小一時間も無駄にしてしまったという恥を記録する次第です。
十年単位で毎度精査せず設定ファイルを引き継ぎまくってる報いでしょう。
おﾊｽﾞｶｼｲ次第です。
2018年12月20日木曜日
2018年12月10日月曜日
Windows10 October 2018 Updateの新規インストール時の回復ドライブは実は使われていない(ｶﾗｯﾎﾟ)
Windows8の頃から回復ドライブネタでいくつか当ブログで記事を書き散らしていますが、記事にコメントをいただいた際に、現時点での最新のWindows10 October 2018 Update(1809)のインストールメディアでクリーンインストールした場合、回復ドライブがどのように配置されるのか試した際に表題の件のような面白いことが分かりましたので記事にしてみたいと思います。
まず、クリーンインストール直後のパーティション構成は次のようになります。
相変わらず回復ドライブが先頭にあります。
なぜかディスクアドミニストレータではMSRが表示されないため、正確を期すためにdiskpartコマンドで実際のパーティション構成を表示した結果も掲載します。
実は、そもそもこれはマイクロソフト自身が2017年に公開した新レイアウトガイドに違反しています。
回復ドライブ、システム(EFI)、マイクロソフト予約(MSR)、Windowsインストール先パーティションの順にパーティションを構成するのは旧レイアウト仕様です。
MS自身が画定した新仕様ではEFI,MSR,Windowsインストール先パーティション、回復ドライブの順でなければなりません。
おまけに、回復ドライブの容量が499MBしか切ってないので、次回のメジャーアップグレード時に確実に廃棄され、Cドライブの後方が切り取られて回復ドライブにされてしまいます。
これで見事に回復ドライブが増殖するわけです。
MS自身で決めたルールをMS自身が破っているために結果としてユーザの計算機資源を奪うことになるわけです。
まあここまでだったら、ばかばかしいけど単に「相変わらずWindowsのインストーラの品質の低さは折り紙付きだなぁ」で終わりそうです。
しかし、これだけでは終わりません。
ここからがさらにお笑いなのです。
実は折角作成された回復ドライブ用のパーティションは使われていません。
何を言っているかわからないでしょう?
言い方を変えます。
回復ドライブ用のパーティションはｶﾗｯﾎﾟです。
実際に見てみましょう。
ディスクアドミニストレータでは回復ドライブにドライブレターを割り当てられませんので、diskpartコマンドで割り当てる必要があります。
ここではTドライブとしてアサインしました。
その中身をのぞいてみましょう。
System Volume Informationディレクトリ回復ドライブとは無関係です。「システムの復元」機能により勝手に全パーティションに生成されるものですので無視してください。
本当に何もないでしょう？
では、じゃあ一体回復ドライブはどこにあるんだ、ということになります。
調べ方はいたって簡単で、reagentcコマンドが教えてくれます。
試しに聞いてみましょう。
partition4とあります。
先のdiskpartコマンドによるパーティション一覧を思い出していただきたいのですが、パーティション番号4は「Cドライブ」を示しています。
従って、C:\Recovery\WindowsRE というところに配置されているというわけです。
つまり、回復ドライブなどははなっから嘘っぱちで実際には、Cドライブに回復環境が配置されているのです。
言い方を変えれば、Cドライブが回復ドライブを兼ねているということになります。
その理由はだた一つ、回復環境の容量に対して回復ドライブとしてインストーラが切ったパーティションサイズが不足しているからです。
1809の回復環境のファイルサイズは約485MBで、一見499MBあれば足りると思われるかもしれませんが、実は最低空き容量の規定があり、パーティションサイズが500MBを超える場合は320MBの容量が必要という仕様により、最低でも806MBなければならないために容量不足となってしまうわけです。
但し、最低空き容量が320MBという仕様書にある数値も眉唾でして、実際には、回復ドライブが実際に機能していたﾊﾞｰｼﾞｮﾝからアップグレードを重ねて1809にした別の環境では回復環境のサイズは510MBとなっておりますが、回復ドライブに奪われたサイズは878MBとなっており、その差が368MBとなっています。つまり仕様書には嘘っぱちの数値がかかれている可能性があり、実際には320MBの空き容量では足りない可能性があります。
ま、要するに新規インストール時に生成される回復ドライブというのは、現在では完全にユーザの計算機資源を無駄にするだけのものでしかないのでした。
しかも、ディスク全体ではなく、Cドライブが死ぬだけで回復環境も起動できないわけです。
自分自身の決め事を守らない上に、自分がインストールしようとするファイルのサイズをもとにパーティションサイズもろくに計算できないインストーラにはもう呆れを通り越して笑うしかないでしょう?
このような間抜けな事態を知るきっかけとなったこちらの記事にコメントをお寄せいただいた方に感謝いたします。
ありがとうございます。
なお、このような間抜けな事態を事前に回避するには、現状ですとWindows10をインストールする前に手動でパーティションを切り、それぞれのパーティションに対してidを振っておくなどパーティション構成を決定しておくほかに手段がありません。
その方法は手間ではあるものの作業としてはとても単純で、Windows10のインストールメディアさえあればdiskpartコマンドを用いてだれでもできます。
手順は本記事の末尾でご紹介いたしますMS自身が作成したご参考資料内にそのまま実行できるスクリプト形式で掲載されていますので割愛いたしますが、英語が面倒だという方は以前書いたこちらの記事が2015年の記事のため旧レイアウト仕様にあわせているものの、新レイアウトに従った順番に変えるだけですのでお役に立つかもしれません。
ただ・・・敢えてぶっちゃけていってしまいますが、今は亡きWindowsPhoneや特殊な構成のメーカお仕着せPCなどでは一般的なインストールメディアからインストールできないため必要でしょうけど、自分でWindows10をインストールできる人にとっては、この回復環境をわざわざ計算機上に配置する意味なんぞまったくないと思います。
インストールメディア上に全く同じ回復環境が用意されているからです。
今回の大型アップグレードでRedstone系列は終了し、次回はまた別シリーズとなります。
実は当ブログでも幾度か記事にさせていただきました通り、Windows8からWindows 10 November Update(1511、Threshold2)までは容量不足ならばアップグレードの際に無制限に回復ドライブの数が増えていくというとんでもない仕様でしたが、Redstone系列に入ってからは無制限な回復ドライブの増殖は行われなくなり、パーティションサイズを大きくできるなら大きくする、というように改善されました(むろん、今回のようにディスクの先頭にある場合は大きくできないので増殖することになりますが・・・)
次回以後の大型アップグレードの系列では、さらなる改善を期待したいと思います。あとインストーラを含めて品質管理をもうちょっとマシにしてください・・・
以上、お読みいただきありがとうございました。
ご参考：
UEFIの場合の新パーティションレイアウト資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions
MBRの場合の新パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions
UEFIの場合の旧パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744301(v=ws.10)
まず、クリーンインストール直後のパーティション構成は次のようになります。
なぜかディスクアドミニストレータではMSRが表示されないため、正確を期すためにdiskpartコマンドで実際のパーティション構成を表示した結果も掲載します。
DISKPART> list partなお、パーティション番号4のプライマリというところがディスクアドミニストレータでは(C:)と表示されている部分に相当し、ここにWindows10がインストールされています。
Partition ### Type Size Offset
------------- ------------------ ------- -------
Partition 1 回復 499 MB 1024 KB
Partition 2 システム 99 MB 500 MB
Partition 3 予約 16 MB 599 MB
Partition 4 プライマリ 59 GB 615 MB
実は、そもそもこれはマイクロソフト自身が2017年に公開した新レイアウトガイドに違反しています。
回復ドライブ、システム(EFI)、マイクロソフト予約(MSR)、Windowsインストール先パーティションの順にパーティションを構成するのは旧レイアウト仕様です。
MS自身が画定した新仕様ではEFI,MSR,Windowsインストール先パーティション、回復ドライブの順でなければなりません。
おまけに、回復ドライブの容量が499MBしか切ってないので、次回のメジャーアップグレード時に確実に廃棄され、Cドライブの後方が切り取られて回復ドライブにされてしまいます。
これで見事に回復ドライブが増殖するわけです。
MS自身で決めたルールをMS自身が破っているために結果としてユーザの計算機資源を奪うことになるわけです。
まあここまでだったら、ばかばかしいけど単に「相変わらずWindowsのインストーラの品質の低さは折り紙付きだなぁ」で終わりそうです。
しかし、これだけでは終わりません。
ここからがさらにお笑いなのです。
実は折角作成された回復ドライブ用のパーティションは使われていません。
何を言っているかわからないでしょう?
言い方を変えます。
回復ドライブ用のパーティションはｶﾗｯﾎﾟです。
実際に見てみましょう。
ディスクアドミニストレータでは回復ドライブにドライブレターを割り当てられませんので、diskpartコマンドで割り当てる必要があります。
ここではTドライブとしてアサインしました。
その中身をのぞいてみましょう。
T:\>dir /ash
ドライブ T のボリューム ラベルは 回復 です
ボリューム シリアル番号は 2AF2-7EC1 です
T:\ のディレクトリ
2018/12/10 16:13 <DIR> System Volume Information
0 個のファイル 0 バイト
1 個のディレクトリ 506,253,312 バイトの空き領域
System Volume Informationディレクトリ回復ドライブとは無関係です。「システムの復元」機能により勝手に全パーティションに生成されるものですので無視してください。
本当に何もないでしょう？
では、じゃあ一体回復ドライブはどこにあるんだ、ということになります。
調べ方はいたって簡単で、reagentcコマンドが教えてくれます。
試しに聞いてみましょう。
T:\>reagentc /info赤字のパーティション番号をご覧ください。
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:
Windows RE の状態: Enabled
Windows RE の場所: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
ブート構成データ (BCD) ID: 31b21218-fc4a-11e8-9a48-f962270261aa
回復イメージの場所:
回復イメージ インデックス: 0
カスタム イメージの場所:
カスタム イメージ インデックス: 0
REAGENTC.EXE: 操作は成功しました。
partition4とあります。
先のdiskpartコマンドによるパーティション一覧を思い出していただきたいのですが、パーティション番号4は「Cドライブ」を示しています。
従って、C:\Recovery\WindowsRE というところに配置されているというわけです。
つまり、回復ドライブなどははなっから嘘っぱちで実際には、Cドライブに回復環境が配置されているのです。
言い方を変えれば、Cドライブが回復ドライブを兼ねているということになります。
その理由はだた一つ、回復環境の容量に対して回復ドライブとしてインストーラが切ったパーティションサイズが不足しているからです。
1809の回復環境のファイルサイズは約485MBで、一見499MBあれば足りると思われるかもしれませんが、実は最低空き容量の規定があり、パーティションサイズが500MBを超える場合は320MBの容量が必要という仕様により、最低でも806MBなければならないために容量不足となってしまうわけです。
但し、最低空き容量が320MBという仕様書にある数値も眉唾でして、実際には、回復ドライブが実際に機能していたﾊﾞｰｼﾞｮﾝからアップグレードを重ねて1809にした別の環境では回復環境のサイズは510MBとなっておりますが、回復ドライブに奪われたサイズは878MBとなっており、その差が368MBとなっています。つまり仕様書には嘘っぱちの数値がかかれている可能性があり、実際には320MBの空き容量では足りない可能性があります。
ま、要するに新規インストール時に生成される回復ドライブというのは、現在では完全にユーザの計算機資源を無駄にするだけのものでしかないのでした。
しかも、ディスク全体ではなく、Cドライブが死ぬだけで回復環境も起動できないわけです。
自分自身の決め事を守らない上に、自分がインストールしようとするファイルのサイズをもとにパーティションサイズもろくに計算できないインストーラにはもう呆れを通り越して笑うしかないでしょう?
このような間抜けな事態を知るきっかけとなったこちらの記事にコメントをお寄せいただいた方に感謝いたします。
ありがとうございます。
なお、このような間抜けな事態を事前に回避するには、現状ですとWindows10をインストールする前に手動でパーティションを切り、それぞれのパーティションに対してidを振っておくなどパーティション構成を決定しておくほかに手段がありません。
その方法は手間ではあるものの作業としてはとても単純で、Windows10のインストールメディアさえあればdiskpartコマンドを用いてだれでもできます。
手順は本記事の末尾でご紹介いたしますMS自身が作成したご参考資料内にそのまま実行できるスクリプト形式で掲載されていますので割愛いたしますが、英語が面倒だという方は以前書いたこちらの記事が2015年の記事のため旧レイアウト仕様にあわせているものの、新レイアウトに従った順番に変えるだけですのでお役に立つかもしれません。
ただ・・・敢えてぶっちゃけていってしまいますが、今は亡きWindowsPhoneや特殊な構成のメーカお仕着せPCなどでは一般的なインストールメディアからインストールできないため必要でしょうけど、自分でWindows10をインストールできる人にとっては、この回復環境をわざわざ計算機上に配置する意味なんぞまったくないと思います。
インストールメディア上に全く同じ回復環境が用意されているからです。
今回の大型アップグレードでRedstone系列は終了し、次回はまた別シリーズとなります。
実は当ブログでも幾度か記事にさせていただきました通り、Windows8からWindows 10 November Update(1511、Threshold2)までは容量不足ならばアップグレードの際に無制限に回復ドライブの数が増えていくというとんでもない仕様でしたが、Redstone系列に入ってからは無制限な回復ドライブの増殖は行われなくなり、パーティションサイズを大きくできるなら大きくする、というように改善されました(むろん、今回のようにディスクの先頭にある場合は大きくできないので増殖することになりますが・・・)
次回以後の大型アップグレードの系列では、さらなる改善を期待したいと思います。あとインストーラを含めて品質管理をもうちょっとマシにしてください・・・
以上、お読みいただきありがとうございました。
ご参考：
UEFIの場合の新パーティションレイアウト資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions
MBRの場合の新パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions
UEFIの場合の旧パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744301(v=ws.10)
2018年11月21日水曜日
C#のListでGetRange()とToCopy()とBlockCopy()を比較してみた
知ってる人にとってはばかばかしいと思いますが、C#素人の悲しさ故に何でもやってみないとわからないので、恥ずかしながら今回は単純なﾘｽﾄの範囲コピーの速度比較をやってみました。
測定条件:
コピー元: List<float> 100000件
コピー先: float[]
コピー条件: コピー元の4000件目から最後まで(96000件)
コピー回数: 100000回
結果：
測定条件:
コピー元: List<float> 100000件
コピー先: float[]
コピー条件: コピー元の4000件目から最後まで(96000件)
コピー回数: 100000回
結果：
コピー先を使いまわす版は異常に高いnewのコストを除外するために測定しました。
とりあえずToCopyがいいみたいです。
以上です。
おまけ：
こんなコードで測定しました。
とりあえずToCopyがいいみたいです。
以上です。
おまけ：
こんなコードで測定しました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | public class ListCopySpeedTest { List<float> fl = new List<float>(); const int membernum = 100000; const int testcount = 100000; const int startindex = 4000; void init() { Random r = new Random(); for ( int i = 0; i < membernum; i++ ) { fl.Add( (float)r.NextDouble() ); } } float[] GetRange( float[] fa ) { fa = fl.GetRange( startindex, membernum - startindex ).ToArray(); return fa; } float[] ToCopy( float[] fa ) { if ( fa == null ) { fa = new float[ membernum - startindex ]; } fl.CopyTo( startindex, fa, 0, membernum - startindex ); return fa; } float[] BlockCopy( float[] fa ) { if ( fa == null ) { fa = new float[ membernum - startindex ]; } Buffer.BlockCopy( fl.ToArray(), startindex, fa, 0, membernum - startindex ); return fa; } delegate float[] testfunc_t(float[] floatarray); void testfunc( Stopwatch sw, testfunc_t f ) { float[] fa = null; for ( int j = 0; j < 2; j++ ) { sw.Reset(); sw.Start(); for ( int i = 0; i < testcount; i++ ) { f( fa ); } sw.Stop(); Console.WriteLine( f.Method.Name + ": " + sw.ElapsedMilliseconds + "ms" ); fa = new float[ membernum - startindex ]; } } public void test() { init(); Stopwatch sw = new Stopwatch(); testfunc( sw, GetRange ); testfunc( sw, ToCopy ); testfunc( sw, BlockCopy ); } } class Program { static void Main( string[] args ) { new ListCopySpeedTest().test(); Console.Read(); } } |
2018年11月15日木曜日
Windows 10 October 2018 Update(Redstone5)では回復ドライブは増殖せず肥大化するのね
ひとつ前の記事でWindows10を1803から1809にしたので、今度こそはまたまた前例通りにパーティションが増殖してくれていることを強く期待して、さっそくディスクアドミニストレータを見てみました。
あ～、今回もパーティションが増えてない・・・
ちぇ、と思って、がっかりするところでした。
が、よーく見ると、なんとサイズが増えて肥大化していたのでした(元は500MBでしたから378MB肥大化しました)。
Threshold2(1511)まではパーティションの数が増えてましたが、どうやらRedstone1(1607)以後はパーティションのサイズを奪い取る成長を遂げていたのですねえ。
それにしても空容量に対して使用量が60%、なんでこんな878MBなんて半端な数値なのかしら。
先頭にあるパーティション、Windows8.1から10にアップグレードしたときのあまりの増殖っぷりに驚いて大きめにわざわざ折角大きめに切ったのにぜーんぜん使われなくって、今はだぁれも住んでいない昔の回復パーティションなんですが、そこに十分おさまるじゃないですかぁやだぁ。
まあ、HDDなんで容量的にはどうでもいいし、パーティションが無意味に増殖してしまって分断されるよりははるかにましですのでさらにどーでもいいっちゃあいいんですが、Threshold2で勝手に作られた回復ドライブの容量が450MBだったことを思うと倍近いんですね。
もうWindows Phoneは放棄したし、あと必要そうなのは、メーカーお仕着せのノートパソコンのリカバリ用途くらいしかないけど、そういう用途ならOS丸ごと入っていたりするものなのでGB単位で切ってあるからますますこんなちっこい回復ドライブを必死に作る必要ってない気がするけど。
どうせストレージが死んだら道連れですし。
どこまで増やすのかな?
ちぇ、と思って、がっかりするところでした。
が、よーく見ると、なんとサイズが増えて肥大化していたのでした(元は500MBでしたから378MB肥大化しました)。
Threshold2(1511)まではパーティションの数が増えてましたが、どうやらRedstone1(1607)以後はパーティションのサイズを奪い取る成長を遂げていたのですねえ。
それにしても空容量に対して使用量が60%、なんでこんな878MBなんて半端な数値なのかしら。
先頭にあるパーティション、Windows8.1から10にアップグレードしたときのあまりの増殖っぷりに驚いて大きめにわざわざ折角大きめに切ったのにぜーんぜん使われなくって、今はだぁれも住んでいない昔の回復パーティションなんですが、そこに十分おさまるじゃないですかぁやだぁ。
まあ、HDDなんで容量的にはどうでもいいし、パーティションが無意味に増殖してしまって分断されるよりははるかにましですのでさらにどーでもいいっちゃあいいんですが、Threshold2で勝手に作られた回復ドライブの容量が450MBだったことを思うと倍近いんですね。
もうWindows Phoneは放棄したし、あと必要そうなのは、メーカーお仕着せのノートパソコンのリカバリ用途くらいしかないけど、そういう用途ならOS丸ごと入っていたりするものなのでGB単位で切ってあるからますますこんなちっこい回復ドライブを必死に作る必要ってない気がするけど。
どうせストレージが死んだら道連れですし。
どこまで増やすのかな?
Windows 10 October 2018 Updateが0x800F081F-0x20003で更新に失敗する
まず結論だけ述べます。
1803までで「Windows開発者モード」をインストールしていると「Windows 10 更新アシスタント(Windows10Upgrade9252.exe)」で1809への更新が失敗する場合があります。
結論は以上です。
以下余談です。
0x800F081FとはDISMのエラーコードそのままを吐いています。
枝番の0x20003は、「Windows 10 更新アシスタント」の更新作業の、どの段階で何をしていたかを示します。
0x200はアップグレードで行われる4段階中の2段階目、Safe OSでの作業中に起こった事象ということを示し、0x03がアップデート(この場合のアップデートとはWindows 10 October 2018 UpdateにあてるべきWindows Updateの事を指しています)をインストール中である事を示しています。
アップグレードとアップデートは言葉が似ているのでヤヤコシイ。
で、今回は
Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab
が原因でした。
DeveloperModeとファイル名にある通り、開発者モード用のパッチですが、これが不具合の原因ですので、これを回避すればいいわけです。
回避するには「Windows開発者モード」をアンインストールします。
アンインストールできる場所は「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」です。
勘違いしやすいので敢えて画像を添付します。
「設定」->「更新とセキュリティ」->「開発者向け機能を使う」->「開発者モード」ではないので念のためご注意申し上げます。
ちょっとお詳しい方ならDISMときたらsfc /scannowで解決だろ!とおっしゃる方もおいでかもしれません。
ところがどっこい、今回は不整合が検出されない場合のケースです。
redstone系列の最終段階であるWindows 10 October 2018 Updateが満を持して公開!!
・・・のはずが、直後にファイル消失という深刻な障害により公開中止となっていました。
ひと月以上たった昨日、ついに再公開されました。
今回も段階的にインストールできる人を増やしていくとのことで、まだ私の環境にはWindows Update経由ではインストールできませんでしたが、どうせWindows Updateの日なのでパッチが強制的に当たったうえに再起動を強制されるついでですので「Windows 10 更新アシスタント」を用いて一挙に更新してしまうことにしました。
1時間ほどかかった挙句、結局更新に失敗しました。
頭にきたので原因を探ってみました。
まず初回の失敗時の状況です。
当環境ではSandboxieというツールがインストールされているのですが、これをアンインストールしないと絶許ということでしたので、素直にアンインストールしたところ、まだSandboxieがあるじゃんアンインストールしろよと言われてしまい(つまりWindowsからは2つインストールされているように見えているようでした)、とはいっても、当方としてはもうこれ以上アンインストールできません。
とりあえずアンインストールを完了するには再起動しなさいとSandboxieに言われているところでしたので、「Windows 10 更新アシスタント」を中断してから再起動し、再起動後に再度「Windows 10 更新アシスタント」を起動したころ、なんだかWindows 10 October 2018 Updateの更新作業が進みだしてしまいました。
まあ、とりあえずなぜか進んだので、Sandboxieが原因だったのかな、それにしても何でインストールが先に進んでしまったのだろう、2つのうち一つしかアンインストールしていないわけですから進んじゃいけないはずなんだから、それって不具合だよねやっぱりテストしてないよね怖いよね、と思いながら眺めていましたが、今回もやっぱり更新中の再起動一回目の進捗14%のところで失敗して1803に巻き戻されました。
この際、何のエラーコードも表示されず、イベントログにも何も残っていませんでした。
普通こういう大型アップデートをかける場合は寝る前とか帰宅前とかで行うでしょうから、失敗だろうが成功だろうが結果を表示しなければ普通の人は「あ、(正常に)終わったのね」としか思わないはずです。
なんて不親切な設計なのかとびっくりしました。
Sandboxieのアンインストールに伴う再起動がまずかったのかな、と思い、再度「Windows 10 更新アシスタント」で更新を開始しましたが、今度も「Sandboxieをアンインストールしてください」と言われてしまい途方にくれました。
レジストリにゴミが残っちゃったのかしら、と舐めるように点検してもSandboxieなんかないし、どうしたものか、と思っていると、別ドライブにバックアップとしてファイルのコピーだけしてあったSandboxieのﾌｧｲﾙ群があるのを発見しました。
ダメ元でそのファイルを削除したところ、それだけでインストールが再開されました。
バックアップだろうが何だろうが、どうせ動かないプログラムだろうと何だろうと、とにかくマイクロソフト様が許さないと指名したファイルがあるというだけでインストールさせないほど超コワモテな姿勢です。
動いているデバイスドライバでも何でもないそんなものをチェックする余裕がある癖に、今回のインストールの失敗の原因(説明はこの記事の後のほうになります)は超単純なのにチェックしてないってのがとてもｽﾊﾞﾗｼｲ。
ですが、インストールが先に進みはしたものの、やっぱり1回目の再起動後の進捗率14%の段階でロールバックされてしまいました。
これ自体は前回と同じ結果でしたのでSandboxieそのものが原因ではないことはわかりました。
しかし、今回は前回と変わって大きな違いがありました。
ロールバック後に「Windows 10 更新アシスタント」が勝手に画面をポップアップしてエラーコードを表示して教えてくれたのです。
それが「0x800F081F - 0x20003」でした。
さっきは不親切さにびっくりしましたが、今度は「あ、本当は結果を表示するはずだったのね」という意味でびっくりしました。
結果が表示されないのはバグだったんですね。
この後も含めて、結局何回か更新作業を行うことになってしまったのですが、後にも先にもこの時しか「Windows 10 更新アシスタント」さんはエラーコードを教えてくれず、1回目と同様に何も表示されないまま1803にロールバックされました。
当然イベントログにも何の情報もありません(何のためのイベントログなんだか)。
やっぱりこの辺もユーザにエラーを通知する機能のテストが全然できてないものとお見受けいたします。
不安をさらに煽ってくれるいいスパイスとなりました。
でもまあ、いつものように「はじめました」->「やってます」->「できませんでした」という無意味なメッセージではなく、兎にも角にもエラーコードを教えてもらえただけでも幸運でした。
早速エラーコードでgoogle検索様に教えを請いましたところ、エラーコードの意味そのものは引っかかりませんでしたが、DISMがこのエラーコードをよく吐くという文言があちこちの検索結果から目に入りました。
こんな数値、とても偶然の一致とは思えません。
そーいやBCDとかもVistaからだったなあ、あの時なんかすげぇ苦労して今はidすら忘れた某ソーシャルサイトで長い記事書いたっけなぁとか眠い頭で連想するうちにsetupact.logの存在を思い出しました。
アップグレードの手順はVistaのころから変わっておらず、「何回か再起動されます」なんて曖昧なことを言われますが、実はアップグレード時のリブート回数は特殊なデバイスを搭載していない限り決まっています。
たとえば今回のように1803上「Windows 10 更新アシスタント」を用いた場合、リブートの1回目は元のOS上でインストールすべきファイルを収集し終えたあと、2回目はSafeOS上での手順がおわるまで、3回目はそれ以降の手順です。
で、なんで回数なんかに着目するかというと、何回目にリブートされたかによってログが吐かれる場所が変わるからです。
余談ですがこれはVistaSP1のころから変わっていません。さすがWindowsNT6.0というだけあっただけにXPのNT5系列から劇的な変化を遂げています。
製品としてのWindows10も(製品名とカーネル番号だけを合わせたので表示上はWindowsNT10.0ですが)実はカーネルは(まだ)WindowsNT6.4相当なのでその辺はほとんど変更がありません。
実際、1803でもﾊﾞｰｼﾞｮﾝは10.0.17134のままですし、今回の1809も10.0.17763です。
これらのバージョン情報はエンドユーザからは簡単には見えませんが、実はコマンドプロンプトでverコマンド(winverコマンドではありません)を入力すると確認できます。
まあ、普通の人はコマンドプロンプトなんか使いませんよね。
この国のIT業界ではスマホのほうがﾒｰﾙ書くのはえぇっすよぉPCなんかつかってらんねぇっすよぉの世界が普通だそうです(えくせるほーがんしやぱわぽでの資料作成を命じると翌日には求人枠が一つ空くとかあかないとか)。
ま、そんなわけですので、Vistaのガワだけ取り替えて見た目は劇的に変わってはいるものの、OSの大規模更新といったようなコアとなるような機能では、Vistaのころからのトラブルシューティングの知見が随分流用できます。
で、今回はsafeos内手順中での作業中の事故ということが0x20003の0x200の部分でも教えてくれていますので、そこにあるべきsetupact.logを検索しました。
すると、こんな行が見つかりました。
2018-11-14 22:10:04, Error SP CAddPackage::DoExecute: Failed to add package Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab. Error: 0x800F081F
これで0x800F081Fの出所もわかったし確かに枝番からわかる0x200の意味するところのSP_EXECUTION_SAFE_OSで 0x03の意味するところのSP_EXECUTION_OP_INSTALL_UPDATES でエラーが起きたことは確かだということが分かりました。
が、これ、実は、まだこれだけじゃ終わりません。
実際にはこのファイルは正しい形式で既定の場所にダウンロードされており、このMicrosoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab自体に問題はありません(ファイル名長すぎ)。
ですので、このファイルだけひねくり回しても何の解決にもなりません。
Errorとして報告されていない部分が実際の異常の原因なのでした。
このエラーだけ見るとMicrosoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cabが異常だと思うじゃないですか。
本当は、このcabファイルがさらに必要とするファイルがあって、それがないという情報はErrorではなくInfoとして報告されているのです。
こんな具合です。
2018-11-14 22:10:03, Info CBS FOD: Missing payload: Microsoft.WebDriver~~~~0.0.1.0
2018-11-14 22:10:03, Info CBS Missing payload found on FOD execution [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Exec: Failed to retrieve FOD payload [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Failed to download and plan capabilities [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Failed to plan execution. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Error CBS Failed to process single phase execution. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS WER: Generating failure report for package: Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~10.0.17763.1, status: 0x800f081f, failure source: CBS Other, start state: Absent, target state: Absent, client id: DISM Package Manager Provider
つまり、WebDriverが必要なのにそれを適用しようとせずに、セットアップスクリプトが依存関係を無視してMicrosoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cabを入れようとしてるのが悪いわけです。
これもバグですよねぇ。
なぜなら、Windows開発者モードが搭載された
「Windows 10 Anniversary Update(1607,redstone1)」
から、その後の
「Windows 10 Creators Update (1703,redstone2)」、
「Windows 10 Fall Creators Update (1709,redstone3)」、
「Windows 10 April 2018 Update (1803,redstone4)」
まで、3回もの大型更新ではまったく問題がないんですから完全にアウトですよねえ。
なぜ今回問題となったかというと、Features on Demand(FoD)化にあるんだと思います。
WebDriverは1908からFoDとしてDISMからインストールできるのですが、1903まではFoD化されてません。インストーラ経由でのインストールになります。
新機能を追加したのにテスト設計チームに全然伝わっておらず、テスト仕様書からごっそりと抜け落ちていたんでしょう。
最近のMSくぉりちーがここにも遺憾なく発揮されてしまったようです。
MS製WebDriverをわざわざ入れる人って極めて貴重なEdgeマニア(そんな人いるのかな)か、業務でEdgeらされている人だけでしょう。
業務としてはお気の毒ではありますがこのバグには遭遇しないと思いますので、日ごろの艱難辛苦が報われたことは誠にご同慶の至りです。
そして、1809になったらなったで、今度は「Windows開発者モード」が「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」->「機能の追加」から消えてしまっています。
これは多分、「設定」->「更新とセキュリティ」->「開発者向け機能を使う」->「開発者モード」を選択したら自動的にインストールされるからいいだろ、ということだと思います。
実際にやってみたところ、選択すると自動で「Windows開発者モード」がインストールされてしまいます。
明示的にユーザがインストールしたわけじゃないのに無理やりされちゃいます。
但し、インストール済みとして表示はされるようにはなるので、そのことを知ってさえいれば削除は可能です。
ところで、1809ではその代わりに、今度は「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」->「機能の追加」にWebDriverが追加されています。
わはは。
UWP早くなくなれ。
ところで。
インストールの最終段階の全画面でのあの無意味な「こんにちは」から始まる一連のやつは今回も健在でした。
もう結構です。
口だけは達者と言われちゃっても知らないぞ。
それにしても、なんだかんだ言って使いやすいOSであることには違いないのになぁ。
先日のライセンス認証サーバがこけちゃう大ポカとか、ファイル消失なんてあっちゃいけないバグが分かってて出荷して出荷停止にする激ポカとか、小一時間は軽くかかるアップデートでこんなくだらないバグを出すとか、FHDだろうが4Kだろうが8Kだろうがお構いなく全画面でこんにちはとか言ってるようじゃどうしようもないんじゃないかなあ。
折角のOSの魅力を自分でスポイルするのはなんかの呪いなんですかねぇ。
1803までで「Windows開発者モード」をインストールしていると「Windows 10 更新アシスタント(Windows10Upgrade9252.exe)」で1809への更新が失敗する場合があります。
結論は以上です。
以下余談です。
0x800F081FとはDISMのエラーコードそのままを吐いています。
枝番の0x20003は、「Windows 10 更新アシスタント」の更新作業の、どの段階で何をしていたかを示します。
0x200はアップグレードで行われる4段階中の2段階目、Safe OSでの作業中に起こった事象ということを示し、0x03がアップデート(この場合のアップデートとはWindows 10 October 2018 UpdateにあてるべきWindows Updateの事を指しています)をインストール中である事を示しています。
アップグレードとアップデートは言葉が似ているのでヤヤコシイ。
で、今回は
Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab
が原因でした。
DeveloperModeとファイル名にある通り、開発者モード用のパッチですが、これが不具合の原因ですので、これを回避すればいいわけです。
回避するには「Windows開発者モード」をアンインストールします。
アンインストールできる場所は「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」です。
勘違いしやすいので敢えて画像を添付します。
「設定」->「更新とセキュリティ」->「開発者向け機能を使う」->「開発者モード」ではないので念のためご注意申し上げます。
ちょっとお詳しい方ならDISMときたらsfc /scannowで解決だろ!とおっしゃる方もおいでかもしれません。
ところがどっこい、今回は不整合が検出されない場合のケースです。
redstone系列の最終段階であるWindows 10 October 2018 Updateが満を持して公開!!
・・・のはずが、直後にファイル消失という深刻な障害により公開中止となっていました。
ひと月以上たった昨日、ついに再公開されました。
今回も段階的にインストールできる人を増やしていくとのことで、まだ私の環境にはWindows Update経由ではインストールできませんでしたが、どうせWindows Updateの日なのでパッチが強制的に当たったうえに再起動を強制されるついでですので「Windows 10 更新アシスタント」を用いて一挙に更新してしまうことにしました。
1時間ほどかかった挙句、結局更新に失敗しました。
頭にきたので原因を探ってみました。
まず初回の失敗時の状況です。
当環境ではSandboxieというツールがインストールされているのですが、これをアンインストールしないと絶許ということでしたので、素直にアンインストールしたところ、まだSandboxieがあるじゃんアンインストールしろよと言われてしまい(つまりWindowsからは2つインストールされているように見えているようでした)、とはいっても、当方としてはもうこれ以上アンインストールできません。
とりあえずアンインストールを完了するには再起動しなさいとSandboxieに言われているところでしたので、「Windows 10 更新アシスタント」を中断してから再起動し、再起動後に再度「Windows 10 更新アシスタント」を起動したころ、なんだかWindows 10 October 2018 Updateの更新作業が進みだしてしまいました。
まあ、とりあえずなぜか進んだので、Sandboxieが原因だったのかな、それにしても何でインストールが先に進んでしまったのだろう、2つのうち一つしかアンインストールしていないわけですから進んじゃいけないはずなんだから、それって不具合だよねやっぱりテストしてないよね怖いよね、と思いながら眺めていましたが、今回もやっぱり更新中の再起動一回目の進捗14%のところで失敗して1803に巻き戻されました。
この際、何のエラーコードも表示されず、イベントログにも何も残っていませんでした。
普通こういう大型アップデートをかける場合は寝る前とか帰宅前とかで行うでしょうから、失敗だろうが成功だろうが結果を表示しなければ普通の人は「あ、(正常に)終わったのね」としか思わないはずです。
なんて不親切な設計なのかとびっくりしました。
Sandboxieのアンインストールに伴う再起動がまずかったのかな、と思い、再度「Windows 10 更新アシスタント」で更新を開始しましたが、今度も「Sandboxieをアンインストールしてください」と言われてしまい途方にくれました。
レジストリにゴミが残っちゃったのかしら、と舐めるように点検してもSandboxieなんかないし、どうしたものか、と思っていると、別ドライブにバックアップとしてファイルのコピーだけしてあったSandboxieのﾌｧｲﾙ群があるのを発見しました。
ダメ元でそのファイルを削除したところ、それだけでインストールが再開されました。
バックアップだろうが何だろうが、どうせ動かないプログラムだろうと何だろうと、とにかくマイクロソフト様が許さないと指名したファイルがあるというだけでインストールさせないほど超コワモテな姿勢です。
動いているデバイスドライバでも何でもないそんなものをチェックする余裕がある癖に、今回のインストールの失敗の原因(説明はこの記事の後のほうになります)は超単純なのにチェックしてないってのがとてもｽﾊﾞﾗｼｲ。
ですが、インストールが先に進みはしたものの、やっぱり1回目の再起動後の進捗率14%の段階でロールバックされてしまいました。
これ自体は前回と同じ結果でしたのでSandboxieそのものが原因ではないことはわかりました。
しかし、今回は前回と変わって大きな違いがありました。
ロールバック後に「Windows 10 更新アシスタント」が勝手に画面をポップアップしてエラーコードを表示して教えてくれたのです。
それが「0x800F081F - 0x20003」でした。
さっきは不親切さにびっくりしましたが、今度は「あ、本当は結果を表示するはずだったのね」という意味でびっくりしました。
結果が表示されないのはバグだったんですね。
この後も含めて、結局何回か更新作業を行うことになってしまったのですが、後にも先にもこの時しか「Windows 10 更新アシスタント」さんはエラーコードを教えてくれず、1回目と同様に何も表示されないまま1803にロールバックされました。
当然イベントログにも何の情報もありません(何のためのイベントログなんだか)。
やっぱりこの辺もユーザにエラーを通知する機能のテストが全然できてないものとお見受けいたします。
不安をさらに煽ってくれるいいスパイスとなりました。
でもまあ、いつものように「はじめました」->「やってます」->「できませんでした」という無意味なメッセージではなく、兎にも角にもエラーコードを教えてもらえただけでも幸運でした。
早速エラーコードでgoogle検索様に教えを請いましたところ、エラーコードの意味そのものは引っかかりませんでしたが、DISMがこのエラーコードをよく吐くという文言があちこちの検索結果から目に入りました。
こんな数値、とても偶然の一致とは思えません。
そーいやBCDとかもVistaからだったなあ、あの時なんかすげぇ苦労して今はidすら忘れた某ソーシャルサイトで長い記事書いたっけなぁとか眠い頭で連想するうちにsetupact.logの存在を思い出しました。
アップグレードの手順はVistaのころから変わっておらず、「何回か再起動されます」なんて曖昧なことを言われますが、実はアップグレード時のリブート回数は特殊なデバイスを搭載していない限り決まっています。
たとえば今回のように1803上「Windows 10 更新アシスタント」を用いた場合、リブートの1回目は元のOS上でインストールすべきファイルを収集し終えたあと、2回目はSafeOS上での手順がおわるまで、3回目はそれ以降の手順です。
で、なんで回数なんかに着目するかというと、何回目にリブートされたかによってログが吐かれる場所が変わるからです。
余談ですがこれはVistaSP1のころから変わっていません。さすがWindowsNT6.0というだけあっただけにXPのNT5系列から劇的な変化を遂げています。
製品としてのWindows10も(製品名とカーネル番号だけを合わせたので表示上はWindowsNT10.0ですが)実はカーネルは(まだ)WindowsNT6.4相当なのでその辺はほとんど変更がありません。
実際、1803でもﾊﾞｰｼﾞｮﾝは10.0.17134のままですし、今回の1809も10.0.17763です。
これらのバージョン情報はエンドユーザからは簡単には見えませんが、実はコマンドプロンプトでverコマンド(winverコマンドではありません)を入力すると確認できます。
まあ、普通の人はコマンドプロンプトなんか使いませんよね。
この国のIT業界ではスマホのほうがﾒｰﾙ書くのはえぇっすよぉPCなんかつかってらんねぇっすよぉの世界が普通だそうです(えくせるほーがんしやぱわぽでの資料作成を命じると翌日には求人枠が一つ空くとかあかないとか)。
ま、そんなわけですので、Vistaのガワだけ取り替えて見た目は劇的に変わってはいるものの、OSの大規模更新といったようなコアとなるような機能では、Vistaのころからのトラブルシューティングの知見が随分流用できます。
で、今回はsafeos内手順中での作業中の事故ということが0x20003の0x200の部分でも教えてくれていますので、そこにあるべきsetupact.logを検索しました。
すると、こんな行が見つかりました。
2018-11-14 22:10:04, Error SP CAddPackage::DoExecute: Failed to add package Add [1] package C:\$WINDOWS.~BT\DUImageSandbox\Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab. Error: 0x800F081F
が、これ、実は、まだこれだけじゃ終わりません。
実際にはこのファイルは正しい形式で既定の場所にダウンロードされており、このMicrosoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cab自体に問題はありません(ファイル名長すぎ)。
ですので、このファイルだけひねくり回しても何の解決にもなりません。
Errorとして報告されていない部分が実際の異常の原因なのでした。
このエラーだけ見るとMicrosoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~.cabが異常だと思うじゃないですか。
本当は、このcabファイルがさらに必要とするファイルがあって、それがないという情報はErrorではなくInfoとして報告されているのです。
こんな具合です。
2018-11-14 22:10:03, Info CBS FOD: Missing payload: Microsoft.WebDriver~~~~0.0.1.0
2018-11-14 22:10:03, Info CBS Missing payload found on FOD execution [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Exec: Failed to retrieve FOD payload [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Failed to download and plan capabilities [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS Failed to plan execution. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Error CBS Failed to process single phase execution. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2018-11-14 22:10:03, Info CBS WER: Generating failure report for package: Microsoft-OneCore-DeveloperMode-Desktop-Package~31bf3856ad364e35~amd64~~10.0.17763.1, status: 0x800f081f, failure source: CBS Other, start state: Absent, target state: Absent, client id: DISM Package Manager Provider
これもバグですよねぇ。
なぜなら、Windows開発者モードが搭載された
「Windows 10 Anniversary Update(1607,redstone1)」
から、その後の
「Windows 10 Creators Update (1703,redstone2)」、
「Windows 10 Fall Creators Update (1709,redstone3)」、
「Windows 10 April 2018 Update (1803,redstone4)」
まで、3回もの大型更新ではまったく問題がないんですから完全にアウトですよねえ。
なぜ今回問題となったかというと、Features on Demand(FoD)化にあるんだと思います。
WebDriverは1908からFoDとしてDISMからインストールできるのですが、1903まではFoD化されてません。インストーラ経由でのインストールになります。
新機能を追加したのにテスト設計チームに全然伝わっておらず、テスト仕様書からごっそりと抜け落ちていたんでしょう。
最近のMSくぉりちーがここにも遺憾なく発揮されてしまったようです。
MS製WebDriverをわざわざ入れる人って極めて貴重なEdgeマニア(そんな人いるのかな)か、業務でEdgeらされている人だけでしょう。
業務としてはお気の毒ではありますがこのバグには遭遇しないと思いますので、日ごろの艱難辛苦が報われたことは誠にご同慶の至りです。
そして、1809になったらなったで、今度は「Windows開発者モード」が「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」->「機能の追加」から消えてしまっています。
これは多分、「設定」->「更新とセキュリティ」->「開発者向け機能を使う」->「開発者モード」を選択したら自動的にインストールされるからいいだろ、ということだと思います。
実際にやってみたところ、選択すると自動で「Windows開発者モード」がインストールされてしまいます。
明示的にユーザがインストールしたわけじゃないのに無理やりされちゃいます。
但し、インストール済みとして表示はされるようにはなるので、そのことを知ってさえいれば削除は可能です。
ところで、1809ではその代わりに、今度は「設定」->「アプリ」->アプリと機能欄の「オプション機能の管理」->「機能の追加」にWebDriverが追加されています。
このためにFoD化したんですよねきっと。
上記のラジオボタン選択による「Windows開発者モード」の強制インストールが行われても、一見WebDriverはインストールされないように見えて実はされちゃいます。
どうせ一緒にインストールされちゃうなら、折角の大型アップグレードなんだから一緒のパッケージにすればいいのに。
どうせ一緒にインストールされちゃうなら、折角の大型アップグレードなんだから一緒のパッケージにすればいいのに。
まあ、要するにこのラジオボタン選択で自動で行われるインストール作業がアップグレード時には行われないのが今回のバグの原因ということなんでしょう。
こんなんじゃ近いうちにまたWindows Updateで問題が起きるかもしれません。
開発者モードはWindows 10 Anniversary Updateでbashが使いたいときにどうしてもインストールしなくちゃいけなかった機能でしたが、その後のWindows 10 Fall Creators Updateからは開発者モードにしなくても使えるようになりましたので、いまでは(もしかしたらUWPの案件が・・・なんて淡い期待とともに、あるいは完全に忘れっぱなしで)そのままにしておいた人や、本当にUWPの開発をしていてWebDriverが不要だった人に直撃です。
本気でUWPを普及させたいから、自分で「Windows開発者モード」を選択してインストールしなくても黙って入れちゃえよ～ともかく敷居だけでも下げられねぇかな～たのむよ～なんとかしてくれよぉ～、という経営上の要請が、WebDriverのほうもやっぱり、Edge普及しねぇんだよぉ～あのFirefoxにも負けてんだよぉ～たのむよぉ～インストーラなんか探さなくても手軽に入れられるようになんねぇかなぁ～、という市場戦略上の要請が、それぞれありありと見えますが、それでこんなバグだしてんだから世話ねえやね。開発者モードはWindows 10 Anniversary Updateでbashが使いたいときにどうしてもインストールしなくちゃいけなかった機能でしたが、その後のWindows 10 Fall Creators Updateからは開発者モードにしなくても使えるようになりましたので、いまでは(もしかしたらUWPの案件が・・・なんて淡い期待とともに、あるいは完全に忘れっぱなしで)そのままにしておいた人や、本当にUWPの開発をしていてWebDriverが不要だった人に直撃です。
わはは。
UWP早くなくなれ。
ところで。
インストールの最終段階の全画面でのあの無意味な「こんにちは」から始まる一連のやつは今回も健在でした。
それにしても、なんだかんだ言って使いやすいOSであることには違いないのになぁ。
先日のライセンス認証サーバがこけちゃう大ポカとか、ファイル消失なんてあっちゃいけないバグが分かってて出荷して出荷停止にする激ポカとか、小一時間は軽くかかるアップデートでこんなくだらないバグを出すとか、FHDだろうが4Kだろうが8Kだろうがお構いなく全画面でこんにちはとか言ってるようじゃどうしようもないんじゃないかなあ。
折角のOSの魅力を自分でスポイルするのはなんかの呪いなんですかねぇ。
2018年10月31日水曜日
KB4462933をインストール後HID準拠ゲームコントローラー(ジョイパッド)が接続されているとスリープしない・・・？
変な表題ですが、理由があります。
結論だけ言うと「KB4462933を再インストールしたら再現しなくなった」ように見せかけて「やっぱり再現した」ものの「再インストールしなくても再現しなくなった」です。
何が何だかさっぱりわかりません。
調査を進めてみると、もしかしてこの事象が発生するのはKB4462933に限らないかもしれない可能性が疑われました。
さらにその後、やっぱりKB4462933が原因だろうと考えざるを得ない事態が出来しました。
ちょっと複雑なので、順を追ってご説明いたします。
まず、以前にもありましたが、またもやUSBで接続されたジョイパッド(MS用語では"HID 準拠ゲーム コントローラー")が接続されていると、アイドル状態が続いて既定の時刻になってもスリープどころかブランクスクリーン(MS用語では"ディスプレイの電源を切る")にもならなくなりました。
あくまでもアイドル状態が指定時間続いた場合にスリープに入らないので手動でスリープを指示すれば正しくスリープに入ります。
ジョイパッドを抜去すると再度アイドル状態が続いた後に自動でスリープに入るようになります。
今回はKB4462933を適用した直後からこの事象が発生しました。
イベントログで確認しても、このKB4462933がインストールされてから丸一日後(たまたま長時間不在の中での更新でした)に気が付いて、試しに手動でスリープボタンを押下するまでスリープに入っていないことが記録されています。
家族に聞いても(常時私のPCを監視しているわけではないのでイベントログほど確実性はないものの)画面がつきっぱなしだったと言われましたので、スリープに入っていないことは確実です。
前回同じようなことを経験しているので、試しに接続されたままだったジョイパッドを抜去して待ってみると、正常に一定時間経過によって自動的にスリープしました。
試しに再起動してみても、ジョイパッドを接続しなおしたり接続ポートを変更してもこの状況は変わりませんでした。
一応、極めて黒に近い灰色に思われましたが、このまま犯人だと決めつけて間違っていたら間抜けなので、念のためにKB4462933をアンインストールして同様の試験したところ、自動的にスリープに入ることを確認しました。
さらに念のため、アンインストール前と設定が変わっていないかどうかの比較のため、以前のようにデバイスマネージャで電源設定を確認したりコントロールパネル->電源オプション->プラン設定の編集をチェックしましたが、両者の間で変更点は全くありませんでした。
powercfg.exe /requestsの結果も双方「なし。」の羅列で阻害要因なし。
powercfg.exe /energyの結果も双方阻害要因なし。
言い方を変えれば、powercfg.exe /requestsの結果および/energyの結果にKB4462933適用済の時とKB4462933未適用の時での差異が一切ありません(が挙動は異なる)という状況でした。
ここまでで犯人もわかったことだし、面倒ではあるけど対策はあるわけだからよしとして、暇なときにでも今度はもうちょっと原因を突っ込んで調べてみよう、ということでこの記事も一旦終わるはずでした。
ところがどっこい、そうは問屋が卸してくれませんでした。
KB4462933を再インストールしたところ、なんとジョイパッドを接続しっぱなしでも今度は正常に指定時間ピッタリに自動的にスリープに入るのです。
同様に再起動してみたり接続ポートを変えたりしてみても、時間経過で正常に自動的にスリープします。
電源設定もpowercfg.exeも再インストール前とアンインストール前の結果と比較してみましたが、やっぱり同一です。
しかし、KB4462933を初回インストールしたあとの再起動後から一切スリープしなくなったのは確かです。
なぜなら、私が不在時にこのWindowsUpdateによる更新が行われましたので、操作者がいない以上、正常ならば再起動してから一定時間経過後にイベントログにKernel-Powerのイベント42、「スリープの理由: System Idle」が記録されていなければなりませんが、その記録がないことからも明らかです。
スリープしているはずの時間帯だけでなく、翌日手動でスリープするまでにどっさりESENTイベントID916などのゴミログがイベントログに大量に、かつ間断なく記録されているのも傍証となります(まさかあのゴミログが役に立つとは!!)。
問題は、KB4462933そのものが原因ではないことです(後述しますがこの段階ではそう見えたものの、この結論は実は早すぎるようです)。
アンインストールして再インストールしたら事象が再現しないのですからそう言わざるを得ません。
(ここから上記の誤った結論に基づいた仮説が縷々続きますが、その後の新しい現象が確認されたことにより無駄な文章となっております。表題の趣旨としては合致しないため、本来は削除すべきですが、ｽｺﾞｲ恥ずかしいのでblogの趣旨としてどう恥ずかしいのかしっかり残すために文字を一回り小さくして残させていただきたいと思います。)
ただし、ここから先は事実ではなく仮説になってしまいますが、今回のケースではKB4462933を入れたことによってスリープをしなくなったものの、再インストールを行うことによって正常にスリープするようになったという現象自体を見ると、WindowsUpdateで品質更新プログラムを適用する際に実行されていると思しき何らかの作業スクリプトに不備があり、このケースと同様にスリープしなくなるという現象を惹起する可能性に思いを致さざるを得ません。
ということは、つまるところ、別の品質更新プログラムや機能更新プログラムでもその修正・追加内容に拘らず同様の事象を再現する可能性があるということになります。
というのは、一般的にはこういった更新適用スクリプトには固有の手続き以外の共通化できる手順というのがあって、そういった部分は毎回書き直したりせず、使いまわされることが多いからです。
その部分に、たとえば更新中は一時的に自動スリープを抑止するような手続きが含まれており、かつ何らかの条件で抑止を解除する手続きの中で一部正常に元に戻せなくなるケースが見逃されているのではないか、などの可能性が考えられます。
また、様々な環境用に一切合切まとめられてしまっている品質更新プログラムの中から、当環境に適したモジュールを抽出して適用する際、特定条件下ではスクリプト部分に問題があって、誤適用してしまう可能性も考えられます。
もしこの仮説が正しければ、の話ですが、もしも今回同様なケースに見舞われた方がおいででしたら、スリープしなくなってしまった直前に適用された品質更新プログラムや機能更新プログラムを再インストールしてみてはいかがでしょうか。
もしかしたら、今回のケースのようにあっさり直ってしまうかもしれません。
今回のケースでも「アア、マタカ」と面倒くさがってジョイパッドを抜去するだけの対策で済ませていたら、品質更新プログラムの再インストールで正常な挙動に直せることが分からずじまいでした。
仮説を唱えるなら実証して見せろ!とお叱りを受けそうです。
ごもっともです。
これは言い訳ですが、KB4462933のインストールとアンインストールと各段階でのデータどりを1ターンとすると、当環境では1ターン当たり2時間弱かかります。
しかも、一般的に機能更新プログラムなどがWindowsUpdateで適用される前の再起動は「前回の」WindowsUpdateでリブートがかかった後、何日～何十日も再起動されないままで適用されるという条件もあります(今回の事案では12日間再起動されていませんでした)。
私にはそれを検証するだけの時間的資源がありません。本当に申し訳ございません。
言い訳だけでなく、危うくKB4462933冤罪事件を免れましたので、恥の記録としてここに記録する次第です。
お読みいただきありがとうございました。
・・・とは終われませんでした。
問屋が卸してくれない状況で輪をかけてこれですから、言うなれば元売りも卸してくれないとでも言えばいいのでしょうか。
KB4462933を再インストールして正常にスリープをすることを確認したその当日の数時間後には、スリープしなくなる現象がまたもや再現したのです。
KB4462933を再インストールして正常にスリープができたことを何度も確認してから、そのままジョイパッドを接続したまま再起動もせず、数時間PCを使った後、所用で1時間ほど離席して帰ってくると、画面がまばゆく輝いていました。
イベントログも確認しましたが、離席した時刻以後は確かにスリープが記録されていません。
その間、繰り返しになりますが、検証のための最後のスリープを確認して復帰させた後は再起動などシステムに手を加えるようなことは何もしていません。
テキストエディタとﾌﾞﾗｳｻﾞを使っていただけです。
仕方がないのでもう一度ジョイパッドを抜去してスリープするか確かめたところ、抜いてあれば時間経過でスリープすることを確認しました。
もうなんだこれ？と途方に暮れつつ、ジョイパッドを接続したままにして、まだ用事が済んでいなかったため再度離席したのち所用を終えて帰ってくると、今度はスリープしているではありませんか。
うーん。魂消たなあ。
この現象はこれまでとはまた違った新現象です。
KB4462933のアンインストール前でのケースでは、ジョイパッドを接続しなおしてもシステムを再起動しても兎にも角にもジョイパッドが接続されている限りスリープに入らない状態は変わらなかったのですが、今回はKB4462933をアンインストールしなくともスリープに入ってしまったわけです。
当然、電源周りの設定とpowercfg.exeの出力も比較しましたが、これまた他と同様、まるで違いは認められません。
前回のアンインストール前の挙動とは明らかに異なります。
いったい何なんだろう。
帰ってきてまたまたパッドを挿抜したりなどのこれまでと同様のテストを行いましたが、正しくスリープに入ってしまいます。
こうなると、現時点では一度スリープから復帰して何時間も使ったあとはスリープに入らなくなったという事しか言えなくなりました。
一度はKB4462933は冤罪とみなしそうになりましたが、実はそうとは言い切れないのではないかという疑いが再浮上してしまいました。むしろ、このパッチが当たるまでは何の問題もなかったのですからますます疑惑が深まってしまいました。
(ひょっとして、その間にスリープ抑止リクエストが入った場合はどうなるかと思いついてしばらくwindows media playerでDISPLAYとDRIVERとPROCESSに抑止が入るようにして使った後、スリープに入るかどうか試してみましたが、正しくスリープに入りましたのでこれは関係ないようです。確かに再インストールしてから特別なスリープ抑止リクエストがかかるようなアプリを起動した覚えはないので、無意味なテストでした。)
とにかく私の先の仮説とやらは大仰に書きまくった割には大外れでとっても恥ずかしいので、このblogの趣旨にとてもふさわしいため、このままこの記事を公開させていただきます。
いやほんと、魂消たなあ。
新たな仮説を打ち立てないと検証方法も設計できないし、今のところお手上げです。
原因を特定することが果たしてできるのか先行きが大変不安な展開となっております。
申し訳ございません。
結論だけ言うと「KB4462933を再インストールしたら再現しなくなった」ように見せかけて「やっぱり再現した」ものの「再インストールしなくても再現しなくなった」です。
何が何だかさっぱりわかりません。
調査を進めてみると、もしかしてこの事象が発生するのはKB4462933に限らないかもしれない可能性が疑われました。
さらにその後、やっぱりKB4462933が原因だろうと考えざるを得ない事態が出来しました。
ちょっと複雑なので、順を追ってご説明いたします。
まず、以前にもありましたが、またもやUSBで接続されたジョイパッド(MS用語では"HID 準拠ゲーム コントローラー")が接続されていると、アイドル状態が続いて既定の時刻になってもスリープどころかブランクスクリーン(MS用語では"ディスプレイの電源を切る")にもならなくなりました。
あくまでもアイドル状態が指定時間続いた場合にスリープに入らないので手動でスリープを指示すれば正しくスリープに入ります。
ジョイパッドを抜去すると再度アイドル状態が続いた後に自動でスリープに入るようになります。
今回はKB4462933を適用した直後からこの事象が発生しました。
イベントログで確認しても、このKB4462933がインストールされてから丸一日後(たまたま長時間不在の中での更新でした)に気が付いて、試しに手動でスリープボタンを押下するまでスリープに入っていないことが記録されています。
家族に聞いても(常時私のPCを監視しているわけではないのでイベントログほど確実性はないものの)画面がつきっぱなしだったと言われましたので、スリープに入っていないことは確実です。
前回同じようなことを経験しているので、試しに接続されたままだったジョイパッドを抜去して待ってみると、正常に一定時間経過によって自動的にスリープしました。
試しに再起動してみても、ジョイパッドを接続しなおしたり接続ポートを変更してもこの状況は変わりませんでした。
一応、極めて黒に近い灰色に思われましたが、このまま犯人だと決めつけて間違っていたら間抜けなので、念のためにKB4462933をアンインストールして同様の試験したところ、自動的にスリープに入ることを確認しました。
さらに念のため、アンインストール前と設定が変わっていないかどうかの比較のため、以前のようにデバイスマネージャで電源設定を確認したりコントロールパネル->電源オプション->プラン設定の編集をチェックしましたが、両者の間で変更点は全くありませんでした。
powercfg.exe /requestsの結果も双方「なし。」の羅列で阻害要因なし。
powercfg.exe /energyの結果も双方阻害要因なし。
言い方を変えれば、powercfg.exe /requestsの結果および/energyの結果にKB4462933適用済の時とKB4462933未適用の時での差異が一切ありません(が挙動は異なる)という状況でした。
ここまでで犯人もわかったことだし、面倒ではあるけど対策はあるわけだからよしとして、暇なときにでも今度はもうちょっと原因を突っ込んで調べてみよう、ということでこの記事も一旦終わるはずでした。
ところがどっこい、そうは問屋が卸してくれませんでした。
KB4462933を再インストールしたところ、なんとジョイパッドを接続しっぱなしでも今度は正常に指定時間ピッタリに自動的にスリープに入るのです。
同様に再起動してみたり接続ポートを変えたりしてみても、時間経過で正常に自動的にスリープします。
電源設定もpowercfg.exeも再インストール前とアンインストール前の結果と比較してみましたが、やっぱり同一です。
しかし、KB4462933を初回インストールしたあとの再起動後から一切スリープしなくなったのは確かです。
なぜなら、私が不在時にこのWindowsUpdateによる更新が行われましたので、操作者がいない以上、正常ならば再起動してから一定時間経過後にイベントログにKernel-Powerのイベント42、「スリープの理由: System Idle」が記録されていなければなりませんが、その記録がないことからも明らかです。
スリープしているはずの時間帯だけでなく、翌日手動でスリープするまでにどっさりESENTイベントID916などのゴミログがイベントログに大量に、かつ間断なく記録されているのも傍証となります(まさかあのゴミログが役に立つとは!!)。
問題は、KB4462933そのものが原因ではないことです(後述しますがこの段階ではそう見えたものの、この結論は実は早すぎるようです)。
アンインストールして再インストールしたら事象が再現しないのですからそう言わざるを得ません。
(ここから上記の誤った結論に基づいた仮説が縷々続きますが、その後の新しい現象が確認されたことにより無駄な文章となっております。表題の趣旨としては合致しないため、本来は削除すべきですが、ｽｺﾞｲ恥ずかしいのでblogの趣旨としてどう恥ずかしいのかしっかり残すために文字を一回り小さくして残させていただきたいと思います。)
ただし、ここから先は事実ではなく仮説になってしまいますが、今回のケースではKB4462933を入れたことによってスリープをしなくなったものの、再インストールを行うことによって正常にスリープするようになったという現象自体を見ると、WindowsUpdateで品質更新プログラムを適用する際に実行されていると思しき何らかの作業スクリプトに不備があり、このケースと同様にスリープしなくなるという現象を惹起する可能性に思いを致さざるを得ません。
ということは、つまるところ、別の品質更新プログラムや機能更新プログラムでもその修正・追加内容に拘らず同様の事象を再現する可能性があるということになります。
というのは、一般的にはこういった更新適用スクリプトには固有の手続き以外の共通化できる手順というのがあって、そういった部分は毎回書き直したりせず、使いまわされることが多いからです。
その部分に、たとえば更新中は一時的に自動スリープを抑止するような手続きが含まれており、かつ何らかの条件で抑止を解除する手続きの中で一部正常に元に戻せなくなるケースが見逃されているのではないか、などの可能性が考えられます。
また、様々な環境用に一切合切まとめられてしまっている品質更新プログラムの中から、当環境に適したモジュールを抽出して適用する際、特定条件下ではスクリプト部分に問題があって、誤適用してしまう可能性も考えられます。
もしこの仮説が正しければ、の話ですが、もしも今回同様なケースに見舞われた方がおいででしたら、スリープしなくなってしまった直前に適用された品質更新プログラムや機能更新プログラムを再インストールしてみてはいかがでしょうか。
もしかしたら、今回のケースのようにあっさり直ってしまうかもしれません。
今回のケースでも「アア、マタカ」と面倒くさがってジョイパッドを抜去するだけの対策で済ませていたら、品質更新プログラムの再インストールで正常な挙動に直せることが分からずじまいでした。
仮説を唱えるなら実証して見せろ!とお叱りを受けそうです。
ごもっともです。
これは言い訳ですが、KB4462933のインストールとアンインストールと各段階でのデータどりを1ターンとすると、当環境では1ターン当たり2時間弱かかります。
しかも、一般的に機能更新プログラムなどがWindowsUpdateで適用される前の再起動は「前回の」WindowsUpdateでリブートがかかった後、何日～何十日も再起動されないままで適用されるという条件もあります(今回の事案では12日間再起動されていませんでした)。
私にはそれを検証するだけの時間的資源がありません。本当に申し訳ございません。
言い訳だけでなく、危うくKB4462933冤罪事件を免れましたので、恥の記録としてここに記録する次第です。
お読みいただきありがとうございました。
・・・とは終われませんでした。
問屋が卸してくれない状況で輪をかけてこれですから、言うなれば元売りも卸してくれないとでも言えばいいのでしょうか。
KB4462933を再インストールして正常にスリープをすることを確認したその当日の数時間後には、スリープしなくなる現象がまたもや再現したのです。
KB4462933を再インストールして正常にスリープができたことを何度も確認してから、そのままジョイパッドを接続したまま再起動もせず、数時間PCを使った後、所用で1時間ほど離席して帰ってくると、画面がまばゆく輝いていました。
イベントログも確認しましたが、離席した時刻以後は確かにスリープが記録されていません。
その間、繰り返しになりますが、検証のための最後のスリープを確認して復帰させた後は再起動などシステムに手を加えるようなことは何もしていません。
テキストエディタとﾌﾞﾗｳｻﾞを使っていただけです。
仕方がないのでもう一度ジョイパッドを抜去してスリープするか確かめたところ、抜いてあれば時間経過でスリープすることを確認しました。
もうなんだこれ？と途方に暮れつつ、ジョイパッドを接続したままにして、まだ用事が済んでいなかったため再度離席したのち所用を終えて帰ってくると、今度はスリープしているではありませんか。
うーん。魂消たなあ。
この現象はこれまでとはまた違った新現象です。
KB4462933のアンインストール前でのケースでは、ジョイパッドを接続しなおしてもシステムを再起動しても兎にも角にもジョイパッドが接続されている限りスリープに入らない状態は変わらなかったのですが、今回はKB4462933をアンインストールしなくともスリープに入ってしまったわけです。
当然、電源周りの設定とpowercfg.exeの出力も比較しましたが、これまた他と同様、まるで違いは認められません。
前回のアンインストール前の挙動とは明らかに異なります。
いったい何なんだろう。
帰ってきてまたまたパッドを挿抜したりなどのこれまでと同様のテストを行いましたが、正しくスリープに入ってしまいます。
こうなると、現時点では一度スリープから復帰して何時間も使ったあとはスリープに入らなくなったという事しか言えなくなりました。
一度はKB4462933は冤罪とみなしそうになりましたが、実はそうとは言い切れないのではないかという疑いが再浮上してしまいました。むしろ、このパッチが当たるまでは何の問題もなかったのですからますます疑惑が深まってしまいました。
(ひょっとして、その間にスリープ抑止リクエストが入った場合はどうなるかと思いついてしばらくwindows media playerでDISPLAYとDRIVERとPROCESSに抑止が入るようにして使った後、スリープに入るかどうか試してみましたが、正しくスリープに入りましたのでこれは関係ないようです。確かに再インストールしてから特別なスリープ抑止リクエストがかかるようなアプリを起動した覚えはないので、無意味なテストでした。)
とにかく私の先の仮説とやらは大仰に書きまくった割には大外れでとっても恥ずかしいので、このblogの趣旨にとてもふさわしいため、このままこの記事を公開させていただきます。
いやほんと、魂消たなあ。
新たな仮説を打ち立てないと検証方法も設計できないし、今のところお手上げです。
原因を特定することが果たしてできるのか先行きが大変不安な展開となっております。
申し訳ございません。
2018年10月27日土曜日
Android用のブラウザで暗い背景色で長文が読みたい
当blogは副題をネットウラシマと申しまして、浦島太郎感漂う「こんなことも知らんのか」と言われるようなﾊｽﾞｶｼｲ話題を記録するblogです。
そこで、今回のお題は「Android版のブラウザでの長文読書は背景が真っ白で目につらい。」です。
対策は「背景を黒く(暗く)すればいい。」
当たり前すぎます。
が、今時のメジャーﾌﾞﾗｳｻﾞはこれがまったくできない、またはプラグインが必要とされることに衝撃を感じたので記録する次第です。
結論から先に書きますと、(Chrome以外でメジャーと言えるブラウザの存在があるとして)メジャーどころではAndroid版Firefox+アドオンでのみ実現可能でした。
Firefoxで背景色を暗くするアドオンは複数あるのですが、その中ではDark Readerが個人的には最も出来が良いと感じ、採用しました。PC版ChromeおよびSafari用にも同一アドオンがあります。
他はあまり良い評価点を与えられなかったので名を挙げませんが、速度に難あり(白いままの画面が割と長い間、といっても数秒、表示されてしまう)、色に難あり(反転しなくていい文字色や画像も単純にinverseされたり特定の文字色以外は全部白になったり等)、文字数が多くなると急に無反応、スクロールするとスクロールされた領域が白いまま、など、数は多かれど実質的にはとても使えなかったり、ｻﾞﾝﾈﾝ感が高いものが多かった中、比較的動作が良好だったのが採用の理由です。
加えて、Android版Firefoxのプライベートタブでは、画面上部のタブ名表示部もアドレスバー表示部も暗色表示になるため、その部分を暗色表示にするためだけのアドオンを探さなくても気になりません。
この部分は「設定」->「一般」->「全画面表示でブラウジングする」オプションスイッチを有効にしたうえで、なおかつ、画面を上にある程度スクロールさせないと引っ込まないという大変鬱陶しい仕様ですので、最初からその部分が暗いプライベートタブで読むと手っ取り早いと思います。
実際にやってみた範囲内では以上です。
以下、なんでAndroid用のブラウザの画面を暗くしたいのかを含めた前置きと、なぜ結論で述べた以外のブラウザで実現できないか、などを書き連ねた戯言です。
子供のころから寝る前に本を読まないと寝付けない習慣がついてしまっていて、枕もとの照明で読んでいました。
ところが、スマートフォンが普及して高解像度で文字も美しく表示され、さらに一画面内の文字数も文庫本1ページ程度は軽く表示できてしまうに及び、枕もとに本を積んでおく必要もなくなり、照明をつけなくとも読めるし本より軽いのですぐにスマートフォン、その後はタブレットを用いるようになりました。
読書に用いるアプリ、例えばKindle、自炊jpeg化した小説などではPerfect Viewerなど当然のように白黒反転機能がついています。
Android4.2だか4.3まで標準搭載されていた「(アプリ名としての)ﾌﾞﾗｳｻﾞ」(ややこしいので以後旧標準ﾌﾞﾗｳｻﾞと表記します)にも、実は画面の反転表示機能があります。
尤もﾌﾞﾗｳｻﾞを使って本(長文)を読むことはなかったので、主に白黒反転機能があるアプリだけでこれまで読んできました。
ところが最近、中国古典に再度嵌りそうになっています。
Web上に面白い文献がたくさんあり、すぐに原文を参照出来たり、意味が分からない言葉の解説をすぐに調べることができ、これは寝る前にちょっとづつ読むのにいいな、画面が大きくて複雑な漢字でも明瞭に表示できるタブレットで読みたいなと思いました。
が、現在の主流ﾌﾞﾗｳｻﾞの背景色は白い。とても白い。
暗い中で真っ白な画面を見た瞬間、虹彩を絞って瞳孔を狭める筋肉に痛みが生じるくらい急激な動きを生じる程度に極めて白く、そして眩しいのです。
とてもではありませんが「読む」なんてできません。せいぜい「見る」程度でもすぐにギブアップです。
普段PCで使うモニタよりも段違いに近くで光る白い板を、暗い中で見つめることになるのですから当然といえば当然です。
旧標準ﾌﾞﾗｳｻﾞを搭載するスマホも手元にあるにはあるのですが、XperiaAなので画面が小さいためタブレットで読みたいということで、調べてみました。
さて、ようやく本題です。
まず普段だったら大本命のAndroid版Chrome。
PC版と違い、アドオンも入れられません。だからカスタマイズもできません。
このケースでは絶望です。
旧標準ﾌﾞﾗｳｻﾞもGoogle製にも拘らず、Chromeには旧標準ﾌﾞﾗｳｻﾞのような反転機能が搭載されていないどころか、アドレスバーも何もかも真っ白です。
但し、何の解決にもなりませんが念のために申し添えますと、シークレットタブの場合はアドレスバー表示部だけ暗灰色になりますが表示中のコンテンツの背景色には何の影響も与えません。そりゃそうです。
Android版Chromeを含めて、どうしてもﾌﾞﾗｳｻﾞ自身で表示中のコンテンツの背景色を暗くすることができないとすれば、OSの機能を使って色反転する手があるだろう、と思われるかもしれません。確かAndroid5だか6だかで搭載された機能です。
しかし、当然ながら略図や地図、石碑や鼎などの写真などの画像も反転してしまいます。さらに当然ながらﾌﾞﾗｳｻﾞ以外も反転します。
画面上部の通知領域と下部のナビゲーションバー(戻ったりするボタンがあるバー)も当然ながら色反転されてしまいます。
通常この両者の背景は黒なので、反転すると白くなります。一部だけ輝いていて眩しい上に余計目障りになってしまいます。
じゃあ両者を白くする/できるホームアプリを入れれば解決でしょ、と言われそうですが、そこまでするのは余程そのﾌﾞﾗｳｻﾞに対する忠誠心が高い人に許される特権でしょう。
そこまでして使うほど愛するﾌﾞﾗｳｻﾞなら別ですが、そもそも、単純に不便ですよね。
従って、あくまでもブラウザ内だけで表示コンテンツの背景色およびガワ(アドレスバー等)を暗色で表示できるﾌﾞﾗｳｻﾞを探しました。
以下、それを踏まえて縷々続きます。
お次はAndroid版Edge。インストールしたことがないしWindows10版でも自作javascriptを使った当blog用コンテンツの動作確認のためだけにあるストレージの肥やし感満載のMS期待の星です。
Chrome以外のﾌﾞﾗｳｻﾞが出てくること自体は大歓迎ですので、試しにインストールしてみましたところ、これも真っ白。背景色を暗色にするオプションも見当たらず、アドオンも利用不可。
PC版ではいつかIEのシェアを抜く日が来ることをお祈りいたしつつ結局アンインストール。
今度はAndroid版Opera。わかりやすいところに「ナイトモード」という切り替えスイッチがあるので一瞬「おおおっ」と一気に胸が高鳴りますが、実はガワが暗色に変わるだけでメインのコンテンツには適用外です。
他ﾌﾞﾗｳｻﾞでもシークレットだかプライベートだかのモードで開けば大抵そのあたりは暗色ですのであんまり魅力がありません。
ていうか最近ナイトモードとか流行ですねぇ。
平たく言っちゃえば、単純にブルーライト商法ってやつですかねぇ。
でしょうねぇ(自己納得)。
そしてなによりAndroid版Operaも背景色を暗色にするオプションが見当たらず、アドオン適用不可能のためカスタマイズ不可。
個人的にはPC版Opera12までは相当お世話になっていたため、過去一瞬だけAndroid版Operaを使ったことがあるのですが、その際は様々なサイトがまともに表示されずにレイアウトが盛大に崩れていたので即アンインストールした覚えがあります。
今回も、要件に合致しないためまたもお払い箱にせざるを得ませんでした。
今度はAndroid版Firefoxです。先の結論で申しました通り、Firefoxにアドオンを適用出来たおかげで要件を達成することが出来ました。
完全に個人の環境のせいだと思うのですが、本当はこれは避けたかった。
利用したいタブレットがMediaPad T2 Proで、この端末でFirefoxを使うと、Firefoxの初回のページ読み込みが何かのタイムアウト待ちに引っかかっているらしく、自宅サーバのホームページだろうがgoogleの検索ページだろうが、ともかくなんでもかんでも初回表示に必ず数十秒かかるためです。
同じAndroid版Firefoxでも他のスマートフォンでは全くそんな現象は起きませんし、当然他のﾌﾞﾗｳｻﾞでは一切そういったことは起きないのですが、起動後一度でも読み込みを完了しさえすれば速度的には問題なくなりますし、ページのレイアウト崩れもあまりないというメリットもありますので、Windows版とLinux版ではお世話になっていることもありますし、これからAndroidでもお世話になることにいたしました。
他にもAndroid版ﾌﾞﾗｳｻﾞはあまたありますし、中には反転機能を最初から備えたﾌﾞﾗｳｻﾞもあるのかもしれませんが、とりあえずはこれで運用してみたいと思います。
それにしても、PC上では背景色が黒くないと嫌なのはテキストエディタとvt100エミュレータくらいで、これはMS-DOSのころのアプリは背景色が真っ黒なのが一般的だったなど慣習的なもので、眩しさとかは全く関係がありません。現に、個人で気軽に使えるマルチウィンドウｼｽﾃﾑが普及した後で使い始めたIDE(VisualC++とか)やらExcel,Word等の背景が真っ白でも全然違和感を感じません。当blogの背景色も真っ白ケッケです。
部屋が暗い中でPCを使うなんてこともありませんので、背景色を暗くしたいということを切実な要望として感じるのはスマートフォンやタブレットならではといえるのかなあ、と勝手に思う次第です。
以上、恥の記録と長大な駄文でした。
お読みいただき、誠にありがとうございました。
そこで、今回のお題は「Android版のブラウザでの長文読書は背景が真っ白で目につらい。」です。
対策は「背景を黒く(暗く)すればいい。」
当たり前すぎます。
が、今時のメジャーﾌﾞﾗｳｻﾞはこれがまったくできない、またはプラグインが必要とされることに衝撃を感じたので記録する次第です。
結論から先に書きますと、(Chrome以外でメジャーと言えるブラウザの存在があるとして)メジャーどころではAndroid版Firefox+アドオンでのみ実現可能でした。
Firefoxで背景色を暗くするアドオンは複数あるのですが、その中ではDark Readerが個人的には最も出来が良いと感じ、採用しました。PC版ChromeおよびSafari用にも同一アドオンがあります。
他はあまり良い評価点を与えられなかったので名を挙げませんが、速度に難あり(白いままの画面が割と長い間、といっても数秒、表示されてしまう)、色に難あり(反転しなくていい文字色や画像も単純にinverseされたり特定の文字色以外は全部白になったり等)、文字数が多くなると急に無反応、スクロールするとスクロールされた領域が白いまま、など、数は多かれど実質的にはとても使えなかったり、ｻﾞﾝﾈﾝ感が高いものが多かった中、比較的動作が良好だったのが採用の理由です。
加えて、Android版Firefoxのプライベートタブでは、画面上部のタブ名表示部もアドレスバー表示部も暗色表示になるため、その部分を暗色表示にするためだけのアドオンを探さなくても気になりません。
この部分は「設定」->「一般」->「全画面表示でブラウジングする」オプションスイッチを有効にしたうえで、なおかつ、画面を上にある程度スクロールさせないと引っ込まないという大変鬱陶しい仕様ですので、最初からその部分が暗いプライベートタブで読むと手っ取り早いと思います。
実際にやってみた範囲内では以上です。
以下、なんでAndroid用のブラウザの画面を暗くしたいのかを含めた前置きと、なぜ結論で述べた以外のブラウザで実現できないか、などを書き連ねた戯言です。
子供のころから寝る前に本を読まないと寝付けない習慣がついてしまっていて、枕もとの照明で読んでいました。
ところが、スマートフォンが普及して高解像度で文字も美しく表示され、さらに一画面内の文字数も文庫本1ページ程度は軽く表示できてしまうに及び、枕もとに本を積んでおく必要もなくなり、照明をつけなくとも読めるし本より軽いのですぐにスマートフォン、その後はタブレットを用いるようになりました。
読書に用いるアプリ、例えばKindle、自炊jpeg化した小説などではPerfect Viewerなど当然のように白黒反転機能がついています。
Android4.2だか4.3まで標準搭載されていた「(アプリ名としての)ﾌﾞﾗｳｻﾞ」(ややこしいので以後旧標準ﾌﾞﾗｳｻﾞと表記します)にも、実は画面の反転表示機能があります。
尤もﾌﾞﾗｳｻﾞを使って本(長文)を読むことはなかったので、主に白黒反転機能があるアプリだけでこれまで読んできました。
ところが最近、中国古典に再度嵌りそうになっています。
Web上に面白い文献がたくさんあり、すぐに原文を参照出来たり、意味が分からない言葉の解説をすぐに調べることができ、これは寝る前にちょっとづつ読むのにいいな、画面が大きくて複雑な漢字でも明瞭に表示できるタブレットで読みたいなと思いました。
が、現在の主流ﾌﾞﾗｳｻﾞの背景色は白い。とても白い。
暗い中で真っ白な画面を見た瞬間、虹彩を絞って瞳孔を狭める筋肉に痛みが生じるくらい急激な動きを生じる程度に極めて白く、そして眩しいのです。
とてもではありませんが「読む」なんてできません。せいぜい「見る」程度でもすぐにギブアップです。
普段PCで使うモニタよりも段違いに近くで光る白い板を、暗い中で見つめることになるのですから当然といえば当然です。
旧標準ﾌﾞﾗｳｻﾞを搭載するスマホも手元にあるにはあるのですが、XperiaAなので画面が小さいためタブレットで読みたいということで、調べてみました。
さて、ようやく本題です。
まず普段だったら大本命のAndroid版Chrome。
PC版と違い、アドオンも入れられません。だからカスタマイズもできません。
このケースでは絶望です。
旧標準ﾌﾞﾗｳｻﾞもGoogle製にも拘らず、Chromeには旧標準ﾌﾞﾗｳｻﾞのような反転機能が搭載されていないどころか、アドレスバーも何もかも真っ白です。
但し、何の解決にもなりませんが念のために申し添えますと、シークレットタブの場合はアドレスバー表示部だけ暗灰色になりますが表示中のコンテンツの背景色には何の影響も与えません。そりゃそうです。
Android版Chromeを含めて、どうしてもﾌﾞﾗｳｻﾞ自身で表示中のコンテンツの背景色を暗くすることができないとすれば、OSの機能を使って色反転する手があるだろう、と思われるかもしれません。確かAndroid5だか6だかで搭載された機能です。
しかし、当然ながら略図や地図、石碑や鼎などの写真などの画像も反転してしまいます。さらに当然ながらﾌﾞﾗｳｻﾞ以外も反転します。
画面上部の通知領域と下部のナビゲーションバー(戻ったりするボタンがあるバー)も当然ながら色反転されてしまいます。
通常この両者の背景は黒なので、反転すると白くなります。一部だけ輝いていて眩しい上に余計目障りになってしまいます。
じゃあ両者を白くする/できるホームアプリを入れれば解決でしょ、と言われそうですが、そこまでするのは余程そのﾌﾞﾗｳｻﾞに対する忠誠心が高い人に許される特権でしょう。
そこまでして使うほど愛するﾌﾞﾗｳｻﾞなら別ですが、そもそも、単純に不便ですよね。
従って、あくまでもブラウザ内だけで表示コンテンツの背景色およびガワ(アドレスバー等)を暗色で表示できるﾌﾞﾗｳｻﾞを探しました。
以下、それを踏まえて縷々続きます。
お次はAndroid版Edge。インストールしたことがないしWindows10版でも自作javascriptを使った当blog用コンテンツの動作確認のためだけにあるストレージの肥やし感満載のMS期待の星です。
Chrome以外のﾌﾞﾗｳｻﾞが出てくること自体は大歓迎ですので、試しにインストールしてみましたところ、これも真っ白。背景色を暗色にするオプションも見当たらず、アドオンも利用不可。
PC版ではいつかIEのシェアを抜く日が来ることをお祈りいたしつつ結局アンインストール。
今度はAndroid版Opera。わかりやすいところに「ナイトモード」という切り替えスイッチがあるので一瞬「おおおっ」と一気に胸が高鳴りますが、実はガワが暗色に変わるだけでメインのコンテンツには適用外です。
他ﾌﾞﾗｳｻﾞでもシークレットだかプライベートだかのモードで開けば大抵そのあたりは暗色ですのであんまり魅力がありません。
ていうか最近ナイトモードとか流行ですねぇ。
平たく言っちゃえば、単純にブルーライト商法ってやつですかねぇ。
でしょうねぇ(自己納得)。
そしてなによりAndroid版Operaも背景色を暗色にするオプションが見当たらず、アドオン適用不可能のためカスタマイズ不可。
個人的にはPC版Opera12までは相当お世話になっていたため、過去一瞬だけAndroid版Operaを使ったことがあるのですが、その際は様々なサイトがまともに表示されずにレイアウトが盛大に崩れていたので即アンインストールした覚えがあります。
今回も、要件に合致しないためまたもお払い箱にせざるを得ませんでした。
今度はAndroid版Firefoxです。先の結論で申しました通り、Firefoxにアドオンを適用出来たおかげで要件を達成することが出来ました。
完全に個人の環境のせいだと思うのですが、本当はこれは避けたかった。
利用したいタブレットがMediaPad T2 Proで、この端末でFirefoxを使うと、Firefoxの初回のページ読み込みが何かのタイムアウト待ちに引っかかっているらしく、自宅サーバのホームページだろうがgoogleの検索ページだろうが、ともかくなんでもかんでも初回表示に必ず数十秒かかるためです。
同じAndroid版Firefoxでも他のスマートフォンでは全くそんな現象は起きませんし、当然他のﾌﾞﾗｳｻﾞでは一切そういったことは起きないのですが、起動後一度でも読み込みを完了しさえすれば速度的には問題なくなりますし、ページのレイアウト崩れもあまりないというメリットもありますので、Windows版とLinux版ではお世話になっていることもありますし、これからAndroidでもお世話になることにいたしました。
他にもAndroid版ﾌﾞﾗｳｻﾞはあまたありますし、中には反転機能を最初から備えたﾌﾞﾗｳｻﾞもあるのかもしれませんが、とりあえずはこれで運用してみたいと思います。
それにしても、PC上では背景色が黒くないと嫌なのはテキストエディタとvt100エミュレータくらいで、これはMS-DOSのころのアプリは背景色が真っ黒なのが一般的だったなど慣習的なもので、眩しさとかは全く関係がありません。現に、個人で気軽に使えるマルチウィンドウｼｽﾃﾑが普及した後で使い始めたIDE(VisualC++とか)やらExcel,Word等の背景が真っ白でも全然違和感を感じません。当blogの背景色も真っ白ケッケです。
部屋が暗い中でPCを使うなんてこともありませんので、背景色を暗くしたいということを切実な要望として感じるのはスマートフォンやタブレットならではといえるのかなあ、と勝手に思う次第です。
以上、恥の記録と長大な駄文でした。
お読みいただき、誠にありがとうございました。
2018年10月26日金曜日
Firefox 63.0 でサイドバーのブックマークと履歴の行間を狭くする方法
面倒なので数日ほっぽいといた更新をようやく受け入れたところ、Firefox 63になりました。
更新したら、サイドバーの行間がドーンと間延びするようにされてしまいました。
まあ、正直現状におけるPC版のFirefoxの存在意義はChrome一強の片隅でひっそりと佇んでくれていることにあると思っていますので、余計な愚痴は差し控えたいと思います。
さて、それにしてもやっぱり間延びしすぎて見づらいので、Firefox63でサイドバーの行間を狭める別の方法を考えます。
とりあえず、以下の方法でどうでしょう。
なお、以下の方法で使用している-moz-tree-ﾎﾆｬﾗﾗはFirefox64からWebコンテンツから使えなくなるそーでーす。どどーん。
しかし、Webコンテンツから、っていう文言が私にはよくわかりません。単にアドオンや表示したページからjavascriptなどで操作ができなるという意味なのか、XULそのものの廃止に向けた準備作業なのか、ﾌﾞﾗｳｻﾞマニアでもなんでもないのでさっぱりです。
ま、ついでなんで試してみました。
今回ご紹介するuserChrome.cssに記述する手法の場合は、手元の開発用Windows10でbeta版のFirefox64.0b3で試してみましたところ、問題なく行間が狭まりました。
ついでにNightly版のFirefox65.0a1(2018-10-25)でも問題なく行間が狭まりました。
Nightly版はbetaですらないのでまだ何とも言えませんが、beta版のFirefox64.0b3の場合はリリースが2018/12/11に迫っており、その後は来年までクリスマス休暇ですので多分このままではないかと思います。
尤も、顔を真っ赤にしてこれから大修正を加える可能性もありますので単に利用させていただいているだけの私には何とも言えません。
Firefox62までは上記の設定だと狭すぎると思います。Firefox62までの調整方法は以前の記事のコメント欄でご紹介しましたが、改めて文末にご参考としてご紹介いたします。
やけにJavascriptで動的に生成した画面の動きが他ﾌﾞﾗｳｻﾞに比べて甘いとか、いまだにonclickとondblclickを同時にきちんと発火させられない(EdgeやChromeではとっくに実装済)とか基本的な機能はほっぽっとくくせに、こんなことに血道をあげて変更を加えてくる人的リソース配分の余裕っぷりがうらやましいですね。あ、愚痴かなこれ・・・
がんばれFirefox,シェアがどんどん下がっていても、目指す方向性がさっぱり周りからは見えなくても。
ご参考: Firefox62までのサイドバーの行間を狭める定義。
なお、広くする分にはこの方法で広げられます。
上記手順のうちコピー内容を以下の３行に変更してください。
treechildren.sidebar-placesTreechildren::-moz-tree-row{
height:1px !important;
}
以上です。
更新したら、サイドバーの行間がドーンと間延びするようにされてしまいました。
まあ、正直現状におけるPC版のFirefoxの存在意義はChrome一強の片隅でひっそりと佇んでくれていることにあると思っていますので、余計な愚痴は差し控えたいと思います。
さて、それにしてもやっぱり間延びしすぎて見づらいので、Firefox63でサイドバーの行間を狭める別の方法を考えます。
とりあえず、以下の方法でどうでしょう。
なお、以下の方法で使用している-moz-tree-ﾎﾆｬﾗﾗはFirefox64からWebコンテンツから使えなくなるそーでーす。どどーん。
しかし、Webコンテンツから、っていう文言が私にはよくわかりません。単にアドオンや表示したページからjavascriptなどで操作ができなるという意味なのか、XULそのものの廃止に向けた準備作業なのか、ﾌﾞﾗｳｻﾞマニアでもなんでもないのでさっぱりです。
ま、ついでなんで試してみました。
今回ご紹介するuserChrome.cssに記述する手法の場合は、手元の開発用Windows10でbeta版のFirefox64.0b3で試してみましたところ、問題なく行間が狭まりました。
ついでにNightly版のFirefox65.0a1(2018-10-25)でも問題なく行間が狭まりました。
Nightly版はbetaですらないのでまだ何とも言えませんが、beta版のFirefox64.0b3の場合はリリースが2018/12/11に迫っており、その後は来年までクリスマス休暇ですので多分このままではないかと思います。
尤も、顔を真っ赤にしてこれから大修正を加える可能性もありますので単に利用させていただいているだけの私には何とも言えません。
- メニューの「ﾍﾙﾌﾟ」から「トラブルシューティング情報...」を開く。
- 「アプリケーション基本情報 」テーブル内の「プロファイルフォルダー」行の「フォルダーを開く」ボタンを押下する。
- 「chrome」という名称のフォルダがなければ手動で作成し、chromeフォルダーを開く。
- 「userChrome.css」というファイルがなければ、chromeフォルダー内に手動で作成し、メモ帳で開く。
なお、拡張子を表示しない設定になってたりしてuserChrome.css.txtなんてﾌｧｲﾙを作ってしまうお茶目を演じてもいいですが意図する結果は得られません。
また、メモ帳以外で開くアプリケーションを決定する際になんでメモ帳を指定しているのかわかんないからWordでいいやとか面白いことをなさっても意図する結果は得られませんのでご注意ください。 - 以下の呪文をコピーしてメモ帳にペーストして保存する。
1234567891011121314151617@namespaceurl("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");#bookmarksPanel, #history-panel {font-size:9pt!important;font-family:"Meiryo UI"!important;}treechildren.sidebar-placesTreechildren::-moz-tree-row{margin-top:-3px!important;margin-bottom:-4px!important;}treechildren.sidebar-placesTreechildren::-moz-tree-row(hover){margin-top:0px!important;margin-bottom:0px!important;}treechildren.sidebar-placesTreechildren::-moz-tree-row(selected){margin-top:0px!important;margin-bottom:0px!important;} - Firefox63を再起動する。
Firefox62までは上記の設定だと狭すぎると思います。Firefox62までの調整方法は以前の記事のコメント欄でご紹介しましたが、改めて文末にご参考としてご紹介いたします。
やけにJavascriptで動的に生成した画面の動きが他ﾌﾞﾗｳｻﾞに比べて甘いとか、いまだにonclickとondblclickを同時にきちんと発火させられない(EdgeやChromeではとっくに実装済)とか基本的な機能はほっぽっとくくせに、こんなことに血道をあげて変更を加えてくる人的リソース配分の余裕っぷりがうらやましいですね。あ、愚痴かなこれ・・・
がんばれFirefox,シェアがどんどん下がっていても、目指す方向性がさっぱり周りからは見えなくても。
ご参考: Firefox62までのサイドバーの行間を狭める定義。
なお、広くする分にはこの方法で広げられます。
上記手順のうちコピー内容を以下の３行に変更してください。
treechildren.sidebar-placesTreechildren::-moz-tree-row{
height:1px !important;
}
以上です。
2018年9月14日金曜日
Fallout® Shelter dwellers viewer
Fallout® shelter dwellers viewer
A script to create a detailed dwellers list from saved data.How to use
Drop save data here
ここにセーブデータをドロップ
or
Fallout® Shelter © 2015-2017 Bethesda Softworks LLC, a ZeniMax Media company. Bethesda, Bethesda Softworks, Bethesda Game Studios, ZeniMax, and related logos are registered trademarks or trademarks of ZeniMax Media Inc. in the U.S. and/or other countries. Fallout, Fallout Shelter and related logos are trademarks or registered trademarks of Bethesda Softworks LLC in the U.S. and/or other countries. All Rights Reserved.
jQuery v2.1.4 | © 2005, 2015 jQuery Foundation, Inc. | jquery.org/license
json2.js http://www.JSON.org/
DeEn.js © 2017 rakion99 https://rakion99.github.io/shelter-editor/
TableSorter (FORK) v2.31.0 © 2007 Christian Bach, fork maintained by Rob Garrison http://tablesorter.com
jQuery v2.1.4 | © 2005, 2015 jQuery Foundation, Inc. | jquery.org/license
json2.js http://www.JSON.org/
DeEn.js © 2017 rakion99 https://rakion99.github.io/shelter-editor/
TableSorter (FORK) v2.31.0 © 2007 Christian Bach, fork maintained by Rob Garrison http://tablesorter.com
How to use
-
このページの趣旨
Fallout® Shelterの住民(dwellers)のhealthの一覧が欲しかっただけなのに、 気づいたら変なものができてしまったのでここに置いときます。
住民のデータを表形式で表示したり、Vaultの部屋のレイアウトと各部屋への住民の配置状況や、実行中のExploreやQuestの状態を参照したり、訓練中の住民の概算終了予測時間を表示したり、CSVやTSVで保存するなどができます。
表の表示項目はチェックボックスで取捨選択できます。
-
セーブデータの場所
Lancher版:"Documents\My Games\Fallout Shelter"
Steam版:"%APPDATA%\..\Local\FalloutShelter"
Windowsストア版:https://bethesda.net/community/topic/25405/transfer-vault-from-desktop-version-to-play-anywhereを参照の事
Android版:"storage/sdcard/Android/data/com.bethsoft.falloutshelter/files"
上記のフォルダの中にあるVault1.sav等の拡張子が.sav(または.sav.bkp)のファイルがセーブデータです。 -
HTML5が正しく動作して、かつjavascriptが有効になっているブラウザでご利用ください。
表の作成はサーバ等への通信は行いません。すべて表示中のﾌﾞﾗｳｻﾞ内部で完結しています。
言い方を変えると、セーブデータはどこにも送信されません。
従って、表の作成時間はあなたがご利用になっているﾌﾞﾗｳｻﾞ及び計算機の処理能力次第です。 - セーブデータを受付領域にドロップするか、またはファイル選択ボタンでセーブデータを選択します。
-
住人の属性が表形式で表示されます。
表はカラム名をクリックすることで昇順/降順の切り替えができます。
行をクリックすると、表の下部にクリックした住民の詳細情報が表示されます。 -
住民データをCSV、TSV形式で保存できます。
表計算ソフトやDBへのインポート時にご利用ください。
さらには、世の中にはtsvやcsvに直接sqlを発行できるという超優れモノがございます。
そういうものを使えば、たとえば:-
住民のうち少ない苗字順で並べるSQL文:
SELECT lastName, COUNT(*) AS cnt FROM dwellers.tsv GROUP BY lastName ORDER BY cnt; -
同じ苗字が３人以下の女性住民を並べるSQL文:
SELECT lastName, COUNT(*) AS CNT FROM dwellers.tsv GROUP BY lastName HAVING (COUNT(lastname) <= 3) and gender=1 ORDER BY CNT; -
S.P.E.C.I.A.Lの合計値が高い順に住民の名前と性別を並べるSQL文:
SELECT `stats.stats[1].value` + `stats.stats[2].value` + `stats.stats[3].value` + `stats.stats[4].value` + `stats.stats[5].value` + `stats.stats[6].value` + `stats.stats[7].value` AS SPECIAL, name, LastName, (CASE WHEN gender=1 THEN "Female" ELSE "Male" END) FROM dwellers.tsv ORDER BY SPECIAL DESC; -
現レベルにおけるEndurance17でレベルアップしてきた場合の理想max healthに対する現状比を列挙するSQL文:
SELECT `experience.currentLevel` ,`health.maxHealth`,`stats.stats[1].value` + `stats.stats[2].value` + `stats.stats[3].value` + `stats.stats[4].value` + `stats.stats[5].value` + `stats.stats[6].value` + `stats.stats[7].value` AS SPECIAL, name,lastName, (`health.maxHealth`/(11.0*(`experience.currentLevel`-1.0)+105)*100)||"%" AS HPperLvl FROM dwellers.tsv ORDER BY HPperLvl,`experience.currentLevel` DESC, SPECIAL;
繁殖や追放のお供にどうぞ。 -
住民のうち少ない苗字順で並べるSQL文:
-
ﾃﾞﾌｫﾙﾄだと表示カラム数が多すぎてよくわからないと思います。
Show column selectorチェックボックスをチェックすると、表示するカラムを取捨選択する画面が開きますので、表示したいカラムを選択してください。チェックボックスにチェックがついているカラムが表に反映されるカラムです。
なお、CSVやTSVとして保存する項目へはチェック状態は適用されません。
Terms of use
- このスクリプトの実行にはjavascriptの実行、およびHTML5を表示できる環境が必要です。
- このスクリプトはあるがままで提供されます。
- このスクリプトを使用したことによる一切の損害等には関知しません。
-
カラム名の和訳を改善・追加するつもりはありません。
-
このスクリプトの修正や改造等の要望には一切応じません。
バグがあっても直しません。
訓練完了時間がセーブ時間より長時間の場合、実際より長めに計算されます。 - 私個人が使うブラウザでしかテストしていません。
- 万が一この程度のスクリプトに要望や不満を覚えるほどゲームに入れ込んでいるなら、GPLv3のライセンス下で自由にこのスクリプトを改変することができます。
(c)2018 ayumi ttgcameback.blogspot.com
登録:
投稿 (Atom)