プログラミング：Win32

東京大学（略）プログラム

αετος / aetos — Fri, 23 Jan 2009 14:05:00 GMT

検索するとよく引っかかる。
結構貴重な資料が公開されているように思う。

連載：メッセージリソース(2)

αετος — Mon, 29 Sep 2008 12:39:00 GMT

ちょっと間が空いてしまいましたが、連載第２回です。
今回は、前回作ったメッセージリソースを使うコードを紹介します。
前回までで、以下のようなプロジェクトができているはずです。

これに、ソースファイルを追加しましょう。
ファイル名は MsgRes.cpp とでもしておきます。

で、いきなりですが中身を公開します。

#include <windows.h>
#include <stdio.h>
#include <locale.h>
#include <tchar.h>

#include "MsgRes.h"

int _tmain()
{
	setlocale( LC_CTYPE, "japanese" );

	LPTSTR msg = NULL;
	DWORD result = FormatMessage(
		FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_IGNORE_INSERTS,
		NULL, MSGID_SAMPLE_0001, MAKELANGID( LANG_JAPANESE, SUBLANG_DEFAULT ),
		reinterpret_cast< LPTSTR >( &msg ), 0, NULL );

	if( result != 0 )
	{
		_putts( msg );
		LocalFree( msg );
	}

	setlocale( LC_CTYPE, "english" );

	result = FormatMessage(
		FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_IGNORE_INSERTS,
		NULL, MSGID_SAMPLE_0001, MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT ),
		reinterpret_cast< LPTSTR >( &msg ), 0, NULL );

	if( result != 0 )
	{
		_putts( msg );
		LocalFree( msg );
	}

	return 0;
}

はい。みんな大好き FormatMessage です。
GetLastError が返すエラーコードを文字列化するのにしか使ったことがない方も少なくないと思います。
今回は、第一引数に FORMAT_MESSAGE_FROM_HMODULE を指定し、第二引数に NULL を指定しています。
この場合、呼び出し側プロセスの EXE モジュールのハンドルを指定したのと同じことになります。

MSGID_SAMPLE_0001 は、前回 MsgRes.mc で定義し、メッセージコンパイラによって MsgRes.h に書かれているメッセージ識別子です。
続いて言語識別子を指定しています。これは MsgRes.mc の LanguageNames で指定した値です。
言語識別子を変えることで、同じメッセージ識別子でも違うメッセージが取得できているのが分かると思います。

本題は以上です。以下、ちょっとしたオマケ。

メッセージコンパイラが生成した MsgRes.rc を開いてみると、以下のような、なんともそっけないコードになっています。

LANGUAGE 0x11,0x1
1 11 "MSG_JA.bin"
LANGUAGE 0x9,0x1
1 11 "MSG_EN.bin"

これでは何だかわからん！　という方のために、もう少し読みやすく書き換えてみます。
ただし、このファイルはもう一度メッセージコンパイラを実行すれば上書きされてしまうので、別のリソースファイルを作りましょう。
MsgRes.rc を一旦プロジェクトから除外し、新しいリソーススクリプトを MsgRes2.rc とでも名づけて作成しましょう。
そうしたら、リソースビューで MsgRes2.rc を右クリックして「リソースファイルのインクルード」を選択します。

出てきたダイアログに、以下のように入力しましょう。

LANGUAGE LANG_JAPANESE, SUBLANG_DEFAULT
1 MESSAGETABLE "MSG_JA.bin"

LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
1 MESSAGETABLE "MSG_EN.bin"

これで、言語も、メッセージリソースだということもわかりやすくなりますね。

ただし、リソースコンパイラは MESSAGETABLE というキーワードを理解しますが、Visual C++ のリソースエディタは理解しません。
というかそれ以前に、このダイアログで入力した内容は、リソースビューに表示されません。
このダイアログを使わずに、MsgRes2.rc を直接書き換えても、リソースの種類は "11" と表示されるだけです。ちょっとさみしいですね。

次回は、挿入シーケンスの使い方と、エラーコードに対するメッセージを定義する方法を解説します。

連載：メッセージリソース(1)

