1 月 01
2008/1/1 付で WinRing0 1.1.1 をリリースします。
（多分最後の）仕様変更を行います。詳細は後ほど…
【2008/1/2 14:45 追記】元旦リリースは間に合いませんでした。
12 月 31
【進捗】
- OpenLibSys Extension API 案の作成
- ANSI -> Unicode 変換ルーチン作成（暫定版）
- MultiByteToWideChar (MSDN) を使用 - Win9x 用ドライバおよび x64 用ドライバ（署名なし）のビルド
- 最終版時に更新予定
【今後の課題】
- 複数プロセッサの情報管理
- プロセッサ分だけクラスオブジェクトを作成し保持するべきかどうか
【ひとりごと】
年内に雰囲気だけは…ということで、一応がんばってみました。一番重要な OpenLibSys の Extension API 仕様がまだ固まっていな状況ではありますが、今回のリリースでは OpenLibSys から文字列を取り出す機能（暫定版）を実装しました。
CrystalCPUID 4 では実装できなかった機能も色々搭載したいので、出来るだけ早めに既存コードの移植を終えて新規開発機能に注力したいと思います。次のリリースは休み明けかな？そのときには、メインダイアログも少しは機能するようになっていると良いのですが…
【リリース】
今のところ、CrystalCPUID 4.x で実現している機能の半分も実装しておりませんので、開発状況が気になる方向けのリリースです。開発超初期版なので転載されても困りますが、一応修正 BSD ライセンスです。
特に、メインダイアログは『飾り』です！！
- CrystalCPUID 5 -Estel- Dev20 (432 KB, NT - x86 - Unicode)
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 が動作しなかった方の動作レポートをお願いしたいと思います。
- CrystalCPUID 5 -Estel- Dev16 (433KB, NT - x86 - Unicode)
12 月 24
【本日の進捗】
- OpenLibSys のロード関連
- UAC への対応および NT4/2000/XP においても必要に応じて管理者権限を要求する機能を搭載
- IE4 以降がインストールされていない NT4 でアクセス違反が発生する不具合を修正
- GetDriverStatus API を作成
- デバイスドライバをシステムにインストール＆アンインストールする OpenLibSys Driver Manager を更新
【メモ】
- IsCurrentUserLocalAdministrator() [スレッドがローカル管理者アカウントのユーザー コンテキストで実行されるかどうか確認する方法。 ] を用いることで、NT4 でも管理者権限で実行されているかどうか確認する機能を実現できました。
- OpenLibSys Driver Manager において、デバイスドライバのアンインストールを完了するためには、一度アプリを終了する必要があるため、インストールボタンおよびアンインストールボタンを 1 回ずつしか押せないようにしました。
【イイワケ】
- 今日は、管理者権限の処理周りに時間がかかってしまったため、System Information by DMI まで進みませんでした。
12 月 24
デバイスドライバをシステムにインストールする機能を復活？させました。システムにドライバをインストールしてしまえば、管理者権限がなくても CrystalCPUID が動作できるようになります。
WinRing0 にはドライバをシステムにインストールする機能がない（あまりにアレなので敢えて取り除いています）ため、ドライバがシステムにインストールされているか、普通にロードされているかを識別する API がありません。この API がないと管理者権限でアプリを起動するべきかどうかを判断できないので、GetDriverStatus API を追加しようと思います。
ようやく CrystalCPUID 5 -Estel- と OpenLibSys -PureCrystal- を開発しているという気分になってきました。長年愛用した Visual C++ 6.0 ともようやくお別れ出来そうです。
12 月 24
◇公式サイト
1.0.11 からの変更点
- マニュアルに Visual C++ 2008 対応に関する記述を追加
- OlsApiInitDef.h および OlsApiInitExt.h を追加
RUN_TIME_DYNAMIC_LINKING 使用時に複数のファイルから WinRing0 API を呼び出すことができない問題に対応 - Visual C++ 2008 Express Edition 対策
OlsDll.rc 内の “afxres.h” を <windows.h> に変更するよう指示するコメントを追加
◇WinRing0SampleCpp.exe (1.0.7.8)
- OlsApiInitDef.h および OlsApiInitExt.h の使用方法を提示するための変更
■メモ
DLL ファイルおよびドライバファイルは 1.0.11 と同一です。
12 月 24
今日もいそいそプログラミング… と。
OpenLibSys と CrystalCPUID の連携コードを書いている際に気が付いたことがあります。
WinRing0 には、RUN_TIME_DYNAMIC_LINKING と LOAD_TIME_DYNAMIC_LINKING それぞれに対応するライブラリ初期化ルーチンが付属しているのですが、RUN_TIME_DYNAMIC_LINKING 用の OlsApiInit.h を使用してライブラリの初期化を行っても、他のファイルから API を呼び出せないという問題があることに気がつきました。サンプルプログラムは、ひとつのダイアログで完結していたので気が付かなかった…。考えてみると当たり前なのですが。
OlsApiIni.h はグローバル空間に WinRing0 API を展開し初期化するため、他のファイルから API を呼び出すためには、extern “API 名” してあげないと参照できません。
例：GetDllStatus() の場合
typedef DWORD (WINAPI *_GetDllStatus) ();
extern _GetDllStatus GetDllStatus;
もちろん、OlsApiInitExtern.h を作って、extern しまくれば解決するわけですが…。英語で状況を説明してマニュアルを書くのは大変です。というわけで、仕様というか初期化ルーチンはオマケですから。
リンク方式の使い分け (MSDN) というわけで、複数のファイルから WinRing0 API を使用する場合は、暗黙的リンク (LOAD_TIME_DYNAMIC_LINKING) を推奨の方向で…。
【2007/12/24 11:12 追記】
OlsApiInitExt.h と OlsApiInitDef.h を作成し、RUN_TIME_DYNAMIC_LINKING においても、複数のファイルから WinRing0/OpenLibSys API を使用できるようにしました。サンプルプログラムも更新しなければならないので、何かのついでに更新したいと思います。
