プログラミング：Win32

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 ファイバ

シャノン — Tue, 11 Mar 2008 17:32:00 GMT

空気なんて読みませんよ。

Windows APIで、トップレベルウィンドウを列挙するサンプルコード。

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

static BOOL CALLBACK EnumWindowProc( HWND hWnd, LPARAM lParam )
{
	if( IsWindowVisible( hWnd ) )
	{
		TCHAR szTitle[ 256 ];
		GetWindowText( hWnd, szTitle, 256 );
		_tprintf( _T( "0x%08.8X, %s\n" ), hWnd, szTitle );
	}

	return TRUE;
}

static void EnumWindows1()
{
	EnumWindows( &EnumWindowProc, 0 );
}

int main()
{
	_tsetlocale( LC_ALL, _T( "japanese" ) );

	EnumWindows1();
	_putts( _T( "" ) );

	_putts( _T( "何かキーを押すと終了します。" ) );
	getchar();

	return 0;
}

非表示でないトップレベルウィンドウを列挙して、ウィンドウハンドル値とタイトルを表示します。
これといって特筆すべきことはありません。

これを、「列挙関数を一度呼ぶごとにウィンドウハンドルを１つ返す」という形にしたいと思います。

まず、ヘッダファイル。ファイル名はEnumWnd.hとします。

#pragma once

typedef struct ENUMWND * HENUMWND;

HENUMWND BeginEnumWindows();
HWND EnumWindow( HENUMWND hEnumWnd );
void EndEnumWindows( HENUMWND hEnumWnd );

ハンドル型と、列挙の開始関数、ウィンドウを１つ列挙する関数、後始末関数を宣言します。

続いて、ソース本体。ファイル名はEnumWnd.cppとしましょう。
制御が移っていく順番を書いてみました。「数字→」から「→数字」へジャンプします。
実行される様子を追いたい場合は、SwitchToFiberの前後にブレークポイントを置いてステップ実行するとよいでしょう。

#include <windows.h>
#include "EnumWnd.h"

struct ENUMWND
{
	LPVOID pMainFiber;
	LPVOID pEnumeratorFiber;
	HWND hwndCurrent;
};

static BOOL CALLBACK EnumWindowProc( HWND hWnd, LPARAM lParam )
{
	// →２
	HENUMWND hEnumWnd = ( HENUMWND )lParam;
	hEnumWnd->hwndCurrent = hWnd;
	SwitchToFiber( hEnumWnd->pMainFiber ); // →３

	// →４
	return TRUE; // 列挙中は２→、最後のウィンドウだったら５→
}

static void CALLBACK FiberProc( LPVOID pvParam )
{
	// →１
	HENUMWND hEnumWnd = ( HENUMWND )pvParam;
	EnumWindows( &EnumWindowProc, ( LPARAM )hEnumWnd ); // ２→

	// →５
	for( ; ; )
	{
		hEnumWnd->hwndCurrent = NULL;
		SwitchToFiber( hEnumWnd->pMainFiber ); // ３→
	}
}

HENUMWND BeginEnumWindows()
{
	HENUMWND hEnumWnd = new ENUMWND;
	hEnumWnd->pMainFiber = ConvertThreadToFiber( NULL );
	hEnumWnd->pEnumeratorFiber = CreateFiber( 0, &FiberProc, hEnumWnd );
	hEnumWnd->hwndCurrent = NULL;

	return hEnumWnd;
}

HWND EnumWindow( HENUMWND hEnumWnd )
{
	SwitchToFiber( hEnumWnd->pEnumeratorFiber ); // 初回は１→、２回目以降は４→

	// →３
	return hEnumWnd->hwndCurrent;
}

void EndEnumWindows( HENUMWND hEnumWnd )
{
	DeleteFiber( hEnumWnd->pEnumeratorFiber );
	ConvertFiberToThread();
	delete hEnumWnd;
}

ついでに、呼び出し側のコード。

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

static void EnumWindows2()
{
	HENUMWND hEnumWnd = BeginEnumWindows();

	HWND hWnd = EnumWindow( hEnumWnd );
	while( hWnd != NULL )
	{
		if( IsWindowVisible( hWnd ) )
		{
			TCHAR szTitle[ 256 ];
			GetWindowText( hWnd, szTitle, 256 );
			_tprintf( _T( "0x%08.8X, %s\n" ), hWnd, szTitle );
		}

		hWnd = EnumWindow( hEnumWnd );
	}

	EndEnumWindows( hEnumWnd );
}

int main()
{
	_tsetlocale( LC_ALL, _T( "japanese" ) );

	EnumWindows2();
	_putts( _T( "" ) );

	_putts( _T( "何かキーを押すと終了します。" ) );
	getchar();

	return 0;
}

