4 月 20
はじめてのCrystalCPUID (『64ビットCPU(AMD64+EM64T)でアセンブラ』さん)
Vista + UAC 環境で CrystalCPUID をスタートアップさせる方法を丁寧に解説してくださってます。
CrystalDiskInfo にスタートアップ登録機能を実装すべく調査を開始したところなのですが、2000/XP は良いとして、Vista/2008 は結構微妙な感じです。CrystalDiskInfo 自体は常に管理者権限で起動しているので、レジストリの変更は可能なのですが、タスクスケジューラへの登録と同じ処理って簡単にできるのかなぁ…
【追記】
マニュアルを丁寧に書くよりもメニューからサクッとスタートアップに登録できる方がユーザ的には絶対いいよなぁ。
1 月 06
【進捗】
- メニューの多言語化およびテーマ機能をまとめた CDHtmlMainDialog クラスを作成
先日作成した CDHtmlDialogEx を継承した、メインダイアログ専用クラスです。多少設計に難あり?
【ひとりごと】
ずいぶん前から新しいプロジェクトを立ち上げるたびに同じこと何度もしているなぁ~と思っていたのですが、新プロジェクトが乱立しつつある現状を鑑みて、共通処理をクラスにまとめました。
CDHtmlMainDialog と CDHtmlDialogEx は CrystalCPUID 5 -Estel- と Crystal******** -Feena- に適用し、品質を高めた上で、そのうち CrystalDiskMark に適用したいと思います。ちなみに、来年度リリース予定の OpenLibSys.org にも使用予定です。
12 月 31
【進捗】
- OpenLibSys Extension API 案の作成
- ANSI -> Unicode 変換ルーチン作成(暫定版)
- MultiByteToWideChar (MSDN) を使用
- Win9x 用ドライバおよび x64 用ドライバ(署名なし)のビルド
- 最終版時に更新予定
【今後の課題】
- 複数プロセッサの情報管理
- プロセッサ分だけクラスオブジェクトを作成し保持するべきかどうか
【ひとりごと】
年内に雰囲気だけは…ということで、一応がんばってみました。一番重要な OpenLibSys の Extension API 仕様がまだ固まっていな状況ではありますが、今回のリリースでは OpenLibSys から文字列を取り出す機能(暫定版)を実装しました。
CrystalCPUID 4 では実装できなかった機能も色々搭載したいので、出来るだけ早めに既存コードの移植を終えて新規開発機能に注力したいと思います。次のリリースは休み明けかな?そのときには、メインダイアログも少しは機能するようになっていると良いのですが…
【リリース】
今のところ、CrystalCPUID 4.x で実現している機能の半分も実装しておりませんので、開発状況が気になる方向けのリリースです。開発超初期版なので転載されても困りますが、一応修正 BSD ライセンスです。
特に、メインダイアログは『飾り』です!!
12 月 29
【進捗】
- System Information by DMI
- デザインは今後改善予定
【作業予定】
- 文字列の ANSI -> Unicode 変換ルーチン
【ひとりごと】
文字列のバッファサイズの扱いは何かと面倒です。実際のところ、アプリ側で大きめのバッファを用意しておくことで、厳密なエラーチェックを省くことになると思いますが、ライブラリ側では、バッファサイズを確認してサイズが足りなければ何バイトのバッファが必要かを返却する等のまじめな処理が必要になるわけです。
ここら辺はしっかり作りこまないと後々不幸になるのでなんとかがんばりたいと思います。
DMI や NameString などは ANSI 文字列として情報が格納されているため、文字列の加工処理は ANSI 用関数で行う必要があります。はっきり言って OpenLibSys.dll を Unicode ビルドするメリットは何もないので、MBCS ビルドしつつ、GetOslStringW の内部で ANSI -> Unicode の処理をかますのが正解な気がしてきました。