αετος — Fri, 19 Sep 2008 16:50:00 GMT

何回か、メッセージリソースというものを取り上げます。
メッセージリソースとは、アイコンやバージョン情報と同様、exe ファイルや dll ファイルに持たせることができるリソースの一種ですが、Visual Studio のリソースエディタで作成できないため、あまり知られていないものではないかと思われます。

メッセージリソースを作成するためには、まず、そのソースとなるメッセージ定義ファイルを書きます。
これを、Windows SDK に付属しているメッセージコンパイラ（mc.exe）でコンパイルしてバイナリ形式に変換し、それをリソースに埋め込みます。
なお、Visual C++ 2008 Express には、メッセージコンパイラが付属していませんので、別途 Windows SDK をインストールする必要があります。

メッセージ定義ファイルの書き方や、メッセージコンパイラの使い方は、MSDN Library の Message Compiler のところに書かれています。
MSDN では、イベントログ関係のページとして書かれているところからもわかるように、メッセージリソースの主な用途はイベントログです。
そのため、この連載でもイベントログについてとりあげますが、それは連載の終盤になる予定です。
その前に、次回以降で、イベントログ以外の使い方を紹介します。

では、早速作ってみましょう。

まず、Visual Studio を立ち上げ、VC++ で新しい Win32 コンソールアプリケーションプロジェクトを作成します。
ウィザードでは「空のプロジェクト」を選びましょう。

次に、ソリューションエクスプローラのリソースフォルダに、メッセージ定義ファイルを追加しましょう。
カテゴリには出てこないので、とりあえずテキストファイルを選んでおきます。
拡張子は何でもいいですが、ここでは .mc としました。

そのファイルを開いて、以下のような内容を書き込みます（VC++ 上では色分けはされません）。

;// コメントはヘッダー ファイルに反映されるので、C++ 形式で書く必要があります。

MessageIdTypedef=DWORD

LanguageNames=(
	English=0x0409:MSG_EN
	Japanese=0x0411:MSG_JA
)

MessageId=0x0001
Severity=Informational
Facility=Application
SymbolicName=MSGID_SAMPLE_0001
Language=English
This is Message Resource Sample.
.
Language=Japanese
メッセージ リソースのサンプルです。
.

次に、ファイルのプロパティを開いて、ビルド方法を設定します。
Visual Studio はメッセージリソースをビルドする方法を知らないので、自分でコンパイラの設定をしてやる必要があります。
とりあえず、以下のようにすればよいでしょう。

設定したら、ソリューションエクスプローラでこのファイルを右クリックして「コンパイル」を選びます。
終わったら、同じフォルダに、MsgRes.h、MsgRes.rc、MSG_EN.bin、MSG_JA.bin の4つのファイルができていることを確認してください。
これらのファイルを、プロジェクトに追加しておきましょう。MsgRes.h はヘッダーファイルフォルダに、それ以外はリソースファイルフォルダでいいでしょう。

それでは、先ほど記述したファイルの内容を解説します。

コメント

.mc ファイルに書いたコメントは、ヘッダーファイルに反映されます。
MsgRes.h を開いてみると、一番上に、.mc ファイルに書いたコメントがあります。
そのため、.mc ファイル中でも、それを意識してコメントを書く必要があります。

MessageIdTypedef

MsgRes.h を見ると、

#define MSGID_SAMPLE_0001 ((DWORD)0x40000001L)

という記述があるかと思います。
この (DWORD) が、MessageIdTypedef=DWORD で指定したものです。
MessageIdTypedef=WORD とすれば、生成されるコードは

#define MSGID_SAMPLE_0001 ((WORD)0x40000001L)

になります。

LanguageNames

言語名を定義し、言語識別子とファイル名を関連付けます。
言語名は、その後のメッセージ定義で使用しています。
ファイル名は、メッセージコンパイラが生成する .bin ファイルの名前になります。

MessageId

メッセージの識別子です。
Severity と Facility を上位ワード、この識別子を下位ワードとしたものが、実際のメッセージ識別子になります。
その値は、MsgRes.h に書き込まれます。
以降、メッセージ識別子に関する話が出てきますが、MsgRes.h に構造が書かれているので、それを見ながらだとわかりやすいと思います。

