虚構人形廃棄場

ここ2年ほどの経験で中国語圏の人の英語は大体聞き取れるようになりました。theの発音が[la]に聞こえたり、母音が全体的に「う」に寄っていたり。前者は稀かもしれませんが、後者のような母音の傾向は恐らく各言語(または地域)ごとに特徴があるだろうと想像しています。

そんなところで本日、インド人の英語に立ち会わされました。会議システム越しで音が悪いとはいえ...半分も聞き取れない...。まだまだ道は長いようです。

立て続けにWindows 10ネタですが、妻のVAIO J (VPCJ127FJ)をアップデートする目処が立ちました。当初、例の「強制」アップデートで輝度調整ができないことが判明し、Win7に戻して下調べをしていたのです。

結論としては(ディスプレイドライバ適用後に)レジストリを一箇所変更すれば大丈夫でした。ネタ元はここです。Windows 8.1でも効果を確認しています。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000]

"FeatureTestControl"=dword:0000fb20

この値はWin7の頃からIntel配布のドライバでは0f800hになっていまして、Win8以降Windows Updateでダウンロードされるものもそうなっています。これがWin7のVAIO向けは0faf2hでした。何やら機能の設定をするようです。

しかし、Win8以降のドライバは0faf2hではダメで、上記掲示板にあった0fb20hで動作となりました。試行錯誤されたのでしょうか、貴重な情報です。同様に他の無印Intel HD Graphics搭載PCでもこの値を変更することで、輝度のトラブルが解決できるかもしれません。

なお、クリーンインストールでの輝度調整は、以下のものを入れれば動作するようです。リカバリメディアにmod2wimを使うなり、どこかから入手するなりしてください。

Sony Shared Library

VAIO Event Service

VAIO Control Center

Sony Firmware Extension Parser (必要ないかも)

Windows Update後の例の「Windowsを構成するための準備中」「コンピューターの電源を切らないでください」がいつまでも終わらない...。

義父からは電話で聞いただけだったので確信が持てませんでしたが、昨日実家に行ったら父サブPCがその状態になっていまして、強制終了して更新履歴を見たら「for Windows 10」の文字があり、ようやく把握しました。

恐らくWindows 10にする前にWindows Updateもしており、回線が細いので異様に時間がかかっていたと思われます。

そんな時間のかかることを普段のWindows Update画面ですべきではありません。Service Packのように長時間かかる旨と、それから手動での更新時のように進捗の表示とは必要です。

ちょうど更新するつもりでいたので、二度手間になってしまいました。実家の滞在時間を長く取れないので、既に始まっているとわかれば取り消さなかったのに、全く不親切です。

家庭内サーバーにしていたWindows 7をWindows 10にしてみましたが...。IISが有効になってポート80等を使われたせいでApache httpdが動作しないトラブル。

このIISが勝手に有効になる現象はネット上で既知ですが、Apache httpdが入っているこのPC以外では経験していません。ということは、意図的な挙動なのでしょう。

つまり、「IISの検出」と称してhttp/httpsのポートだけを確認するといった、悪意のあるロジックがあるのではないかと言うことです。

Windows 10の「強制」アップグレードを挙げるまでもなく、嫌がらせが目立つようになりました。

この怪しい写真が何かというと、先っぽは怪しいThinkPad用ACアダプタです。

ところが認識がうまくいかなくなった(Incorrect AC adapter is attached.)のと、45Wでは物足りないことから、DELL製20V/70Wのものにすげ替えた上で、コネクタ部を分解して中身を修正しました。

フェライトコアが2つなのは、元のノイズが大きかったので念のため。

修正というのは、あの角形コネクタ(スリムチップというそうな)のセンターピンはGNDとの抵抗値で供給能力を識別しているとのことで、適正な抵抗値にしたという次第。

これは実測180Ωでしたが45Wは本来120Ω。流用した70Wに近いのは65Wで280Ω。普通に手に入る一番近いのは270Ωということで、樹脂モールドをカッターで切開し抵抗を付け替え、USB Type-Aのカバーを接着剤と万力とで無理矢理くっつけました。

カバーが少し傾いているのはご愛敬。しかしおかげで正常に使用できるようになりました。

勤務先のOffice 365でOffice 2013から2016に更新してみたのですが...Outlookの添付ファイルがプルダウンメニューになって、幅が固定されファイル名も省略表示されるようになりました。

どうにかならないのかと思ったら「新しいユーザーエクスピリエンスのため」だそうです。当該スレッドは非難囂々、「2013以前に戻すしかない」と2016は完全に地雷扱いという結論になっていました。

ビジネスメールなんて結構ファイル名が長いものをやり取りしてると思うのですが、UIのことを真面目に考えているとはとても思えません。切り替え可能になるとしても次期バージョンからでしょう。

まあ、添付ファイルの扱いはタッチUIを主眼に置くと厄介ですが、だからといってデスクトップアプリとしてのUIを蔑ろにされては困るのです。この辺、Windows 8での失敗を繰り返しているように思います。

そういうわけで、わずか1日で2013に戻しました。

週の最初は何曜日か。

「週末」は土日を指しますが、私は昔「日曜日が最初」と教わった気がします。「日月」「火水木金土」ですから(恐らく当て字的なものであれ)陰陽五行的にも土日をまとめるわけにはいきません。

