How can we handle undcomented shell functionsAW, that MS declared now (WSTR version only)

[Detlef Riekenberg]

Hi

There are a some undocumented Functions in shell32, which have
one entrypoint that use STR in win9x, but WSTR in NT:

- dlls/shell32/undocshell.h
- http://www.geocities.com/SiliconValley/4942/paths.html

Some of them are now declared without A/W suffix
(include/shobj.h from SDK 2003), but since win9x 
is no longer supported by MS, it's only for the Wide version.

Examples: PathProcessCommend, PathResolve, PathQualify

Question for include/shlobj.h:
What is the correct way to declare such functions?

In undocshell.h, we use functionAW with LPVOID for the first two,
but for PathQualify, we use:
//
BOOL WINAPI PathQualifyA(LPCSTR path);
BOOL WINAPI PathQualifyW(LPCWSTR path);
#define PathQualify WINELIB_NAME_AW(PathQualify)
BOOL  WINAPI PathQualifyAW(LPCVOID path);
//

And PathResolve in exported by name (see shell32.spec)

#############################################################

Next question for shell32.spec:
Are we fixed to "ptr" for such functions?
("str", "wstr" and "long" are all used and need to be fixed)

Is it possible / useful to add support for "awstr" (or a similar name)?
What about support for UNICODE-Strings ("ustr")?

How can we handle undcomented shell functionsAW, that MS declared now (WSTR version only)

[Alexandre Julliard]

Detlef Riekenberg  writes:
> Examples: PathProcessCommend, PathResolve, PathQualify
>
> Question for include/shlobj.h:
> What is the correct way to declare such functions?

They should be declared exactly like they are on Windows. The AW
function is internal to shell32.
> Next question for shell32.spec:
> Are we fixed to "ptr" for such functions?
> ("str", "wstr" and "long" are all used and need to be fixed)

They should be ptr.
> Is it possible / useful to add support for "awstr" (or a similar name)?
> What about support for UNICODE-Strings ("ustr")?

I don't think it's worth the trouble.