Cygwinでlibintl*が無くなった（？）件

Cygwinでlibintl1～3あたりは、もう配布・インストールできなくなってしまったんでしょうかね？

ある古いプログラム（SH用GCC）が、まだlibintl-2.dllを要求しているんですけど。

無くなった理由が分からないのですが、どなたかご存知であれば教えて下さい。
今のところは、バックアップにしていたcygwinディレクトリからlibintl-2.dllを探して、現在のcygwin/binにコピーしました。とりあえず、これで動いているからヨシとします。

というか、libintll-*.dllって何をやっているのかな？

PassMarkのベンチマーク結果がおかしい件

職場で与えられているPCはそんなにポンポンと買い替えてもらえないので、ちょっと新しいCPUが欲しくなったら自分でノートPCを買って持ち込んでいます（BYODというヤツですね）。
そんな感じで、職場のデスクトップ＝Core-i5、自前のノート＝Core-i7クアッドコアという本末転倒な状態で仕事をしているわけですが、このdynabook R73も（ほぼ）最新スペックだ！と思って使っていましたが、１年以上も経つとどんどん新しいCPUが出てきて、なんだか置いてけぼり感が湧いてきました。（体感的には、IvyBridgeなCore-i5デスクトップの方がややキビキビしているんですがね。）

今は、ノート用Core-i7も6000番代になっているのですね。
というわけで、どれくらい進化しているものなのか、PassMarkのベンチマークサイトで調べてみました。

えっ！？

そんなわけないですよね？ベンチマーク情報のサンプル数が少なくて、低い方に偏っているのかも。

auからMVNOへMNP転出

auのガラケーをやめて、MVNOでスマホデビューしました。

電話番号は引き継ぎたかったのでMNP転出したのですが、どうも腑に落ちないことがありました。
EZWEBから転出手続きができたのは良かった（オペレータの引き止め工作に付き合わなくて済む）のですが、次のような確認画面が出てきました。

これは別にいいんです。問題は次の画面です。

• 「誰でも割の更新月以外では解除料9500円かかる」

というのが正しいはずなのですが、この画像の文章では「誰でも割に加入している人は例外なく解除料＝9500円がかかる」ということになってしまいます。ここに、「更新月以外は・・・」くらいの一言は入れられると思うのですが・・・。
これって、利用者に必要な情報をちゃんと提示していないという点において、不正競争防止法に抵触しないですかね。

Windows10の仮想デスクトップ機能

遂に待望の機能が追加されました！

いろんなアプリを同時に起動したり、割り込みの仕事が入った時に操作が混同しないためにも、仮想デスクトップ環境が必要でした。これまでは、VirtualDemensionのようなフリーソフトを使って来ましたが、やはり"後付け"の機能なのでうまく動かなかったり、ウィンドウがどこかに行ってしまったり（デスクトップ切り替えで裏デスクトップにあるウィンドウが消えたままになったり）することがありました。

その点では、Windows自体が（やっと）仮想デスクトップ機能を持ってくれたことで、その辺の不安定さはなく動いていることは嬉しいです。

しかし、この仮想デスクトップ機能はある意味、中途半端だなぁと思います。まず、

• 新しいデスクトップを用意するには、Windows＋CTRL+Dキーという隠しコマンド的操作をしなければならない。

という点。こんなの知らなければ分かりませんね。どうして、デスクトップやタスクバーからのマウスorタッチ操作で、この機能が見つけられるようにしなかったのでしょう。

それから、

• Windows＋CTRL＋矢印キーで仮想デスクトップ切り替えというのも知らなければ分からない。

これも、どうしてマウスorタッチで切り替えができない仕様なのか理解に苦しみます。

まあ、私はショートカット／ホットキー操作を積極的に使う方なので、一度覚えてしまえば何てことはないのですが、「隠し機能」的な操作になっている点が解せないです。せっかくの良い機能なのに・・・。

更に言わせてもらえれば、いくつか作った仮想デスクトップをキー操作一発で切り替えできるようなホットキーの定義ができたらと思うのはわがままでしょうか。

Windows 10でできなくなったこと。その１

