予防保守

先々週になるが、ボーナスも出たのでメインマシンのHDDを新調した。サブマシンがBIOSベースで2TBのHDDまでしか扱えないことから、転用を考えて今回も2TBである。で、今まで使っていたHDDは玉突きでサブマシンへ、サブマシンのHDDは外付けケースを購入してバックアップ用兼、非常時用という具合である。

メインマシンはWindows 7以降で使うのでSSD入れようがオーバー2TBのHDDを入れても何の問題もないのだが問題はWindows 7以前で動くサブマシンである。一応まだ、Windowsフリーソフト作家としてWindows XP/Vistaが動く環境を持っておきたいのでサブマシンで使えるHDDを確保しておくために、今回も2TBのHDDを購入して予備を増やしたという訳である。幸い、近年ではSMART情報で代替セクタが使われたHDDが1台出たくらいでクラッシュとかは出ていないが、非常時に備えておくに越したことはないというものである。

こうしたPCの動態保存にあたって何が一番の問題かと考えると、CPUファンは古いCPUでも対応してくれているし、システムファン、電源は効率が良くなるといった内部的な変化はあるがインタフェースの変化はないので、動態保存の一番の問題はHDDになるのではなかろうか。
さすがに、マザーボードがいかれたらおしまいではあるが、その時は中途半端なWindows Vistaを切り捨ててWindows XPは仮想マシンでということになると思う。MSX PLAYerなどXP世代までのソフトがあるわけで、XPは残しておきたいというところである。

俺のソフトの俺による俺のための機能

今日7/16にBookSyncをバージョンアップしたわけだが、Opera 25以降タブにUnsorted bookmarksを無視するという機能を追加している。
この機能は当該ブックマークのUnsorted bookmarksを同期・変換対象とせず、同期・変換後も元の内容が残るというものである。

この機能であるが、Firefoxの他のブックマークに大量のブックマークをメモ代わりのごとく入れている俺用の機能だったりする。Firefoxの他のブックマークとOpera 25以降のUnsorted bookmarksは基本的に使い道は一緒なのだが、Firefoxの他のブックマークにはフォルダを作れるが、Opera 25以降のUnsorted bookmarksにはフォルダを作れないという違いがある。
これらを同期するとどうなるか。Firefoxの他のブックマークに作ったフォルダの中に入れていたブックマークがOpera 25以降のUnsorted bookmarksフォルダ直下に同期される。そして、次に同期を行うとFirefoxの他のブックマークに作ったフォルダの中に入れていたブックマークが他のブックマークフォルダ直下にもOpera経由で同期されて収拾がつかなくなるという訳である。
そこで、Opera 25以降のUnsorted bookmarksを無視することでFirefoxの他のブックマークに作ったフォルダの中に入れていたブックマークの二重化を防ぐというのが、今回追加した機能の意図である。
それほどOpera使っているわけでもないし。

そもそも他のブックマーク使いすぎだろうと言われれば身もふたもないが。

こういう機能をぶち込めるというのはソフトウェアを自作しているからできるわけで、ソフトウェア作者の特権と言えるだろう。

32ビットから32/64ビット並行にするということ

本っ当に久々にBookSyncをバージョンアップした。曲がりなりにも代表作のはず…なのだが。

というのもここのところのChrome独り勝ちの様相の中で各ブラウザのブックマーク関連については見たところ変化がなかったことや、Microsoft Edgeのブックマークは相変わらず低機能な癖に意味不明ということでバージョンアップの必要はないだろうと思っていたことと他のソフトいじっていたことがあったからである(それにしても、Windows 10 Creators Updateでシステムフォントのサイズも変えられなくなったのでMeiryo UIも大っきらい!!が必要になることが増えたのには今でも困惑しているというものである)。

で、今回のバージョンアップだが元は、最近のFirefoxのバージョンアップによるブックマークの内部の変更点についていけてなかったので対応が必要になったというのがそもそもの理由である。旅行に行く前に、行くところに関連するリンク集作ってスマホに入れようと思ったらうまくいかなかったことで1か月以上前から気づいていたのだが、こういう時に限ってMeiryo UIも大っきらい!!いじる必要が出て延び延びになっていたのでようやくのバージョンアップである。

