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のレジスタを変更するだけでなく、コア電圧のレギュレータも変更しているのですね。なかなか面倒な世の中になったものです。

BeagleBone Blackでのカーネルビルド

公式wikiに書いてあることと同じですが、どこに書いてあるかすぐに忘れてしまうことと、wikiが書き換えられて内容が変わってしまった時のための自分に対する備忘録です。

BeagleBone Blackでdebianのカーネルを再ビルドする方法：

（以下は、ubuntuで実行する）

git clone https://github.com/RobertCNelson/bb-kernel

cd bb-kernel/

git checkout origin/am33x-v3.8 -b tmp

または

git checkout origin/am33x-v4.1 -b tmp　（←こちらはうまくいくか試していない）

./build_kernel.sh　（←初めてビルドするときはこちら）

./tools/rebuild.sh　（←コンフィグを変えて再ビルドするときはこちら）




それから、起動時に4D CAPE上のLCDにカスタムの画像を表示する方法：




• 適当な画像を用意。4D CAPE　LCD4.3inch版では480x272以下に抑える。
• gimpなどで224色のインデックスカラーに落とした後、ppmフォーマット（RAWでなく、ASCII形式）でエクスポート
• ppmファイルは、./KERNEL/drivers/video/logo/logo_linux_clut224.ppmと置き換える（のが一番簡単）
• ./tools/rebuild.shで再ビルドする。途中のmenuconfigでは、
  drivers --> Graphic support --> Boot logo
  にチェックを入れて、その中の224色のものにチェックがあれば良い。

起動時に4D CAPE上にカーネルメッセージを表示させない方法：

• linux起動パラメータ（bootargs）から、console=tty0を抜く（uEnv.txtを適宜編集）

起動後にLXDEデスクトップを表示させずにコンソールで止める方法：

• linux起動パラメータに、"text"を追加する

なんか、linuxで調べることが多い＆検索で見つかってもうまくいかないことが多いので、ちょっとしたことでも時間がかかるなぁ。

尿路結石とその顛末

先日、尿路結石になってしまいました。そのときに思ったことを残しておきたいと思います。

• 痛みは突然、夜中にやって来ました。最初は、持病の椎間板ヘルニアが悪化して痛むのかな？と思いました。しかし、様子が違いました。まず、かなり痛い。それから、ヘルニアによる坐骨神経痛でみられる下肢やおしりのしびれがなかったです。
• いわゆる「腰痛」とも違いました。「腰痛」では腰のあたり全体が痛みますが、今回は確かに腰のうちでも背中の右側がピンポイントで痛かったです。
• 「難産に匹敵する痛さ」とも言われていますが、それほどでもなかったです。というか、私は男なので難産がどんなものか比べるべくもないのですが、少なくとも難産のように絶叫したりはしません。が、確かに「ううっ」と唸ってしまうくらいには痛かったです。脂汗なのか、下に書いた嘔吐のせいなのか、よく分からない汗が出ていました。
• とは言え、痛みがピークのときは歩くのも辛かったです。というか、力を入れると痛むような気がする（痛みが怖い）ので、這っていました。とはいえ、実際にはどんな体勢をしていようが、痛いものは痛いのですが。
  後から聞くと、「エビのようになっていた」と家族は言っていました。こちらは痛みに何とか耐えようとしているのに、そんなふうに思っていたとは・・・。
• 吐きました。尿路結石と吐き気（食べたもの）とは関係ないと思うのですが、痛みがピークになると我慢できず吐いてしまいました。しかも、吐いてもう何も残っていないにもかかわらず、痛みがピークになるとまた吐き気が襲ってきます。これは何なんでしょうね。
• 痛みが少し収まった隙に辞典やネットで調べてみて、すぐに「これは尿路結石に違いない」と確信しました。ニュースなどで「救急車をタクシー代わりに使う人がいる」という問題を聞いていましたし、命にかかわるような病気でもないので、朝まで我慢して病院に駆け込めばいいと考えるだけの理性は残っていました。しかし、心配した家族が「救急車、呼ぼうか？」と訊いてくれることに対して、「呼ばなくていい」というその一言がどうしても言えなかったです。叫ばないにしても、そのくらいの痛みがあり、とにかく「早く何とかして欲しい」、その一念でした。結局、救急車を呼んでもらいました。人生初の救急搬送です。
• 深夜の救急病院は、他に患者さんがおらずひっそりとしていました。そして、尿路結石でやってくれる救急処置は、結局痛み止めの座薬だけでした。なかなか効かなかったですが、効き始めると薬の有り難みをこんなに思い知ったのは初めてです。