ニッチな使い方かも知れませんが、「Windowsキー」＋"アプリケーション名のタイプ入力"でアプリケーションが見つからないようになってしまいました。

いや、普通にインストールするアプリケーションは問題なく見つけられるんです。

問題は、フリーソフトなどインストールを必要としないアプリケーションをスタート画面に「ピン留め」しても、上の操作では検索してくれなくなったということです。

例えば、適当なフォルダに展開したフリーソフト（など）を素早く起動できるようにしたいとき、でも「タスクバーにピン留め」するほどではないと思う場合は、Windows 8までは次のようにやっていました。

1. 最初は目的のフォルダをエクスプローラで開いて移動する。そして、目的のアプリで右クリックして「スタート画面にピン留め」する。
2. 次からは、「Windowsキー」＋"そのアプリ名のタイプ入力"で、ピン留めしたアプリが検索されるので、ENTERキーで起動。

Windows 10では、この操作ができなくなってしまっています。

１でスタート画面にピン留めした段階で、確かにスタート画面の中にはそのアプリが存在するのですが、それをマウスを使ってスクロールして目で追って探すなどということは、できればやりたくないです。キーボード操作が多い私の使い方では、目で探すよりキーを押すほうがよっぽど速いです。

Windows 8の頃は、この操作での検索はWindows Searchの検索結果を使用しているようでしたので、「インデックスのオプション」で検索の対象フォルダにスタート画面用のショートカットが保存されているフォルダ（＝%USERPROFILE%￥AppData￥Roaming￥Microsoft￥Windows￥Start Menu）を指定してみましたが、新しくピン留めしたショートカットはやはり検索してくれないです。

スタート画面での検索は、どのデータベースを使っているのでしょうか・・・

Windows10のハマりポイント（POPFile）

Windows8.1からWindows10にアップグレードしたPCで、POPFileが動いていないことに気がつきました。調べてみると、POPFile関連の環境変数（POPFILE_ROOTなど）が8.3名（DOS名、短縮形式）ではなく、ロングファイル名に変換された結果、パス名にスペース文字が含まれていることが問題となっているようです。

そこで、システムの詳細設定から環境変数を変更してみます。
事前にコマンドプロンプトでdir /xを実行するなどして、"Program Files (x86)"フォルダの8.3名を調べておきます。私のPCでは、"PROGRA~2"となっていましたので、環境変数のPOPFILE_ROOTを"c:￥PROGRA~2￥POPFile"のように変更します。その後、POPFile.exeを直接実行してみると、ちゃんと起動できていました。タスクマネージャにも、ちゃんとプロセスが起動していますし、POPFileコントロールセンターも表示できていました。

しかし、です。Windowsを再起動すると、やはりPOPFileは起動しません。もう一度、環境変数を確認してみると、先ほど8.3名に変更したはずなのに、元のロングファイル名に戻っています。何か操作ミスをやらかしたのかと思い、再度環境変数を書き換えてテストするとちゃんとPOPFileが起動するものの、やはり再起動とか、環境変数の設定ダイアログを開いたりすると、何かの拍子に元に戻されてしまいます。

仕方が無いので、POPFile自体を空白文字を含まないパスにインストールし直すことにしました。
一旦、POPFileをアンインストールし、再度インストールします。新しくインストールするときは、デフォルトのインストール先ではなく、スペースを含まないパスを指定してインストールします。ちなみに、私は、"c:￥ProgramFiles(x86)￥POPFile"（←空白を消している）にインストールしました。
これまでの学習データや設定はそのまま残るようなので、再インストールすると自動的に読み込まれて、以前と同じ状態で使えるようになりました。

Dynabook R73にWindows 10を入れてみた

普通にインストールできました。
特に互換性云々というような問題は出ませんでした。TOSHIBA独自のドライバ関係も、Windows8のときのままで使用できているようです。少なくとも、デバイスマネージャに「！」は出ませんでした。

OSは、実際には別途入手していたWindows8 Proをクリーンインストールして、そこからWindows 10Proへのアップグレードを行いました。Windows 10のISOイメージは手動で入手できるので、Windows10無印とProの２つをダウンロードしてから、USBメモリにコピーして、Windows8の動作状態からsetup.exeを実行してインストールしました。

