<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive
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
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
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.
--- Mike Hearn <mh(a)codeweavers.com> 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
Steven Edwards wrote:
--- Mike Hearn <mh(a)codeweavers.com> 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 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
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
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 -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Mike Hearn <mh(a)codeweavers.com> 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... -- Alexandre Julliard julliard(a)winehq.org
Hi, --- Alexandre Julliard <julliard(a)winehq.org> 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
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
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
Robert van Herk <robert(a)robertvanherk.nl> 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. -- Alexandre Julliard julliard(a)winehq.org
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
Mike Hearn <mh(a)codeweavers.com> 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. -- Alexandre Julliard julliard(a)winehq.org
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.
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.
participants (8)
-
Alexandre Julliard -
Arjen Nienhuis -
Kuba Ober -
Mike Hearn -
Mike McCormack -
Robert van Herk -
Shachar Shemesh -
Steven Edwards