<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

[Robert van Herk]

Hi,

I had some problems with my mail server, so I send in this patch again. 
If the previous one did arrive, please ignore this e-mail.

------------------------------------------------------------------------

Changes:

Added functionality to browse for a UNIX folder.
This is done by making two new funtions in dlls/shell32/brsfolder.c, namely
         wine_shell_browse_for_UNIX_directoryA
         wine_shell_browse_for_UNIX_directoryW
These functions are exported in shlobj.h.

The original code that allowed just for picking a Windows folder, was
split up.
It was to be found in brsfolder.c, but I split this in:
brsfolder.c
brsfolder.h
brsfolder_windows.c
brsfolder_windows.h
brsfolder_unix.c
brsfolder_unix.h
unixTools.c
unixTools.h,
Otherwise I found the code to be incomprehendible.

Furthermore, winecfg now uses the wine_shell_browse_for_UNIX_directoryA
to let the user pick a UNIX directory as root for his virtual drive
mappings.

Regards,
Robert van Herk

[Mike McCormack]

Robert van Herk wrote:
> Added functionality to browse for a UNIX folder.
> This is done by making two new funtions in dlls/shell32/brsfolder.c, namely
>         wine_shell_browse_for_UNIX_directoryA
>         wine_shell_browse_for_UNIX_directoryW
> These functions are exported in shlobj.h.

How about creating a new object class or interface to an existing object 
that exposes these interfaces?   That way you won't need to export any 
extra functions from shell32.

Mike

[Mike Hearn]

On Thu, 02 Dec 2004 15:19:27 +0900, Mike McCormack wrote:
> How about creating a new object class or interface to an existing object 
> that exposes these interfaces?   That way you won't need to export any 
> extra functions from shell32.

What's wrong with additional APIs? The browse folder API isn't COM based
anyway.

[Steven Edwards]

--- Mike Hearn  wrote:
> What's wrong with additional APIs? The browse folder API isn't COM based
> anyway.

It would be much better to use the API provided to create a namespace for the Unix filesystem. The
Control Panel and Network Neighborhood are good examples of this. Quite a few third party apps
create a virtual namespace for things like CVS so I don't see why we can't work in the existing
API to do this with the Unix fs.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

[Shachar Shemesh]

Steven Edwards wrote:
> --- Mike Hearn  wrote:
> > What's wrong with additional APIs? The browse folder API isn't COM based
> > anyway.
>
> It would be much better to use the API provided to create a namespace for the Unix filesystem. The
> Control Panel and Network Neighborhood are good examples of this. Quite a few third party apps
> create a virtual namespace for things like CVS so I don't see why we can't work in the existing
> API to do this with the Unix fs.
>
> Thanks
> Steven

It's been a LONG while since I messed with shell extensions. However, if 
my memory serves me right, you cannot pass virtual namespaces to 
"CreateFile" and friends. The only one who knows how to work with 
virtual namespaces is explorer.

That may not be much of a problem for the winecfg utility, but it's 
something to consider. Esp. being that we don't have a proper explorer 
(and none is planned for Wine that I know of, and ReactOs doesn't seem 
to need Posix filenames...)

Shachar

[Kuba Ober]

> > > What's wrong with additional APIs? The browse folder API isn't COM based
> > > anyway.
> >
> > It would be much better to use the API provided to create a namespace for
> > the Unix filesystem. The Control Panel and Network Neighborhood are good
> > examples of this. Quite a few third party apps create a virtual namespace
> > for things like CVS so I don't see why we can't work in the existing API
> > to do this with the Unix fs.
>
> It's been a LONG while since I messed with shell extensions. However, if
> my memory serves me right, you cannot pass virtual namespaces to
> "CreateFile" and friends. The only one who knows how to work with
> virtual namespaces is explorer.

I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type

edit \server\myhome\file.txt

And it opens it just fine.

Similarly, I can type

dir "\server\shared files"

I'm sure the DOS utilities just use long file name APIs and those "simply 
work". It should be the same for win32 apps.

This is networking stuff, though. Now as far as virtual namespaces go, I have 
no idea.

This involved some {guid} stuff in the name, but I sure doubt that CreateFile 
would dig that.

Maybe the unix stuff can go under \__unix\something ?

Cheers, Kuba

[Shachar Shemesh]

Kuba Ober wrote:
> I wouldn't be so sure about that. On win98, in "MS-DOS Prompt" I can type
>
> edit \server\myhome\file.txt
>
> And it opens it just fine.
>
> Similarly, I can type
>
> dir "\server\shared files"
>
> I'm sure the DOS utilities just use long file name APIs and those "simply 
> work". It should be the same for win32 apps.
>
> This is networking stuff, though. Now as far as virtual namespaces go, I have 
> no idea.

Try to go to the temporary internet files folder. Under explorer you see 
the shortcuts and their location. From dos (do "dir /a") you see just 
"Content.IE5" and "Desktop.ini" (which is what makes this folder a shell 
extension).
> This involved some {guid} stuff in the name, but I sure doubt that CreateFile 
> would dig that.