Windows10を使ってみて・・・・

Windows8とくらべて、特に何がどうということはありませんでした。今のところ、Windows 10に乗り換えなければ！という理由が見当たりません。とりあえず、よく使うアプリ（Visual Studio2008とか）は普通に動いていましたので、いつでも気が向いた時に移行すればいいかな～という感じです。

新しいブラウザEdgeですが、速度はそこそこながら、あまりいい印象を持ちませんでした。

1. ダウンロードリンクをクリックしても反応しないことがある。
2. 検索ボックスは普段隠れていて、ウィンドウ上部をクリックすると現れるのは不親切ではないか？

上の１の件ですが、どうもクリックした時にダウンロード対象ファイルに危険がないかどうかをどこか（Microsoftのサーバ？）に問い合わせている雰囲気です。その結果を受け取るまでは、ダウンロードリンクをいくら押しても何の反応もなく、イライラします。そして、忘れた頃（５分とか１０分後）にダウンロード開始の表示が出る、しかも何回も押してしまっているので、何個もダウンロードしようとする、という現象が見られました。

すぐにダウンロードを開始するもの（できるもの）もあるのですが、イラッとしたのでChromeを入れようとしてChromeのページでダウンロード＆インストールのボタンを押しても、こちらも反応しなかったです。待ちきれなかったので、別PCでダウンロードしたChromeSetup.exeをコピーして実行してインストールしました。Chromeでは、何でもすぐにダウンロードできていましたので、ブラウザの問題のようです。

それから、Windows Updateはどこに行ったのでしょうね？コントロールパネルからは消えていました。おそらくは、Updateする／しないという選択ではなく、常にUpdateするというような方針にしたいのでしょうか＞Microsoft。実際、Windowsキー＋"update"で検索すると新しいWindows Updateの画面が見つかりましたが、「更新を確認する」とかすると、有無を言わせずインストールまでしてしまうようです。これを止める設定はどこかにあったのかな？

面白いことに、リリースからまだ１日しか経っていない7/30日時点で、すでに３つのアップデートがありました。出たばっかなのに・・・。

Windowsのバックアップと復元にはDismを使う

500GBクラスのSSDが2万円を割り込んだら買おうと思って価格.comとかを見ていたら、500GBには少し満たないけれど480GBのものが2万円を割り込んでいたの思わず購入しました。

• SanDISK UltraII 480GB

もうすぐWindows10が出るので、そのテスト用にもひとつ確保したかったので。

実際には、このPCで使っていた256GBのSSDをテスト用にして、今回買った新しいSSDへ換装しました。その際、ディスクのクローンにはEASE US　todo backupとかParagonとかは使わないで、最近知ったMicrosoft純正のDismを使って引っ越しました。このDism、なかなかの"神"ツールだと思います。bcdedit、diskpartあたりと組み合わせて使えば、クローンはもちろん、リカバリイメージ／バックアップイメージからの復旧も自由自在です。

DismはWindows8上からも使えますが、それではSSD/HDDの引っ越しはできないので、Windows PE環境を用意します。単純にWindowsのインストールディスクでよさそうですが、DVDからの起動は遅いですから、そのWindowsのインストールディスクをUSBメモリにコピーしてBIOS/UEFIブートに対応したものを使用して、USBメモリからブートできるようにして作業しました。

まずは、元となった256GBのSSDのイメージ化です。Windows PEでブートしたら、dismでWindowsのあるドライブを丸ごと.wimファイルにイメージ化します。

dism /capture-image /imagefile:イメージファイル名.wim /compress:max /capturedir:(目的のWindowsのあるドライブ名):

Windows PEでブートするとCドライブが目的のWindowsシステムとなっているとは限らないので、diskpartなどで予め調べておきます。また、Windows PE環境はRAM DISK上で動作していて、その総容量が32MByteとか非常に小さいので、テンポラリフォルダの容量もかなり小さいです。dismを使うと、「エラー80　ファイルが有ります」というような謎のエラーが出ることがありますが、これは単にテンポラリ容量の不足が原因なので、dismを使う前にset TMP=?:\temp [ENTER] set TEMP=?:\temp [ENTER] のようにして、テンポラリフォルダを十分容量のある別ドライブ上に設定しておきます。