Severity

メッセージの重大さです。
この値は、メッセージ識別子の上位 2 ビットに反映されます。
標準では、成功=0、情報=1、警告=2、エラー=3 となっていますが、SeverityNames ステートメントを使うことで、自分で名前を定義することもできます（2 ビットしかないため、値は 0 ～ 3 しか使えません）。
今回は、メッセージ識別子の上位 2 ビットが 01 なので、0x4000～になっているわけです。

Facility

メッセージのファシリティ値（日本語ではどう言えばいいんでしょう？）を指定します。
この値は、メッセージ識別子のビット 16 ～ 27 に書き込まれます。
標準では、Application=0 のようです。他に何が定義されているのかはわかりません（MSDN の記述は間違えているようです）。
FacilityNames ステートメントを使うことで、自分で名前を定義することができます。こちらは、任意の 12 ビットの値を使えます（たぶん）。

SymbolicName

MsgRes.h に定義される値の名前です。

Language

LanguageNames で定義した言語名です。

メッセージ本体

メッセージの本体を記述します。
最後に、ピリオドだけの行を置くと、メッセージ本体の終端を意味します（ピリオドはメッセージ本体に含まれません）。
複数行書くことも可能です。

次回は、このメッセージを使う方法です。

WTL 日本語アプリケーションウィザード

シャノン — Tue, 09 Sep 2008 00:35:00 GMT

UsefullCode.net で配布されているものをベースに、最新の build 7161 への対応ほか、ちょこちょこ改造したもの。
よければ使って＆おかしなところがあったら突っ込んで。

http://cid-e324cfc6fe7b549e.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/wtl8.rar

NTネイティブパス名をMS-DOSパス名に変換するには？

シャノン — Tue, 05 Aug 2008 13:15:00 GMT

本投稿は備忘録であり、ご回答は NTネイティブパス名をMS-DOSパス名に変換するには？で募っています。
マルチポストとなるのを避けるため、こちらには技術的な内容をご回答されませんよう、お願いいたします。

以下本文。

NT パス名、例えば \Device\HarddiskVolume1\... を C:\... に変換するにはどうすればよいのだろう？

ローカルドライブ下にあるパスについては、GetLogicalDriveStrings でドライブ名の一覧を取得し、QueryDosDevice でドライブ名を NT デバイス形式に変換し、前方一致で確認すればできそう。
が、ネットワークドライブや、ドライブレターが割り当てられていない UNC パスについてはどうすれば？

ローカルドライブの場合、例えば C: について QueryDosDevice で問い合わせれば \Device\HarddiskVolume1 という文字列のみが返ってくるため、前方一致で判別できる。
しかし、例えば、N: が \\Server\Path にマップされている場合、ネットワークドライブ内にあるファイルの NT パスは \Device\LanmanRedirector\Server\Path だが、N: に対して QueryDosDevice を実行すると \Device\LanmanRedirector\;N:謎の数字 \Server\Path のような文字列が返ってきてしまい、前方一致できない。
また、QueryDosDevice に UNC を渡しても、対応する NT パスは取得できない。
NT パスが \Device\LanmanRedirector\Server\Path となっていれば、それは \\Server\Path を指すのだと解釈してしまうのも、ドライバか何かの実装が異なれば、 LanmanRedirector 以外の名前がありそうで怖い。

RtlNtPathNameToDosPathName という関数もあるが、Undocumented なので、できれば使いたくない。

マウントポイント等の場合にどうなるかは要調査。

追試、情報求む

シャノン — Fri, 25 Jul 2008 13:44:00 GMT

Windows API の GetDiskFreeSpaceEx について MSDN で調べると、 If per-user quotas are being used, this value may be less than the total number of free bytes on a disk. とあることから、この関数はディスククォータに対応していると考えられます。
しかし、Windows 2003 R2 から導入された File Server Resource Manager を利用して設定したクォータによって制限された容量は、この関数では取得できない（GetDiskFreeSpaceEx は FSRM に対応していない）という情報を耳にしました。