It won't. This is a *shell* extension.
> Maybe the unix stuff can go under \__unix\something ?

That's an interesting idea, actually. I actually don't think that we 
need to change anything in wine.

mkdir -p ~/.wine/dosdevices/unc/__unix
ln -s / ~/.wine/dosdevices/unc/__unix/root

That should give you a link to the files the way you want them. I'm too 
out of touch of the thread to figure out whether that solves our 
problems. If it does, we can just have wineprefix create create this 
link....
> Cheers, Kuba

Shachar

[Alexandre Julliard]

Mike Hearn  writes:
> On Thu, 02 Dec 2004 15:19:27 +0900, Mike McCormack wrote:
> > How about creating a new object class or interface to an existing object 
> > that exposes these interfaces?   That way you won't need to export any 
> > extra functions from shell32.
>
> What's wrong with additional APIs? The browse folder API isn't COM based
> anyway.

Well, there's an IShellFolder interface, and it should probably be
doing something with that. In any case it should definitely be more
integrated into the shell way of doing things, there shouldn't be a
need for a whole new set of APIs. This needs more thought IMO...

[Steven Edwards]

Hi,

--- Alexandre Julliard  wrote:
> Well, there's an IShellFolder interface, and it should probably be
> doing something with that. In any case it should definitely be more
> integrated into the shell way of doing things, there shouldn't be a
> need for a whole new set of APIs. This needs more thought IMO...

It can be done with only a little work as this guy even did it for Gmail <g>

http://www.viksoe.dk/code/gmail.htm

Rather than mapping the network filesystem as a shell folder we just need to the root of the Unix
fs. It can't be too hard I guess but I MSDN documentation on how to do it sucks and I can't find
any example code anywhere. I have been wanting to do this for a while for another project I am
working on where I need to create a shell view of the NT Object Manager.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

[Mike Hearn]

Alexandre Julliard wrote:
> Well, there's an IShellFolder interface, and it should probably be
> doing something with that. In any case it should definitely be more
> integrated into the shell way of doing things, there shouldn't be a
> need for a whole new set of APIs. This needs more thought IMO...

I have to disagree. I did try and write a shell extension once - even 
with the Delphi wizards helping with the boilerplate it was still some 
kind of Buddhist patience-enhancing mental excercise. In the end I 
trashed Explorer and had to reinstall Windows. There's a *lot* of work 
involved in writing one.

Anyway part of the reason for having the new APIs and restructuring the 
code is so we can have a non-standard UI. If it's implemented as a shell 
namespace extension the code will get a lot more complex, and the UI 
will still show the mapped drives alongside the new namespace which 
would be confusing to say the least.

thanks -mike

[Robert van Herk]

Mike Hearn wrote:
> Alexandre Julliard wrote:
> > Well, there's an IShellFolder interface, and it should probably be
> > doing something with that. In any case it should definitely be more
> > integrated into the shell way of doing things, there shouldn't be a
> > need for a whole new set of APIs. This needs more thought IMO...
>
> I have to disagree. I did try and write a shell extension once - even 
> with the Delphi wizards helping with the boilerplate it was still some 
> kind of Buddhist patience-enhancing mental excercise. In the end I 
> trashed Explorer and had to reinstall Windows. There's a *lot* of work 
> involved in writing one.

Alexandre,

Do you want me to continue on my patch, or are you saying that you feel 
that this is not the way to go, so that I would be wasting time with 
further polishing it anyway?

Robert

[Alexandre Julliard]

Robert van Herk  writes:
> Do you want me to continue on my patch, or are you saying that you
> feel that this is not the way to go, so that I would be wasting time
> with further polishing it anyway?

I'm afraid so yes. We really don't want to define new APIs for that,
it needs to be integrated properly with the existing code. Ideally a
Winelib app should be able to start using Unix dialogs without code
changes at all.

[Mike Hearn]

Alexandre Julliard wrote:
> I'm afraid so yes. We really don't want to define new APIs for that,
> it needs to be integrated properly with the existing code. Ideally a
> Winelib app should be able to start using Unix dialogs without code
> changes at all.

I don't see how to make this work. Silently replacing the win32 file 
pickers with native file pickers (or custom built-for-Unix Wine pickers) 
is possible in a few cases but when the app modifies the dialog with 
additional controls, we have to use the same UI design as native.

If we don't show Windows paths in the file pickers, I think this could 
be even more confusing that currently: programs will display eg 
Y:\MyDocument.doc in the titlebar but you will have chosen something 
under /home/xyz in the file picker.

If we did a shell extension to simply reflect the Unix heirarchy into 
the shell namespace, then the map drive dialog that motivated all this 
would display both currently mapped drives *and* the custom namespace 
extension, which would allow invalid selections (or at the very least, 
be quite confusing). It would also imply a large amount of code 
(IShellFolder implementations etc) to achieve the same effect that 
introducing a new function has.