一番派手なバージョンアップ項目になる64ビット版の作成であるが、32ビットプログラムからGetModuleFileNameEx APIで64ビットプログラムのパスが取れないというたった一点のために行ったという訳でである。他のプロセス関連のAPIは動作するのでなんでやねんという感じである。
実際に64ビット化した実感としてはプロジェクトの作り方が分かればあとはバックアップ機能に使っている統合アーカイバプロジェクトのDLLのことに気付いてあれ？と思ったくらいであとはコーディング面ではこれといったこともなかった。むしろ、プロジェクトの作り方の方が面倒だったと言えるだろう。出力パスをすべて精査しないと収拾がつかなくなるわけで、それらをすべてチェックするのに手がかかったというものである。一つのプロジェクト構成で32ビットと64ビットの両方を考慮する必要があるのでそれを考慮する必要があるのが厄介であった。一つのプロジェクト構成には32ビットか64ビットのどちらか一方が結びつく方が楽だと思うんだけどなぁ。一つのプロジェクト構成に32ビットと64ビット両方が結びつくメリットって何だろう？

それにしても、32ビット版プログラム用のProgram Filesフォルダに入れているChromeがバージョンアップされることで32ビット版プログラム用の場所に64ビット版プログラムがあるというのは気持ちはわからないでもないが気持ち悪いと思うのは自分だけだろうか。

なんで忘れてたんだろう？

海外の方から、Meiryo UIも大っきらい!!と共に指摘を受けていたMulSyncについて、ダイアログの位置を調整したVersion 1.3.3をリリースした。

のはいいのだが、作っていて今更ながらEscキーでダイアログを閉じる処理を入れ忘れていたことに気づいて慌ててプロパティを設定した。ほんと、なんで今まで忘れてたんだろう？Windows Formsのプログラムなんてかつての本業と合わせて散々書いてたはずなのに。C++でWin32 API直で叩くときのCreateDialog APIで出したダイアログとごっちゃにでもしたのかな？

いまさらながらWindowsアプリケーション開発のガイドラインを見る

海外の方から、Meiryo UIも大っきらい!!のウインドウ位置がプライマリモニタの左端なのは不便だという旨のメールが来た。で、どうするかなと調べていて、WindowsのGUIアプリを作るようになって16年にしていまさらなのだが始めてWindowsアプリケーション開発のガイドラインを見た。そこには、ちゃんとウインドウやダイアログの表示位置についても書いてあり、中でもただ親ウインドウの中心に子となるダイアログを置くのではなく、視線を考えて左上45％の位置に置くというくだりはなるほどと思ったものである。

いったい、世の中のソフトウェアはガイドライン見てるのかなとか、どうやっているんだろうと軽く思いつつ、ダイアログやヘルプの表示位置を調整してMeiryo UIも大っきらい!! Version 2.34としてリリースした。

昨日は、その後マルチディスプレイの画面を何度も切り替えつつファイルのバックアップを片方のマシンで採りながらもう一方のマシンのchkdskを行っていたが、ダイアログの表示位置がめちゃくちゃだとそのたびにディスプレイ移動してマウスカーソル移動してなんてやる必要があったのかと思うとガイドラインの遵守って大事だなと思わされた最近であった。

さて、この辺のウインドウの表示位置周りの修正、他の拙作にも入れていかないといかんかなぁ。
(2017/06/04 16:20追記)
まずは兄弟的な存在のウインドウの各部分の幅・高さを調整するツールRe-Metricsに反映しました。

じゆう…むじゅん…はかなさ…じぶん……らしさ

Windows 10 Version 1703ではシステムフォントの大きさすら標準では変更できなくなったようで、海外の方がMeiryo UIも大っきらい!!(No!! Meiryo UI)をダウンロードして使うという事例があったので、対応する形でMeiryo UIも大っきらい!!(No!! Meiryo UI)をバージョンアップしました。