これで現在使っている環境が丸ごとwimファイルに落とせたので、心置きなく作業ができます。

SSDを新しく買ったSanDISKのものと交換します。まだ、パーティションも切っていないまっさらの状態ですが、USBメモリでブートできるWindows PE環境と、先ほど作ったwimイメージファイルがあれば元のWindows環境に戻るので、この段階で換装してしまいます。

Windows PEでブートしたら、SSDのパーティションとフォーマットをします。

diskpartを起動して、以下の操作でSSDに対してパーティションを切りました。

[GPTへの変更]

 convert gpt

[予約パーティションの作成 - 必須ではないが一応作成しておく]

　create part msr size=128

[システムパーティション（EFIパーティション）の作成]

　create part efi size=100

　format quick fs=fat32 label="EFI"

  assign letter=s

[Windows用のパーティションの作成]

  create part pri size=任意

  format quick fs=ntfs label="Windows 8"

  assign letter=c

次に、UEFIブート用のコードをBCDをsドライブにコピーします。

これはUEFIブート時のブートマネージャとBCDを設定するものなので、とりあえずは適当なもので済ませました。今回は、Windows PE起動に使ったUSBメモリに入っていた\efiディレクトリを丸ごとsドライブにコピーしました。

  robocopy (USBメモリのドライブ名):\ s:\ /S /E /SL /J /COPYALL

BCDの調整が必要ですが、先にwimイメージを展開します。

  dism /apply-image /imagefile:(wimイメージファイル名) /index:1 /applydir:c:\

このとき注意すべきは、上にも書いたようにテンポラリフォルダの設定です。dism実行中に、上に書いたエラーや、「ディスクの容量が足りません」的なエラーがでた場合は、先に環境変数TMP/TEMPを適切に変更しておきます。

また、イメージの展開先ドライブ名は必ず”Cドライブ”とします。別のドライブ名にイメージを展開してもWindowsは起動できるのですが、dismは展開するときにジャンクションをそのドライブ名で設定してしまいます。Windowsは通常Cドライブで起動するので、ジャンクションの参照先がCドライブ以外になっていると見えなくなってしまいます。特に"ユーザー"フォルダ配下ではジャンクションが多数設定されているので、それらが全滅してしまいます。

あとは、s:\efi\microsoft\boot\BCDの内容を調整するだけです。

{default}エントリのdevice値、osdevice値が正しいパーティションを指していないようであれば、先ほど展開したWindowsのあるパーティションを指すように設定します。

また、同じく{default}エントリのpath値は、UEFIブートであれば、\windows\system32\boot\winload.efiに設定します。

他の値は、ちゃんと起動できているシステムのBCD値を真似ておけば、だいたいOKでした。

とりあえず、これだけでほぼ元のWindows環境が新しいSSDに移行出来て、ブート出来る状態になりました。

あとは、必要に応じて、Windows回復環境用のパーティション作成・イメージ展開・BCD設定をするなどしておけば完璧ですが、今回のようにUSBメモリブートでWindows PE環境が起動できれば、WIMイメージの展開からブート設定までひと通りのことができるので、敢えてWindows回復環境までは作りこみませんでした。

余談ですが、dismコマンド自体は仮想ディスクイメージファイル(VHD)に対して使える場合と使えない場合があるそうですが、マウントされた仮想ディスクには物理ディスクと同様に使えるようなので、Windows8のシステムバックアップイメージの復元にも使えそうです。このシステムバックアップの復元はエラーが出ることが多く、その原因も不明で解決できないのですが、dismコマンドでマウントされた仮想ディスクをwimイメージ化できるので、上と同じ要領でWindowsシステムを復元できそうです。

Windows 8.1 自動修復からの回復

いつも使っていたWindows8が、先日急に「自動修復」で起動するようになってしまいました。そして、自動修復がうまくいくならまだしも、ログファイル（SrtTrail.txt）を見てみると、「ご使用のバージョンと互換性がありません」という意味不明のメッセージが出ていました。