が、曜日は輸入品ですから、特に英会話の都合もあり正しい認識が必要です。というわけで調べてみると...

旧約聖書では天地創造に従い日曜が最初(「光あれ」で光の日だからでしょうかね)なのですが、宗教は当然他にもあるわけでして。

ISO 8601では月曜を最初と定めていますが、文化的な問題なので「とりあえず」の域を出ません。アメリカ他いわゆる「欧米」や中東、ベトナムなどは日曜、ロシアや東欧(スラブ系の起源だとか)、フランス、中国あたりは月曜が最初だそうな。

ただ中東の複数の言語はその成立過程で日曜を最初としているものの、イスラム文化としては金曜が休みなので土曜からのカレンダーもあるとやら。

結論としては、「世界標準はない」ということになりますね。外国人との会話では週末日曜月曜あたりが絡む場合は、誤解を避けるためthis、last、nextあたりを避けて日数で表現するのが無難なのでしょう。

# the day after tomorrowみたいな言い方は辞書特有なのでやめましょう

まあ、どのみち厳密なやり取りは日付を明記するものですから、些細な問題は気にできる余裕があるときだけ気にする程度の話ではあります。

なんとびっくりCreateProcessだと問題なく、ShellExecute(Ex)だと問題発生、ということだと特定しました。

以前から時々、タスクバーからのFirefoxがうまく起動しないことがありましたが、時々だったものが44では必ずになった、ということのようです。私の環境に問題があるのかもしれませんが、Firefoxでだけ起こるのです。

それぞれのSTARTUPINFOに有意な違いはありませんでしたし、環境変数も同一でした。ともかくCreateProcessなら全く問題が出なくなる、ということがわかっただけでも前進です。

そういうわけで、後述のようなvbsファイルを用意して、タスクバーにあるFirefoxのリンク先をそっちにしておきました。RunがShellExecuteでExecがCreateProcessのようでして。

Set objShell = WScript.CreateObject("WScript.Shell")
objShell.CurrentDirectory = "C:\Program Files (x86)\Mozilla Firefox"
objShell.Exec ("C:\Program Files (x86)\Mozilla Firefox\firefox.exe")

(追記2015/02/15)
44.0.2で修正された模様。ちなみに上記vbsスクリプトは2/10のWindows Updateで利かなくなっており、Win32でCreateProcess APIを使う簡単なexeを別途作ったりしました。

まだ再現条件が全く不明ですが、Firefoxを44にした環境の一つ(Windows 7 x64)で、webが全く接続できない現象が発生しています。

43.0.4に戻すと問題ない
44のSafe Modeでも問題ない
アドオン全て無効でも回避できない
Firefox終了時にApplication Errorが記録される(アドレスは一定せず)
ただしntdll.dllの0x2e389、MSVCP120.dllの0xe439、unknownの0x15020249あたりは何度か見られている
44にした昨日は初回起動時のApplication Error(MSVCP120.dllの0xe439)以外は問題なかった
今日は.NET Framework 4.6.1を入れたが、念のため削除も現象変化なし
(システム復元はいつの間にか壊れており実施できず)

設定への何らかの新規追加項目が悪さをしていると想像されますが、当該環境はとりあえず43.0.4に戻して更新を止めています。

(追記2016/01/29)
どうもプロファイルではなくアプリケーションの問題のような? Prefs.js削除も効果無しでした。
C:\Program Files (x86)\Mozilla Firefoxにtobedeletedという残骸フォルダがありまして、それを削除したら読み込み不能は再現しなくなりました。ただ今度はFlash Pluginの実体(FlashPlayerPlugin_20_0_0_286.exe)が時々落ちています。

(追記2016/02/02)
ログオン後の初回起動しか正常動作しないことがわかりました。ただし、Safe Modeと管理者権限(怖い)での起動ではいつでも動作します。上記取り消し線の記述は、tobedeletedフォルダを管理者権限のファイル管理ツール(卓駆★)から削除した後、そのままfirefox.exeを直接起動したために起きたことのようです。

(追記2016/02/03)
ショートカットの置き場所により不具合が発生することがわかったのですが、条件がよくわかりません...。
タスクバーのピン留め(~\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar)やデスクトップだと再現し、スタートアップ含むスタートメニューだと再現せず、explorer以外からの起動(exe直接・ショートカット共)でも再現せず。
上記「初回起動」は初回でなくスタートアップだから動作していたのでした。しかし試行錯誤しているうちにタスクバーでも再現しなくなりました。一体何だったのやら。

アプリケーションが自分自身をタスクバーにピン留めする方法というのが投稿されていたのですが、Windows 10で動作しませんでした。不思議なことにそれ以外は問題ありません。スタートメニューへのピン留め・解除、及びタスクバーへもピン留めの解除は大丈夫ですが、ピン留めだけがダメなのです。

この方法はIShellDispatchを取得するところから始まっていますが、IShellWindowsからIShellFolderViewDual等を辿ってIShellDispatchを取得すると大丈夫でした。IShellWindowsからの流れはWindows SDKのExecInExplorerサンプルが流用できます。

もう一つ、Alt+Tabのイベントが通知されないようです。EVENT_SYSTEM_MENUSTART/EVENT_SYSTEM_MENUENDをSetWinEventHookに指定してもコールバックが呼ばれません。他のは問題ないようですが。