BeginEnumWindowsは、データを収める構造体を確保して、中身を初期化します。
まず、呼び出し側スレッドをファイバ化します（ConvertThreadToFiber）。
次に、新しいファイバを作ります（CreateFiber）。
ファイバはスレッドと違い、作っただけでは実行を開始しません。FiberProcはまだ眠りについたまま、制御は呼び出し側（EnumWindows2）へ戻ります。

EnumWindows2からEnumWindowが呼ばれます。
この中ではSwitchToFiberが呼ばれています。引数はBeginEnumWindowsで作った、FiberProcを指し示すファイバポインタなので、ここで初めて、FiberProc（１）が実行され始めます。
と同時に、EnumWindowの実行は一旦中断されます。

FiberProcの中ではEnumWindows（EnumWindowではありません）が呼ばれ、制御はEnumWindowsProc（２）に移ります。
ここは何の変哲もありません。

EnumWindowsProcの中で、１つウィンドウハンドルが取得できたので、呼び出し側に制御を返します。
BeginEnumWindows内でConvertThreadToFiberで作成したファイバを指定してSwitchToFiberを呼ぶことで、EnumWindowの中断していた箇所（３）に制御が戻り、同時に、EnumWindowProcの実行が一時中断されます。
EnumWindowから、呼び出し元であるEnumWindows2に戻り、非表示でなければ、ウィンドウの情報が表示されます。

再度EnumWindowが呼ばれ、SwitchToFiberが呼ばれると、EnumWindowProcの中断していた箇所（４）に制御が移ります。
ウィンドウの列挙が全て完了するまで、以上の繰り返しになります。

全てのウィンドウを列挙し終えると、FiberProc（５）に戻ってきます。
その後は、無限にループしているように見えますが、そうではありません。
ループ中のSwitchToFiberでEnumWindow（３）に戻り、呼び出し元のEnumWindows2では結果がNULLなのでループを中断します。
EndEnumWindowsで後始末をして、プログラムが終了します。

FiberProcの中で無限ループのようなコードを書いていた理由は、29行目をコメントアウトし（forブロック全体をコメントアウトしないように）、呼び出し元のEnumWindows2で、EnumWindowがNULLを返した後、EndEnumWindowsを呼ぶ前に、もう一度だけEnumWindowを呼んでみればわかります。

static void CALLBACK FiberProc( LPVOID pvParam )
{
	// →１
	HENUMWND hEnumWnd = ( HENUMWND )pvParam;
	EnumWindows( &EnumWindowProc, ( LPARAM )hEnumWnd ); // ２→

	// →５
	// for( ; ; )
	{
		hEnumWnd->hwndCurrent = NULL;
		SwitchToFiber( hEnumWnd->pMainFiber ); // ３→
	}
}

void EnumWindows2()
{
	HENUMWND hEnumWnd = BeginEnumWindows();

	HWND hWnd = EnumWindow( hEnumWnd );
	while( hWnd != NULL )
	{
		if( IsWindowVisible( hWnd ) )
		{
			TCHAR szTitle[ 256 ];
			GetWindowText( hWnd, szTitle, 256 );
			_tprintf( _T( "0x%08.8X, %s\n" ), hWnd, szTitle );
		}

		hWnd = EnumWindow( hEnumWnd );
	}

	// もう一度呼んでみる
	hWnd = EnumWindow( hEnumWnd );

	EndEnumWindows( hEnumWnd );
}

mainで、何かキーを押すまで終了を待機しているはずなのに、19行目のEnumWindowの呼び出しから戻ることなく、プログラムが終了してしまいます。

このプログラムには、ファイバは２つありますが、スレッドは１つしかありません。
スレッドが終了するには、ExitThreadを呼ぶか、スレッドプロシージャからreturnしますね。
さて、このプログラムのスレッドプロシージャはドコでしょうか？

FiberProcには、呼び出し元がありません。
EnumWindow内のSwitchToFiberから呼び出されているようにも見えますが、それは１回目だけです。
２回目以降は、いきなりFiberProc（から呼ばれているEnumWindowProc）の途中から始まります。

呼び出し元がないのですから、帰る先もありません。
おわかりでしょうか。
このプログラムには、mainの最後とFiberProcの最後、スレッドプロシージャの終了地点が２つあるのです。
どちらかからreturnすれば、スレッドは終了してしまいます。
だから、FiberProcからは決してreturnしないように、無限ループのようなfor文を書いているのです。
FiberProc自体には戻り値がないのも、returnすることがないからでしょう。