12 月 28
【進捗】
- OpenLibSys Extension API の暫定定義
- DWORD GetOlsStringA(DWORD index, PCHAR str, DWORD sizeInBytes);
- DWORD GetOlsStringW(DWORD index, PWCHAR str, DWORD sizeInWords);
- DWORD GetOlsValue(DWORD index, PDWORD value);
- DWORD SetOlsValue(DWORD index, DWORD value);
- OpenLibSys からの文字列取得機能の動作確認 (ANSI 版のみ)
【作業予定】
- System Information by DMI
- 文字列の ANSI <-> Unicode 変換ルーチン
【ひとりごと】
OpenLibSys.dll 内部では基本的に ANSI 文字列しか扱わないので、GetOlsStringA だけで良いような気もするのですが、将来の拡張を考えると最初から Unicode ビルドに対応しておきたいところ。
12 月 27
【進捗】
- メニューが複数段になったときの処理を改善
- Feature Flags Infromation のバグを修正
- Dialog サイズの定義方法を改善
【作業中】
- System Information by DMI
- OpenLibSys Extension API の検討
- GetOlsStringA, GetOlsStringW
- GetOlsValue
あたりを定義して、これらの API を使ってアプリケーションは OpenLibSys からデータを引き出す方式を採用予定(SysInfo と基本は同じだけど C++ 以外からも使える)
現在作業中の項目が出来次第開発途上版を公開予定。OpenLibSys Extension API の定義は結構大変そうです。(当たり前ですけどね) なんにせよ、また何年後かに再構築をする必要が発生しないよう良く考えて定義したいところです。
12 月 26
【進捗】
- CPUID Information / Feature Flags において OpenLibSys の Cpuid API を使用するように変更
- Feature Flags において、未対応の項目についても適当に表示してしまう不具合を修正
【リリース】
今のところ、CrystalCPUID 4.x で実現している機能の半分も実装しておりませんので、開発状況が気になる方向けのリリースです。開発超初期版なので転載されても困りますが、一応修正 BSD ライセンスです。
メインダイアログは『飾り』です。
CrystalCPUID 4.x が動作しなかった方の動作レポートをお願いしたいと思います。
12 月 26
【進捗】
- モーダルダイアログ終了処理のバグを修正
- メニューが複数段になってもクライアント領域を指定サイズに維持する機能を搭載
【メモ】
CrystalDiskMark では、多言語対応を果たしたものの言語によってはメニューが2段になってしまうことがあるよう(対応言語版 OS ではフォントの関係で問題ないのかも?)で困っていました。
色々調べたのですが、メニューの段数を直接取得する方法が見つからず、AdjustWindowRect はメニューが1段の場合にしか対応していないため、以下のように一度ウィンドウサイズを変更してから所望のサイズとの差分を取得し、ウィンドウサイズを再設定するという方法を考えてみました。クライアントサイズが既に所望のサイズの場合は、サイズ変更を行わず return します。
もう少しクールにまとめたいものですが…とりあえずこんな感じ。
void SetClientRect(DWORD sizeX, DWORD sizeY)
{
RECT rc;
RECT clientRc;
rc.left = 0;
rc.top = 0;
rc.right = sizeX;
rc.bottom = sizeY;
GetClientRect(&clientRc);
if(clientRc.bottom - clientRc.top == sizeY
&& clientRc.right - clientRc.left == sizeX)
{
return;
}
AdjustWindowRect(&rc, WS_DLGFRAME, TRUE);
SetWindowPos(&CWnd::wndTop, -1, -1,
rc.right - rc.left, rc.bottom - rc.top,
SWP_NOMOVE);
GetClientRect(&clientRc);
if(clientRc.bottom - clientRc.top != sizeY)
{
SetWindowPos(&CWnd::wndTop , -1, -1,
rc.right - rc.left,
rc.bottom - rc.top + sizeY
- (clientRc.bottom - clientRc.top),
SWP_NOMOVE);
}
}

12 月 24
NT4 SP1 でも動作するように意地になって色々調査したところ、IE のバージョンチェック方法に問題があったことが判明(^_^;
CDHtmlDialog は IE に依存しているため、動作には最低でも IE4 が必要となります。そこで、私は、
if(GetFileVersion(_T(”Shdocvw.dll”)) < 400){エラー処理;}
という感じで IE 対策をしていたつもりだったのですが…
インストールされている Internet Explorer のバージョンを確認する方法 (MSDN)
によると IE4 における Shdocvw.dll のバージョンは 4.71 とのこと。前もこのページを見ながら IE4 が入っていない NT4 対策をしたような気がするのですが。う~む。
※じゃぁ、CDHtmlDialog 使うのやめたら?というツッコミはご勘弁を。
Visual C++ 2005 を使用しているうちは、NT4 での動作にもこだわりますよぉ~。無駄な努力だけど、なんとなく熱いような気がするので。