Crystal Dew R&D Labs

【進捗】

• 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 ビルドに対応しておきたいところ。

【進捗】

• メニューが複数段になったときの処理を改善
• Feature Flags Infromation のバグを修正 
• Dialog サイズの定義方法を改善

【作業中】

• System Information by DMI
• OpenLibSys Extension API の検討
  - GetOlsStringA, GetOlsStringW
  - GetOlsValue
  あたりを定義して、これらの API を使ってアプリケーションは OpenLibSys からデータを引き出す方式を採用予定（SysInfo と基本は同じだけど C++ 以外からも使える）

現在作業中の項目が出来次第開発途上版を公開予定。OpenLibSys Extension API の定義は結構大変そうです。（当たり前ですけどね）　なんにせよ、また何年後かに再構築をする必要が発生しないよう良く考えて定義したいところです。

【進捗】

• CPUID Information / Feature Flags において OpenLibSys の Cpuid API を使用するように変更
• Feature Flags において、未対応の項目についても適当に表示してしまう不具合を修正

【リリース】

今のところ、CrystalCPUID 4.x で実現している機能の半分も実装しておりませんので、開発状況が気になる方向けのリリースです。開発超初期版なので転載されても困りますが、一応修正 BSD ライセンスです。

メインダイアログは『飾り』です。

CrystalCPUID 4.x が動作しなかった方の動作レポートをお願いしたいと思います。

• CrystalCPUID 5 -Estel- Dev16 (433KB, NT - x86 - Unicode)

【進捗】 

• モーダルダイアログ終了処理のバグを修正
• メニューが複数段になってもクライアント領域を指定サイズに維持する機能を搭載

【メモ】
CrystalDiskMark では、多言語対応を果たしたものの言語によってはメニューが２段になってしまうことがあるよう（対応言語版 OS ではフォントの関係で問題ないのかも？）で困っていました。

色々調べたのですが、メニューの段数を直接取得する方法が見つからず、AdjustWindowRect はメニューが１段の場合にしか対応していないため、以下のように一度ウィンドウサイズを変更してから所望のサイズとの差分を取得し、ウィンドウサイズを再設定するという方法を考えてみました。クライアントサイズが既に所望のサイズの場合は、サイズ変更を行わず 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);
  }
}

【本日の進捗】 

• OpenLibSys のロード関連 
• UAC への対応および NT4/2000/XP においても必要に応じて管理者権限を要求する機能を搭載
• IE4 以降がインストールされていない NT4 でアクセス違反が発生する不具合を修正
• GetDriverStatus API を作成
• デバイスドライバをシステムにインストール＆アンインストールする OpenLibSys Driver Manager を更新 

【メモ】 

• IsCurrentUserLocalAdministrator() [スレッドがローカル管理者アカウントのユーザー コンテキストで実行されるかどうか確認する方法。 ] を用いることで、NT4 でも管理者権限で実行されているかどうか確認する機能を実現できました。 
• OpenLibSys Driver Manager において、デバイスドライバのアンインストールを完了するためには、一度アプリを終了する必要があるため、インストールボタンおよびアンインストールボタンを 1 回ずつしか押せないようにしました。

【イイワケ】

• 今日は、管理者権限の処理周りに時間がかかってしまったため、System Information by DMI まで進みませんでした。

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 での動作にもこだわりますよぉ～。無駄な努力だけど、なんとなく熱いような気がするので。

管理者権限を持っているかどうかを実行時に判別して、ドライバがインストールされていない場合は、管理者権限を要求するという処理を入れようと思ったのですが、これがなかなか難しい C# 版は簡単にできたのですが…

使えそうなのは、

• IsUserAnAdmin (XP 以降/ 2000 では序数でのみ呼び出せるらしい)
• IsUserAdmin (CheckTokenMembership のサンプルコード)

しかし、NT4 では動かないことがわかりました orz えっ？NT4 はどうでも良いだろうって？いやいや、NT4 は仮想 PC 上の妖精さんとして永遠に生き続けるはずです。

と思ったら、

• スレッドがローカル管理者アカウントのユーザー コンテキストで実行されるかどうか確認する方法。

なら NT4 でもいけるみたい。よくよく考えると、CrystalCPUID 5 -Estel- は多言語化対応のため Unicode 版と MBCS 版を別々に用意することになるので、GetProcAddress じゃなくて #ifdef で済みますね。

こういう部分は、一度完成したと自分が思ってしまうと見直すことがないので、やる気があるうちにしっかり実装してしまいたいところ。

デバイスドライバをシステムにインストールする機能を復活？させました。システムにドライバをインストールしてしまえば、管理者権限がなくても CrystalCPUID が動作できるようになります。

WinRing0 にはドライバをシステムにインストールする機能がない（あまりにアレなので敢えて取り除いています）ため、ドライバがシステムにインストールされているか、普通にロードされているかを識別する API がありません。この API がないと管理者権限でアプリを起動するべきかどうかを判断できないので、GetDriverStatus API を追加しようと思います。

ようやく CrystalCPUID 5 -Estel- と OpenLibSys -PureCrystal- を開発しているという気分になってきました。長年愛用した Visual C++ 6.0 ともようやくお別れ出来そうです。

今日もいそいそプログラミング… と。

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 を使用できるようにしました。サンプルプログラムも更新しなければならないので、何かのついでに更新したいと思います。

【本日の進捗】

• BIOS Information by WMI ダイアログを作成
• CPUID Information ダイアログを作成
• 各種拡張機能をモードレスダイアログ化
• CDHtmlDialogEx クラスを改良 （モードレスダイアログに対応）
• テーマ機能を実装（CrystalDiskMark 相当）
• 多言語対応機能を実装（CrystalDiskMark 相当）
• CrystalCpuidDlg.cpp を分割（テーマ機能と多言語対応機能を別ファイルへ）

【ひとりごと】

• CrystalCPUID 4.x よりは遥かに保守がしやすそう。
• 仮想関数の意味がようやく理解できたような気がする。
• 開発ブログっぽくなってきた。ような気がする。

【明日の目標】

• OpenLibSys との連携機能
• System Information by DMI  

あたりの対応をがんばりたいと思います。OpenLibSys の Extension API 仕様はまだ全然考えていないのですが、とりあえずリンクして、一緒に動作するようにするところまでは進めたいと思います。そこまでできれば必要に応じて API を定義していくだけですからね。