最後に余談。
このプログラムにはスレッドが１つしかありませんが、マルチスレッドとファイバの組み合わせも面白いものがあります。
CreateFiberで作ったファイバは、CreateFiberの呼び出し元のスレッドに関連付けられません。
CreateFiberを呼んだスレッドと、そのファイバに制御を移すためのSwitchToFiberを呼ぶスレッドは異なっていてもかまいません。
ファイバは、SwitchToFiberの呼び出し側のスレッドで実行されます。
そのため、１つのファイバを実行するスレッドを複数用意して切り替えることができます。
ただし、複数のスレッドから同時に１つのファイバにアクセスすることはできません。

循環参照するDLLのビルド

シャノン — Wed, 30 Jan 2008 15:54:00 GMT

循環参照なんてするな！　終わり。

…では怒られるので。

２つのDLL、Hoge.dllとPiyo.dllがあるとします。
Hoge.dllはPiyo.dllの関数を呼び、Piyo.dllはHoge.dllの関数を呼ぶ。
しかもどちらも暗黙リンクで、GetProcAddressはしたくないという困ったちゃんだとします。

想定に無理があるのは承知です。
そもそも循環参照した時点で無茶なので、その辺は目をつぶってください。

で、こういうビルド、実はできます。
Hoge.dllをビルドするときにPiyo.dllは必要ではなく、必要なのはPiyo.libであるというのがミソです。
要は、Piyo.dllとは別にPiyo.libだけ先にビルドできれば良いわけです。

というわけで、やってみましょう。

１：Piyo.libのビルド
Piyo.libのビルドに必要なのは、実はPiyo.defだけです。ソースコードすら要りません。
ビルドには、VC++に添付のlib.exeを使います。こんな感じ。

lib /DEF:Piyo.def /MACHINE:X86 /OUT:Piyo.lib

これで、カレントディレクトリにPiyo.libとPiyo.expができます。

２：Hoge.dllとHoge.libのビルド
こっちは普通にやればいいです。IDEからもできますが、コマンドラインでやってみましょう。

cl /c /FoHoge.obj Hoge.cpp
link /DEF:Hoge.def /DLL /IMPLIB:Hoge.lib /MACHINE:X86 /OUT:Hoge.dll Hoge.obj Piyo.lib

最後に Piyo.lib を付け加えています。
これで、Hoge.dll、Hoge.lib、Hoge.expができます。

３：Piyo.dllのビルド
Piyo.defの代わりにPiyo.expを使うのがポイントです。

cl /c /FoPiyo.obj Piyo.cpp
link /DLL /MACHINE:X86 /OUT:Piyo.dll Piyo.obj Hoge.lib Piyo.exp

晴れて循環参照がクリアできました。
ちなみに、エクスポートする関数には明示的に extern "C" をつける必要があるので注意してください。

なお、改めて言わなくてもわかってると思いますが、これは興味本位で調べたことであって、そもそもやるべきことではありません。

PEファイルの謎

シャノン — Sun, 27 Jan 2008 17:59:00 GMT

PEファイルについて調べてます。
んで、わからないことが数点。

その１：隠しリンカオプション
VC++ 2008のリンカオプションはMSDNに一覧があるが、ここに書かれていないオプションが少なくとも一つある。
/INTEGRITYCHECKというのがそれで、これを指定してリンクすると、PEヘッダのIMAGE_OPTIONAL_HEADER.DllCharacteristicsにIMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITYビットが含まれる。
が、このファイルがどういうわけか実行できない。
このフラグは何のためにあるのだろう？

その２：セクション属性
PEファイル中のセクションの属性は、IMAGE_SECTION_HEADER構造体に含まれる。
こいつのCharacteristicsメンバに含まれるフラグのなかに、意味がよくわからないものがある。
列挙すると、IMAGE_SCN_NO_DEFER_SPEC_EXC、IMAGE_SCN_LNK_NRELOC_OVFL、IMAGE_SCN_MEM_DISCARDABLE、IMAGE_SCN_MEM_NOT_CACHED、IMAGE_SCN_MEM_NOT_PAGEDの５つ。
どれも、ビットが立っているとどういう挙動をするのかがよくわからない。
最初の２つは、どうすればこのビットが立つのかもわからない。

ご存知の方がいらっしゃいましたら、教えてくださると幸いです。
なお、現在、x86とx64アーキテクチャ上での、いわゆるDLLとEXEのみを対象として調べており、他のアーキテクチャ用だとか、「カーネルモードドライバでしか縁のないフラグ」とかには興味がありません。
ので、上に挙げたようなものが、もしそうしたものであったら、詳細なしでも構いません。

Detours

シャノン — Sat, 12 Jan 2008 16:21:00 GMT

http://research.microsoft.com/sn/detours/

MS製のDLLインジェクションライブラリですか？

なんか面白そう。