当方、2003 R2 または 2008 の環境がないため、試すことができません。
どなたか、この情報は本当なのか、もし本当であれば、それは仕様として Microsoft からドキュメント化されているか、また、回避策はあるのか等、ご存知でしたら教えてください。

MSDN には FSRM の API がドキュメント化されていますが、The FSRM API is available starting with Windows Server 2008. と書かれています。これは本当なのでしょうか？ 2003 R2 の FSRM の情報を取得する API は無いということでしょうか？

また、このような透過的でないクォータサービスが存在しうるということは、第２、第３の FSRM（Microsoft 製でないものも含む）があり得るということですので、由々しき事態だと思います。
もし本当ならば、これは Microsoft に改善してもらわねばならないと思うのですが、そういったフィードバックはどこに提出すればよいのでしょうか？

翻訳版でないかなー

シャノン — Fri, 18 Jul 2008 13:24:00 GMT

Windows Internals 5th Edition
「インサイド Windows」の第5版。

Windows Via C/C++
たぶん「Advanced Windows」の第5版。

Visual BasicユーザーのためのWindowsプログラミング入門

シャノン — Fri, 06 Jun 2008 09:34:00 GMT

Visual BasicユーザーのためのWindowsプログラミング入門

電脳書房で見つけた古雑誌。思わずぽちっと購入。

これはですね、タイトルに補足を入れるならば、「Visual Basic（6.0）ユーザーのためのWindows（API）プログラミング入門」です。
冒頭から、「言語としては VB6 を使いつつ、VB6 のオブジェクトや関数は一切使わない Windows プログラム」が出てきます。もちろん、RegisterClassEx に始まり、CreateWindowEx やら GetMessage やらが出てくるあれです。
ただひとつ、Command 関数だけは使われていたので、自分で GetCommandLine 関数に直したりしましたけど。

俺が始めて「Windowsプログラミング」をやった記念すべき一冊です。

リンクいろいろ

シャノン — Tue, 27 May 2008 16:09:00 GMT

ハードリンク
リパースポイント
シンボリックリンク
ジャンクション
マウントポイント
subst

どう違うのー？

VC++での、リンカオプションの自動設定

シャノン — Mon, 24 Mar 2008 16:56:00 GMT

例えば、#define _WIN32_WINNT 0x0600 とします。
これは、Windows Vista 以降で実装された機能を使うことの宣言であって、できたプログラムは Vista 以降でしか動かなくなります。
この宣言をしたにもかかわらず、Vista 以降固有の機能を使っていない場合、動くこともありますが、動かないものと思っておくべきです。

で、WinMain あたりで VerifyVersionInfo で Vista 以降かどうか判定して蹴るという方法もあるのですが、もっと楽な手もあります。
それは、リンカオプションの /SUBSYSTEM を利用するというものです。
例えばこれを /SUBSYSTEM:WINDOWS,6.0 とすると、Windows 5.x では、実行しようとしたときに「有効な Win32 イメージではありません」と怒られます。

んで、ちょっと前に挑戦して、うまく行かなかったこと。
WINVER や _WIN32_WINNT シンボルの値に応じて、リンカオプションを自動的に指定できないものかと思うわけです。
コードからリンカオプションを指定するには、#pragma comment( linker, "/SUBSYSTEM:WINDOWS,6.0" ) とやればいいはずです。
この "6.0" の部分を、プリプロセッサシンボルから自動生成できないかなーというわけなのですが。

どなたかご存知ありません？

プログラミング：Win32

東京大学（略）プログラム

連載：メッセージ リソース(2)

連載：メッセージ リソース(1)

WTL 日本語 アプリケーション ウィザード

NTネイティブパス名をMS-DOSパス名に変換するには？

追試、情報求む

翻訳版でないかなー

Visual BasicユーザーのためのWindowsプログラミング入門

リンクいろいろ

VC++での、リンカオプションの自動設定

連載：メッセージリソース(2)

連載：メッセージリソース(1)

WTL 日本語アプリケーションウィザード