Crystal Dew R&D Labs

【進捗】

• 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)

GetFileAttributes (MSDN)

によると宣言が

DWORD GetFileAttributes(LPCTSTR lpFileName);

に対して、戻り値は、『関数が失敗すると、-1 が返ります。』 とのこと。

このように、DWORD 型に対して -1 を返しています。Win32 API を眺めてみると他にもそういうのがあるのですが、DWORD (unsigned int) に対して -1 を返すというのは、一般的なんですかねぇ？

今年は、社会人になってから弛みきっていた？プログラマとしての力を取り戻すことが出来ました！？新作を 2 本もリリースことが出来ましたし、次回作の準備も着々と進んでおります。

大晦日ということで、今年の主な出来事を振り返ってみたいと思います。

今年の出来事　ベスト５

1. コードサイニング証明書の取得
   - デジタル署名のまとめ（Vista x64対応）
   - 総合ベンチマークソフト「CrystalMark 2004R2」がWindows Vista x64に対応 (窓の杜)
   有限会社を作るしかないのか…と諦めかけていたときの奇跡に感涙。全俺が泣いた。
2. Project PureCrystal 発動
   - OpenLibSys.org 開設
   - WinRing0 リリース (SourceForge.net デビュー)
   - OpenLibSys 開発中…
   ずいぶん前から構想を練っていたオープンソースハードウェアアクセスライブラリの開発に着手。コア部分を WinRing0 としてリリース！！
3. CrystalDiskMark リリース
   - 窓の杜ライブラリ収録
   - 窓の杜大賞 2007 ノミネート (選外)
   CDHtmlDialog の理解とノウハウを蓄積。単体ベンチとしてはまずまずの成功！？
4. インタビュー(取材)
   - インタビュー記事 (日経PC（ピーシー）21 2007年5月号 )
   - はりぼて友の会が@ITで紹介されました!!
   来年は、OpenLibSys.org で…って無理か。
5. CrystalCPUID 5 -Estel- 開発開始
   ずいぶん前から要望を受け付けていながら、遅々として進まなかった CrystalCPUID 5 ですが、先日、開発コードネームを付与したところ開発力が 1024 % 改善しました。これが『○え』の力なのか…

他にも、この『Crystal Dew R&D Labs』開設が果たした役割（CrystalDiskMark, WinRing0 の開発促進など）も大きかったですね。また、Crystal 関係ではありませんが、TOEIC で初めて 600 点を突破しました。英語苦手意識克服まであと一歩？英語サイトもそれなりに充実してきましたし、WinRing0 のマニュアルは英語版も完備しましたし…まぁ、つたない英語力で良くがんばったなと。

とにかく今年は、コードサイニング証明書が取得できたのがぶっちぎりで一番良かった出来事でした。『諦めなければ願いは叶う』とはいいますが、ホントその通りで、諦めずに調査した甲斐がありました。来年もプログラマとしてがんばれるのはすごく嬉しいです。

と思い調査してみました。

調査してみると COFF ヘッダ内の『MajorSubsystemVersion』のフィールドが 4 から 5 になっていることに気がつきました。確認のために、Visual C++ 2005 でビルドした実行ファイルの当該フィールドを 4 から 7 に変更すると Vista でも実行できなくなりました。ふむふむ。ココが肝みたいですよ。

早速、Visual C++ 2008 でビルドしたあとに実行ファイルの『MajorSubsystemVersion』を 5 から 4 にバイナリエディタで変更し Windows Me で実行してみると・・・

kernel32.dll で GetFileSizeEx がみつかりません orz

GetFileSizeEx は Windows 2000 以降の対応なので、本格的にダメみたいです。MFC を使わない場合は、インポートしている API 的には問題なさそうに見えるのですが・・・動作せず？

当面は、Visual C++ 2005 と Visual C# 2008 の生活を送りたいと思います。

参考：

• /SUBSYSTEM (サブシステムの指定) (MSDN)
• EXEファイルの内部構造（PEヘッダ） (CodeZine)

【進捗】

• System Information by DMI
  - デザインは今後改善予定

【作業予定】

• 文字列の ANSI -> Unicode 変換ルーチン

【ひとりごと】

文字列のバッファサイズの扱いは何かと面倒です。実際のところ、アプリ側で大きめのバッファを用意しておくことで、厳密なエラーチェックを省くことになると思いますが、ライブラリ側では、バッファサイズを確認してサイズが足りなければ何バイトのバッファが必要かを返却する等のまじめな処理が必要になるわけです。

ここら辺はしっかり作りこまないと後々不幸になるのでなんとかがんばりたいと思います。

DMI や NameString などは ANSI 文字列として情報が格納されているため、文字列の加工処理は ANSI 用関数で行う必要があります。はっきり言って OpenLibSys.dll を Unicode ビルドするメリットは何もないので、MBCS ビルドしつつ、GetOslStringW の内部で ANSI -> Unicode の処理をかますのが正解な気がしてきました。

突破したのは一昨日？ですが、一応メモと。

【進捗】

• 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);
  }
}