Problems unveiled by the last version.c patch

[Paul Vriens]

Hi Dmitry,

> <pvriens at xs4all.nl> wrote:
>
>> trace:shell:SHELL_GetPathFromIDListA -- F:\temp, 0x00000000
> ...
>> trace:shell:SHGetPathFromIDListW -- L"F:\\temp", 0x00000000
>>
>> The main difference (apart from the A/W) is that SHGetPathFromIDListW
>> returns an extra backslash compared to the A-counterpart.
>
> If you mean a double backslash in the 2nd line of the above quote
> then it's just the escaping which debugtsr_w() performs.
>
> --
> Dmitry.
>
>

I think the problem lies in the fact the some of the procedures use
Unicode depending on the version and some don't care (or use some
default). Going to the traces I can see:

Call shell32.SHBrowseForFolder(3de5f760) ret=01003c8d
... (always calls SHBrowseForFolderA)
trace:shell:SHBrowseForFolderA
Ret  shell32.SHBrowseForFolder() retval=77e30fc0 ret=01003c8d
...
Call shell32.SHGetPathFromIDList(77e30fc0,0100b720) ret=01003c99
trace:shell:SHGetPathFromIDListAW
... (checking the version)
trace:shell:SHGetPathFromIDListW
...
Ret  shell32.SHGetPathFromIDList() retval=00000001 ret=01003c99
...
Call kernel32.lstrcpyA(0100a360,0100b720 "F") ret=01003ca9

So you see, we are mixing A and W now:
- SHBrowseForFolderA
- SHGetPathFromIDListW
- lstrcpyA

In this case does it mean we (I ?) have to implement SHBrowseForFolderAW
or is that the wrong path (as many calls don't do this and all of them
have to be checked/corrected)?

Cheers,

Paul.