• 自分で判断して、勝手に『自動修復』しようとしているのに、互換性がないなんてどういうこと？
• そもそも、自動修復機能はMicrosoftが仕込んだ機能でしょう？なのに、どうして互換性云々というのか？

などと突っ込みどころ満載ですが、ツッコんでも治らないので、いろいろと検索しました。

しかし、困っている人はかなり居るけれど大抵は「リカバリ」することになるようですね。ある意味この方法が一番の「正解」なのでしょうが、個人的には負けを認めているようで何だか納得出来ないです・・・。

というわけで、四苦八苦した顛末です。

まず、「自動修復を準備しています」に勝手に入るようになると、セーフモードにすら入れない（＝やっぱり『自動修復』で起動してしまう）のを何とかしないといけません。この点は、BCDの通常起動設定である{current}にrecoverenabled値がyesになっていることに気づきました。これをbcdeditで消してやると、少なくとも「自動修復」のループからは抜けられそうです。
というわけで、コマンドプロンプトを立ち上げて、
bcdedit /deletevalue {current} recoveryenabled
として、値を消しました。

再起動すると、今度は自動修復に入らずに通常起動に進んだようですが、そこで今度はBSOD発生です。今回のケースでは、wfplwfs.sysが読み込めないか壊れていますと出ましたので、HDD故障を覚悟しましたが、ダメ元でこのファイルのみを修復してみました。USBメモリからブートして、他のWindows8.1に入っていたwfplwfs.sysを問題のPCにコピーしました。

すると、今度は起動してデスクトップ画面までたどり着きました。しかし、「d3d10_1.dllが壊れている」とか何とかのエラーが出ますし、何だか反応がかなり遅いです。
まあ、HDDの故障か、少なくともシステムファイルの破損が起きているのは間違いないので、chkdsk /rとsfc /scannowを実行して、ディスク＆ファイルの検査をしました。sfcの方では、いくつかのファイルの破損が報告されました。chkdskの方は、かなりの時間がかかるようなので、結果待ちの状態です。

結論はまだですが、やはり少なくともリカバリを、場合によってはHDDを交換した方が良いのかもしれません。

最後に、↑のような操作をするには、BCDに関する慣れがないうちはやらない方がいいかも知れません。万一、まったくブートできなくなったとしても保障できませんので。
それから、少なくともUSBブートできる環境が必要になるでしょう。これがあれば、BCDのバックアップやテスト用ブート環境の構築がやりやすくなりますから。実際、↑の説明では「recoverenabled値を削除する」と書きましたが、私は念を入れて、{current}設定をコピーした上でコピーした側のrecoveryenabled値を削除しました。そして、ブート時の選択画面からコピーした側の設定で起動する方法を行いました。

[備忘録]BeagleBone Blackのコアクロック変更

訳あって、BeagleBone Blackのコアクロックを強制的に落とすテストをすることになって、調べてみた件。

Linux起動時の最初の方でアーキテクチャ別／ボード別の初期化処理の中で初期化されているものと思って調べてみましたが、どうも該当する処理が見つからない。
初期化部分というよりはcpufreqというドライバの中で、そして「設定」というよりは「制御」されているということが分かりました。
いつも使っているWindowsでは、高負荷のときはクロックを上げ、低負荷では下げるということを当たり前のように捉えていましたが、組み込みLinuxでもそういうことをしているとは、すぐには考えが及びませんでした。

というわけで、cpufreqドライバと関係するソースを探してみるも、具体的にクロック速度を定義しているところが見つからない。

root@beaglebone:~# cat </sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
300000 600000 800000 1000000
root@beaglebone:~#

このように300MHz/600MHz/800MHz/1GHzがリストアップされるけれど、このリストはどこで定義されているのだろう？

答えは、device treeにありました（こういう時にもdtbを使うんだなぁ、と思いました）。

KERNEL/arch/arm/boot/dts/am335x-boneblack.dtsにdevice treeのソースがありましたので、これをちょっと書き換えてみたところ、指定したクロックの範囲内で動作させることができることが確認できました。

余談ですが、クロックを変更するのにPLLのレジスタを変更するだけでなく、コア電圧のレギュレータも変更しているのですね。なかなか面倒な世の中になったものです。