We could reuse the rather nice GTK+ file pickers, which were recently 
redesigned and support things like bookmarks and pluggable devices, 
however that'd make winecfg (and therefore Wine) depend on GTK+ which in 
the past you objected to.

Could you describe in more detail how you want this to work please? 
Having a new API that reuses as much code as possible while still 
presenting a sensible UI seems like the most direct way forward.

thanks -mike

[Alexandre Julliard]

Mike Hearn  writes:
> I don't see how to make this work. Silently replacing the win32 file
> pickers with native file pickers (or custom built-for-Unix Wine
> pickers) is possible in a few cases but when the app modifies the
> dialog with additional controls, we have to use the same UI design as
> native.

Native file pickers are a completely different issue. What I'm talking
about is the standard shell browser thing, except showing Unix paths
instead of Windows drives, so that it's as transparent as possible to
the app. If the app wants a GTK file picker it has to be changed to
make GTK calls itself.
> If we don't show Windows paths in the file pickers, I think this could
> be even more confusing that currently: programs will display eg
> Y:\MyDocument.doc in the titlebar but you will have chosen something
> under /home/xyz in the file picker.

Yes of course, we need to fix more than just the shell file
picker. Some changes to the application code are probably unavoidable
too, but this should be kept to a minimum. But we need something like
that if we want to present Winelib as a credible environment for doing
Linux ports.
> Could you describe in more detail how you want this to work please?
> Having a new API that reuses as much code as possible while still
> presenting a sensible UI seems like the most direct way forward.

As you noted, the app can modify the dialog with additional controls
etc. which is why we have to use the same API. If you have to change
the whole file selection logic in the app code you might just as well
convert it to GTK or whatever.

<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

[Mike Hearn]

On Mon, 2004-12-06 at 17:07 +0100, Alexandre Julliard wrote:
> Native file pickers are a completely different issue. What I'm talking
> about is the standard shell browser thing, except showing Unix paths
> instead of Windows drives, so that it's as transparent as possible to
> the app. If the app wants a GTK file picker it has to be changed to
> make GTK calls itself.

Hmm. For the winecfg use case though we have to pass back a Unix path,
as by definition it might not be mapped to a Windows path. I suspect
most code that uses the browse folder API converts the PIDL straight
into a path that it can use with CreateFileEx and so on so it might
break stuff if we invented a new PIDL extension that contained a raw
Unix path.
> Yes of course, we need to fix more than just the shell file
> picker. Some changes to the application code are probably unavoidable
> too, but this should be kept to a minimum. But we need something like
> that if we want to present Winelib as a credible environment for doing
> Linux ports.

OK, I agree with that. Still there are stages of porting - simply having
it run like it would on regular Wine+EXE is the first stage, then
dressing it up to integrate better with Unix is the next, then porting
to native (well, free) APIs where possible would be the final stage.
> As you noted, the app can modify the dialog with additional controls
> etc. which is why we have to use the same API. If you have to change
> the whole file selection logic in the app code you might just as well
> convert it to GTK or whatever.

OK. I'm still not sure exactly what type of API extension is wanted
though. From looking at the relevant page on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/shellcc/platform/shell/reference/structures/browseinfo.asp

there could be a new Unix FS shell namespace plugin that is normally
hidden (how? i'm not sure the API lets you do that) which you can set as
the root and select from there, and then some way to convert a PIDL back
into a Unix path. Still, there is the problem that PIDLs are not usable
with the file APIs, so the sort of thing winecfg does will be rare. And
if you let the user pick any directory it may not be mapped.

So maybe when the user selects a path under the root, a drive could be
automatically mapped temporarily and the PIDL would be convertible to
the newly mapped drive using SHGetPathFromIDList.

Still, given that it'd normally be hidden (otherwise you get both the
windows and unix view of the FS at once in the file|open dialog box...)
this seems like an awful lot of work for the case of specifically
written apps like winecfg. I'm not sure it's worth trying to hide the
user from the fact that the program uses drive letters under the hood.

[Arjen Nienhuis]

> Hmm. For the winecfg use case though we have to pass back a Unix path,
> as by definition it might not be mapped to a Windows path. I suspect
> most code that uses the browse folder API converts the PIDL straight
> into a path that it can use with CreateFileEx and so on so it might
> break stuff if we invented a new PIDL extension that contained a raw
> Unix path.

No, you shouldn't convert a PIDL to path. Shell extensions create
temporary files on SHGetPathFromIDList. SHGetPathFromIDList is
implemented by shell extensions.

Maybe we can return names like \.\unix\usr\doc\ or whatever
devicepaths look like in windows.

You can hide shell extensions by not registering them as part of 'my
computer'. You can acess any them simply by creating a shortcut or a
directory named Dirname.{CLSID}. I don't know if you can access them
without creating a file.