平日になるまで痛み止めで何とかやり過ごして、後日、泌尿器科にかかりました。レントゲンでは３～４mmの石が膀胱と思われる場所に写っていました。このくらいの大きさの場合は、自然に出るのを待つのが普通だそうです。それまでの間、そして出るときにはもう一度痛みのピークが来ると聞いてちょっと戦々恐々としましたが仕方ありません。痛み止めでやり過ごすのみです。

結局、最初に痛みが出て７日目に石は出ました。それがこれです（左側の黒いもの）。

「石」というくらいですから水に沈むと思っていましたが、浮くんですね。初めて知りました。

おしっこをするときに、ごく僅かな違和感を感じました。また、同時に「カチッ」という音がしたような気がします。便器を見てみると、この黒い塊が浮いていましたので、それを拾っておきました。

へぇ～と思ったのは、結石＝水溶性物質の析出物というイメージでしたので、どちらかというイガイガ、あるいはトゲトゲしたものかと思ったら、角が殆ど無い丸い曲面の石でした。

石が出るまでの間は、やや痛みがぶり返したり、痛みがきつくなると座薬に頼ることもありましたが、石が出た直後くらいからウソのように痛みがピタリとなくなりました。不思議です。それまでは、尿路ではなく膀胱にあったはずなのですが、それがどうして痛むのでしょうか？それから、この石が水に浮くなら、膀胱の中でもだいたい浮いて存在していたはず。膀胱の下からは出にくいかと思うのですが、何らかのタイミングでうまく尿道の方に出れば、それで痛みが消えるというのは、やはり不思議です。

[dynabook R73]スリープ時のインジケータ表示

Windowsをスリープ状態にすると、電源LEDがオレンジ色でゆっくりと点滅します。しかし、これは一定時間経過すると点滅しなくなります。

それがたとえ、「電源オプション」→「スリープ」→「次の時間が経過後休止状態にする」を『なし』に設定していても、です。

そのせいで、スリープ後一定時間経過すると、いまスリープしているのか、電源が切れている（or休止状態になった）のかが分からなくなります。

しかし、確かにスリープ状態には留まっているようです。電源ボタンを押すなどすると、Windowsブート時の玉クルクルは表示されないまま、いきなり元の画面（アプリ開いたまま）に戻りますので。休止状態に落ちているのであれば、玉クルクルが見えるはずです。

ということは、誰がLED点滅を止めさせているのでしょうね。Windowsではなく、おそらくPC自体（BIOS？）でしょう。東芝さん、勝手に止めないでもらえますか？

(2015/5/20 追記)

この件、どうも腑に落ちない。
↑に書いたように「次の時間が経過後休止状態にする」は『なし』に設定しているにもかかわらず、スリープ後何時間が経過したら、どうも”休止状態”相当に落ちているようです。そう思われる理由は・・・

• 復帰するのに時間がかかっている（HDDのアクセスランプが10秒くらいつきっぱなしになった後、スリープ前の状態に戻る）
• スリープ後、何日も放置していても、バッテリーが減っていない

”休止状態”相当という書き方をしたのは、復帰するときに画面には何も表示されないからです。通常、正しく休止状態に落ちた状態から復帰するときには、Windowsのロゴと玉がグルグル回るやつが表示されますが、↑の状態からの復帰では真っ暗のままです。

また、休止状態に落ちているなら、AC電源とバッテリーの両方を外しても、ちゃんと休止状態から戻って元のデスクトップ画面になるはずですが、↑の”休止状態”相当では一度AC/バッテリーを外してしまうと、その後はコールドブートになってしまいます。また、イベントビューアでも「以前のシャットダウンは予期されていたものではありませんでした」というのが残っていますので、やはりスリープ相当のようではあります。

ちなみに、ノートPCなので、ハイブリッドスリープは切れた状態です。

実際は、どういう動作になっているのでしょうね。

(2015/5/28追記)

先日、この件がIntel Rapid Start Technologyの既定の動作であることを初めて知りました。知らなかったことが恥ずかしい・・・。けれど、このページはそのまま置いておこう。

