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
unixfs.
> 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.
Bye,
--
Michael Jung
mjung at iss.tu-darmstadt.de
More information about the wine-devel
mailing list