今回、Windows 10の詳細なバージョンを表示するようにしたのはWindows 10 Version 1703でシステムフォントの大きさを変更できなくなったことを考えると、今後Meiryo UIも大っきらい!!でシステムフォントの大きさを設定しても反映されなくなることも考えられなくはないので、どの時点でWindowsに変更が入ったかがわかるようにするためです。

考えてみるとWindows側の変更でいつこのソフトが無駄になってもおかしくはないので、案外はかないものかもしれません。そもそも、自由なソフトではないWindowsで自由を求めること自体矛盾してますし。という訳で、本文のタイトルになるという訳です。

文字セットをどうしよう

Windows 10 Creators Updateで良いんだか悪いんだか、Meiryo UIも大っきらい!!にフォーカスが当たったので見直しをかけてるけど文字セットの扱いをどうするか悩んでいる。

影響を受けるところとしては

• 言語ファイルの表示フォントの指定
• プリセットの設定

といったところだろうか。

この辺をどうにかしないと他の国の人がローカライズしようとしたときに表示がおかしいとか、プリセット呼び出してOK押すとシステムフォントが文字化けなんてことになりそうなので、何とかしないといけないんだろうなとぼんやり考えている。
他のいじりたいところはトピックブランチ作った状態でgithubのページにソースは上げているので、文字セット関連を追加してやって、ヘルプのバージョンアップ時の変更点について訳していただいたらバージョンアップかな。
多言語表示ってちゃんとやろうとすると厄介なものだ。

さらば、Vista

2017年4月11日にWindows Vistaのサポートが終了した。

という訳で、以下の手順を採って綺麗な状態でスタンドアローンにして動態保存にした。ネットワークから切断した完全なるパーソナルな状態である。

• SP2統合媒体からクリーンインストールを行う
• Windows Updateで入るすべてのパッチを適用する
• イメージバックアップを取得する
• 手元に落としていたパッチを整理して、Windows Updateで入らなかったパッチを当てる。
• Ultimate Extrasをすべて入れる
• ネットワークインターフェースをすべて無効にする
• ウイルス対策ソフトを外す
• 再度、イメージバックアップを取得する

実際は、工程の中でパッチ等のチェックが全然終わらないので電源を強制断して再実行を何度かやったのでウイルス対策ソフト外す前にsfc /scannowかけてやったりとかしたけど、これで立派な動態保存状態になったのではないだろうか。
動態保存とはいえ、Vista以降固有のソフトはほとんどないというか、Windows 7で済むので拙作の動作確認くらいしか使い道ないけど。

世界は戸惑いとともに回る

Windows 10 Version 1703(Creators Update)でシステムフォントサイズの変更画面が無くなって、それに対して拙作Meiryo UIも大っきらい!!で対処できるというのを自分で作っておきながらなんだかなと戸惑っていたら、アクセス解析経由でさらに不思議な光景を見た。

日本で作った拙作Meiryo UIも大っきらい!!(別名:No!! Meiryo UI)について中国のフォーラムで言及されていたのをアメリカのMicrosoftのフォーラムで引用しているという光景である。
(Has "Change only the text size" been removed in Creators - Microsoft Community)
日本、中国、アメリカと合計で3カ国絡んだことになる。なんとも奇妙な縁だ。

進捗表示は厄介なものだ

今日はメールで指摘があったMulSyncの同期実行時のプログレスバー表示を改善して公開した。

MulSyncはC#と.NET Frameworkで組んでいるのを生かしてワーカースレッドを起動しての実行、進捗表示管理、処理終了後の処理呼び出しといったスレッド周りを面倒見てくれるBackgroundWorkerクラスにおんぶにだっこできたので楽に改善できたのだが、長い時間がかかる処理とその進捗の表示というのは実に厄介なものである。

GUI周りはメインスレッドでないと処理できないので行いたい処理は別にスレッドを立ち上げて処理する必要がある。で、メインスレッドは処理を行うスレッドを待つ際に常に処理を行っているとCPUの実行時間を食うので適度にウェイトを入れる必要があるのだが、その間にも実際の処理は進んでいるのでメインスレッドでの進捗表示と実際の進捗を合わせるのは難しいものである。

どのスレッドからもGUI周りに手を出せる環境があったらなと思うのだが、そんな環境はあるのだろうか。