Windowsが持つ休止状態と、Rapid Startとの違いとして、起動速度のことはよく挙げられていますが、その他の違いについてもまとめておきたいと思います。

• 休止状態はhiberfil.sysに保存、Rapid Startは専用パーティションに保存
• 搭載メモリ量が変わった時、休止状態は自動でサイズ調整されるが、Rapid Startは意識的にパーティションの調整が必要
• 休止状態は操作によって望むときに休止状態に入れるが、Rapid Startはスリープ後？？時間という設定しかない（たぶん）ので、好きなときにSSD退避ができる訳ではない。
• 休止状態になるとAC電源＆バッテリーを完全に外しても、その後ちゃんと復帰できるけれど、Rapid StartでSSDに退避している場合は（なぜか）AC電源＆バッテリーを外すと復帰ができず、コールドブートとなる。

この辺の違いを認識した上で、どちらをどのように使うかを考えたいと思います。

ところで、このPCにはIntel Rapid Start Technology Managerがインストールされていないのですが、それで良かったのでしょうかね。
そもそも、BIOSレベルでやってることなので敢えてドライバは必要じゃないのと、名前が"Driver"じゃなくて"Manager"なので、たぶん状態やパーティションの管理（可視化）をするだけなので、必須ではないのだろうと理解しました。

Visual C++のFeature Packをインストールすると、Visual Studioのような自由にドッキング可能なウィンドウが簡単に実現できるけど、ドキュメントが少なくてちょっと苦労する件

自分に対する備忘録です。

• ｘ閉じるボタンで閉じた時に、CPane派生クラスを削除する方法
  
  ドッキングフレームウィンドウのｘボタンを押すとウィンドウは閉じたように見えるけれど、実際には作成たCPane派生クラスのウィンドウは非表示になっているだけ。フレームワークは、CPaneのコンテナウィンドウ（直接の親ミニフレームウィンドウ）しか破棄してくれない。
  ｘボタンを押した時にそのCPane派生ウィンドウも破棄するには、ドッキング対象の親フレームウィンドウクラス（CMDIFrameWndExとか）のOnCloseDockingPaneメンバ関数をオーバーライドする。そして、この関数に渡されるCDockablePaneに対して、WM_CLOSEをPostMessageすると良いようだ。
  SendMessageはダメで、あくまでもフレームワークにいったんCPaneを非表示にさせておいて、その後WM_CLOSEハンドラで削除するという流れになるようだ。
  
  
• ｘ閉じるボタンを押さないで、アプリ側から特定のドッキングウィンドウを削除する方法
  
  これは結構悩みました。CPaneがフローティング状態か、ドッキングしているか、他のドッキングウィンドウとのタブ化されているか、ドッキング後隠れている状態かといろんな状態があって、それによってコンテナウィンドウが違うんですね。どの親コンテナに、どんなメッセージを送るべきか、あるいは、どの関数を呼ぶべきか・・・。
  
  結論は、そういうアプローチじゃなかったです。自分のCPane派生クラスのOnPressCloseButton()メンバ関数を呼ぶだけで良かったんです。それで、上のいろんなドッキング／フローティング状態からも、その親ミニフレームウィンドウも含めて、うまくウィンドウを破棄してくれました。

備忘録

• Windows8はTFTPクライアントを持っているが、デフォルトではインストールされていない。「プログラムのアンインストールと変更」から「Windowsの機能の有効化と無効化」から追加できる。
  ただし、ファイアウォール設定でTFTPに許可を与えないと実際の通信はできない。これは、TFTPクライアントが送信した最初のコマンドパケットに対して、TFTPサーバは別のポート番号から応答パケットを返すので、Windowsはこれを「攻撃」とみなすようだ。
  
• UDPソケットでは、bindをしないと受信ができない（という仕様らしい）。送信はbindしなくてもできる。
  
• Windowsのファイルウォール設定で、アプリケーション名（exe）を指定して通信を許可するときは、ジャンクション上のパスを指定してはいけない。この場合、通信（受信）はブロックされてしまう。
  ジャンクションの先のパス名を指定すればOK。手動で設定する場合は、人間が確認して設定すればよいが、プログラム上でファイアウォール設定をするときは何らかの方法でジャンクションの設定先パス名に変換しなければならないので、少し面倒臭い。