UnixFolder_IShellFOlder used instead of SHELL32_IShellFolder

Michael Jung mjung at iss.tu-darmstadt.de
Tue Nov 1 15:55:15 CST 2005

Hi Vitaly,

On Tuesday 01 November 2005 19:35, Vitaliy Margolen wrote:
> For some reason now UnixFolder_IShellFOlder is used in some cases where
> SHELL32_IShellFolder should of been used instead.

That's how it is supposed to work. If unixfs is registered in the namespace at 
the desktop, the desktop shell folder forwards to CLSID_UnixDosFolder instead 
of CLSID_ShellFSFolder in it's ParseDisplayName method. The corresponding 
code is in shfldr_desktop at line 189. Conceptually, that should'nt be a 
problem though, since CLSID_UnixDosFolder objects should be compatible to 
CLSID_ShellFSFolder. Do you have a concret problem with that?

> If you look at the sheel32/test/shlfolder.c test_EnumObjects_and_CompareIDs
> it should use the real IShellFolder. But for some reason it's being
> replaced by UnixFolder_IShellFOlder. Any ideas why this is happening? I
> thought that it should be it's own shell name space (different ID)?

Let's say c: maps to /home/mjung/.wine/drive_c and an application passes "C:
\windows" to the DesktopFolder's ParseDisplayName method. If unixfs is 
enabled, shfldr_desktop will forward to UnixFolder::ParseDisplayName, which 
will create a SHITEMIDLIST like home::mjung::.wine::drive_c::windows. This 
means you will see the unix path in the file dialog. If you call 
GetDisplayName on the corresponding folder object, you will get "C:\windows" 
again. In a nutshell, unixfs' SHITEMIDLISTs are based on fully qualified unix 
paths, while the display names (and thus the usual "string'ified" paths) are 
drive based DOS paths. That's why you can use unix paths in file dialogs of 
applications, which weren't meant to work with unix paths. Does this 
explanation make sense? I guess I'll have to write up some documentation on 

> This could be a main cause for all the problems people having with browsing
> files. 

I wasn't aware that people do have a lot of problems with browsing files. Did 
I miss something on wine-devel (or wine-user), or was this discussed on IRC? 
Can you give me some pointers?

> As now you can "escape" to the root (/) dir. That should not be 
> possible for windows programs!

Actually, you can't. OpenFile, CreateFile and the like are still based on DOS 
paths. It's only deep inside shell32, that the unix api's are called to 
browse the unix filesystem. Everything that goes in and out are DOS paths.

Michael Jung
mjung at iss.tu-darmstadt.de

More information about the wine-devel mailing list