No subject

You should add comdlg32 to DELAYIMPORTS, not IMPORTS, since it will be
rarely needed and setupapi is used a lot. DELAYIMPORTS is like
IMPORTS, but comdlg32 won't be loaded until you call a function that
it provides.

You should handle the A/W split by invoking the W version first and
then writing the A version as a wrapper around that (converting
arguments to unicode and any unicode results back to ansi). There's no
need to duplicate so much code.

You're using some lstr* functions instead of str* functions. The l
functions are like the normal functions except that they catch invalid
page faults. Unless you do not trust the pointers you are using AND
you know that windows doesn't crash when they are invalid, you
probably want to use the normal str* functions.

I think it's safe to assume that if you use GetModuleHandle from
within the module whose handle you ask for, it will succeed. In fact,
I think you can simply store the module handle in a global variable
when it's first loaded and use that global variable later on. (Someone
correct me if I'm wrong.)

Standard practice is to write tests mostly on the A version so that
they can run on Windows 9x. MSDN claims the function is not available
on Windows 9x; I guess it doesn't matter if that's true.

You've, uh, done something weird with the whitespace around
SPDRP_MAXIMUM_PROPERTY in setupapi.h. My text editor displays that
line broken in the middle, but the line numbers indicate it's one
line.

I think this is big and new enough to warrant a new source file,
perhaps a dialogs.c. (are there other dialogs in setupapi that need to
be implemented?)

I'm curious what happens if you tell if you're looking for a file on
C: that you know exists. If it doesn't bring up a dialog, that might
allow you to create a few tests that succeed.

> it lacks LOTS of details though, i just implemented the juice of it and some simple details.
This is EXACTLY what you should do. In fact, you may want to split
some of the current details out into later patches.

Vincent Povirk