Hi all,
Back in Nov 2004, there was a brief discussion about extending the Windows file dialogs to allow browsing the Unix file system. Does anyone know if this have been implemented yet? If not, any suggestions on how to implement it?
I am porting a windows application to linux using winelib, and using unix file path rather than window file path would be desired.
Thanks, Michael
Michael Lin wrote:
Back in Nov 2004, there was a brief discussion about extending the Windows file dialogs to allow browsing the Unix file system. Does anyone know if this have been implemented yet? If not, any suggestions on how to implement it?
Apparently something has been implemented by Michael Jung. I don't know how it works, but the code is in the cvs at:
http://cvs.winehq.org/cvsweb/wine/dlls/shell32/shfldr_unixfs.c
If you figure out how to make a file open dialog use that code, let me know.
Mike
On Wed, Apr 20, 2005 at 04:36:33PM +0900, Mike McCormack wrote:
Michael Lin wrote:
Back in Nov 2004, there was a brief discussion about extending the Windows file dialogs to allow browsing the Unix file system. Does anyone know if this have been implemented yet? If not, any suggestions on how to implement it?
Apparently something has been implemented by Michael Jung. I don't know how it works, but the code is in the cvs at:
http://cvs.winehq.org/cvsweb/wine/dlls/shell32/shfldr_unixfs.c
If you figure out how to make a file open dialog use that code, let me know.
winecfg already uses it in the Drives Tab.
Perhaps the file open dialog just needs to list the shell extension folder or so.
Ciao, Marcus
Hi,
On Wednesday 20 April 2005 09:36, Mike McCormack wrote:
If you figure out how to make a file open dialog use that code, let me know.
If you import the attached file with regedit the unix filesystem will appear in open/save file dialogs. Currently it only shows folders, no files, since this is all what is needed for winecfg's drive mapping property sheet. I'm still working on it (though I didn't have too much spare time lately) to extent it to files and make it more complete.
This all doesn't help a whole lot, however, if what you want is to access files via unix path names. The CreateFile etc. functions still do not know how to handle unix paths.
I thought about a per application property in the wine configuration, which states if an application can handle unix paths correctly. Wine's file functions would accept unix paths only if this property is set for the running application (winelib apps probably should be provided an api to tell wine programmatically that they know how to handle unix paths). The unix filesystem shell namespace extension (uuh?) would also appear only, if the property is set.
What do you think about this idea? What is your guess about how much effort this would take?
Bye,
On Thu, 21 Apr 2005 02:45, Michael Jung wrote:
This all doesn't help a whole lot, however, if what you want is to access files via unix path names. The CreateFile etc. functions still do not know how to handle unix paths.
The context here is that WINE is being used to make a Linux version of a Windows app (it used to use TWINE, but for obvious reasons has to move to WINE). Users would prefer to see UNIX path names throughout, so that's what needs to be displayed.
CreateFile and such are not a problem since the app won't use them - it goes directly to the native RTL for those functions, and to the Windows API for GUI stuff.
I thought about a per application property in the wine configuration, which states if an application can handle unix paths correctly. Wine's file functions would accept unix paths only if this property is set for the running application (winelib apps probably should be provided an api to tell wine programmatically that they know how to handle unix paths). The unix filesystem shell namespace extension (uuh?) would also appear only, if the property is set.
We toyed with this idea too, but that would break too much in WINE.
What do you think about this idea? What is your guess about how much effort this would take?
There are parts of Wine that call CreateFile on files they expect to find in the Windows file system, so you couldn't have it as a global flag.
There are other approaches I am considering
1. A special type of path, say '\.\unix/etc/passwd'. (which would be case sensitive).
2. WINE specific flags to APIs that take file names.
3. WINE specific calls (I'm thinking of something like WineCreateFileExA), with conditional code in the headers causing those to be used rather than the Windows ones. For example:
# ifdef WINE_NATIVE_PATHS # define WINELIB_NAME_AWU (func) WINELIB_NAME_AW(Wine##func) # else # define WINELIB_NAME_AWU(func) WINELIB_NAME_AW(func) # endif /* UNICODE */
HANDLE WINAPI CreateFileA(LPCSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,DWORD,DWORD,HANDLE); HANDLE WINAPI CreateFileW(LPCWSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,DWORD,DWORD,HANDLE); HANDLE WINAPI WineCreateFileA(LPCSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,DWORD,DWORD,HANDLE); HANDLE WINAPI WineCreateFileW(LPCWSTR,DWORD,DWORD,LPSECURITY_ATTRIBUTES,DWORD,DWORD,HANDLE); #define CreateFile WINELIB_NAME_AWU(CreateFile)
Now that I think of it, a combination of (2) and (3) would probably be in order. The Wine* APIs could convert the file name to the special path and pass it off to the standard Win32 APIs.
Hi Troy,
On Thursday 21 April 2005 01:34, Troy Rollo wrote:
On Thu, 21 Apr 2005 02:45, Michael Jung wrote:
This all doesn't help a whole lot, however, if what you want is to access files via unix path names. The CreateFile etc. functions still do not know how to handle unix paths.
...
CreateFile and such are not a problem since the app won't use them - it goes directly to the native RTL for those functions, and to the Windows API for GUI stuff.
I see, this makes sense.
I thought about a per application property in the wine configuration, which states if an application can handle unix paths correctly. Wine's file functions would accept unix paths only if this property is set for the running application (winelib apps probably should be provided an api to tell wine programmatically that they know how to handle unix paths). The unix filesystem shell namespace extension (uuh?) would also appear only, if the property is set.
We toyed with this idea too, but that would break too much in WINE.
I don't see how this could break anything:
- If the 'accept unix paths' property is not set for an application in wine's configuration, then wine would behave exactly as it does at the moment.
- Otherwise, we wouldn't disable Windows-like paths. We would just accept unix paths in addition. The functions in wine, which map wine paths to unix paths, would pass unix paths right through. The functions, which do unix to wine path conversion, would try to find a path starting from a wine drive letter and if none is found, would pass through the unix path. If there is code in wine, which has problems with this scheme, we can fix it. If there is code in an application, which has problems with this scheme, you wouldn't set the flag. If you are porting an application to winelib, you have the source and can fix it.
There are parts of Wine that call CreateFile on files they expect to find in the Windows file system, so you couldn't have it as a global flag.
See above.
There are other approaches I am considering
A special type of path, say '\.\unix/etc/passwd'. (which would be case sensitive).
WINE specific flags to APIs that take file names.
WINE specific calls (I'm thinking of something like WineCreateFileExA), with conditional code in the headers causing those to be used rather than the Windows ones.
As I understand it, we would like to stay as close as possible to the native Windows API. Thus I wouldn't like 2 and 3 too much. 1 seems to be like a good thing.
Bye,
On Thu, 21 Apr 2005 17:53, Michael Jung wrote:
The functions, which do unix to wine path conversion, would try to find a path starting from a wine drive letter and if none is found, would pass through the unix path.
I don't like this idea. Aside from the fact that it would slow everything down when using a UNIX path, you have case sensitivity issues (UNIX paths should be case sensitive, Windows paths should not).
An app should know at compile time the path is a UNIX path or a Windows one anyway. As this is something only a WineLib app should care about it seems to me that a deterministic compile time solution is better than an heuristic run time solution.
Hi Troy,
On Friday 22 April 2005 00:56, Troy Rollo wrote:
On Thu, 21 Apr 2005 17:53, Michael Jung wrote:
The functions, which do unix to wine path conversion, would try to find a path starting from a wine drive letter and if none is found, would pass through the unix path.
I don't like this idea. Aside from the fact that it would slow everything down when using a UNIX path, you have case sensitivity issues (UNIX paths should be case sensitive, Windows paths should not).
An app should know at compile time the path is a UNIX path or a Windows one anyway. As this is something only a WineLib app should care about it seems to me that a deterministic compile time solution is better than an heuristic run time solution.
That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.)
I think it would be cool if unix paths would be available to non WineLib apps also: 1.) There might be applications, which treat filenames as opaque objects and just happen to work with unix paths. 2.) People, who write Win32 programs might have wine in mind and build their programs to work with unix-paths, without going all the way to port their apps to WineLib (I do have a bunch of source code for Borland OWL based apps. They work fine with wine, but it doesn't seem easy to me to port these to gcc/WineLib.)
Bye, -- Michael Jung mjung@iss.tu-darmstadt.de
I've been following the unix path discussion, but I've kept quiet because I don't know enough about the filesystem layer in wine to comment. I probably don't know enough to implement this, but I'll be glad to help testing and fixing bugs.
Michael Jung wrote:
2.) People, who write Win32 programs might have wine in mind and build their programs to work with unix-paths, without going all the way to port their apps to WineLib (I do have a bunch of source code for Borland OWL based apps. They work fine with wine, but it doesn't seem easy to me to port these to gcc/WineLib.)
FWIW, we're using OWL with gcc and WineLib and I don't think it was overly difficult to get it working. The "OWL NExt" project has patches to get the stock OWL compiling with gcc on windows with mingw. We still had to make a fair number of changes to deal with gcc since we were using a newer version that was a bit more strict, OWL NExt might have taken care of this by now. We did have to make a few changes to work correctly with winelib, but it wasn't that bad.
In the past we've compiled OWL with Sun's Forte C++ compiler and HP's aCC compiler (both against MainWin), and we're now using it successfully with gcc on Linux, Solaris, HP (against WineLib), and native Windows. If you have code that you really want to get running with winelib, don't let OWL stop you. It might take a week or two of tweaking it, but it's a lot more portable than you might think.
Eric
Michael Jung mjung@iss.tu-darmstadt.de writes:
That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.)
That of course is the whole problem: you cannot reliably identify unix paths just by looking at the string.
What about writing Unix paths like an URL ? So you would have unix://path/to/file
Andrew
You can be the captain I will draw the chart Sailing into destiny Closer to the heart
Closer to the Heart by Rush (A Farewell to Kings, 1977)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alexandre Julliard wrote:
Michael Jung mjung@iss.tu-darmstadt.de writes:
That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.)
That of course is the whole problem: you cannot reliably identify unix paths just by looking at the string.
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote:
What about writing Unix paths like an URL ? So you would have unix://path/to/file
Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices...
Hmm, I feel like I've seen that before. Where???
Le ven 22/04/2005 à 20:09, Francois Gouget a écrit :
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote:
What about writing Unix paths like an URL ? So you would have unix://path/to/file
Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices...
People wanting access to unix paths in Wine want a "normal" unix path, ie /path/to/file instead of z:/path/to/file (or z:\path\to\file). The z: part is not unix, and that breaks the integration (use of a drive letter while on unix).
The other thing is if/when z: doesn't map to / anymore... how do you add it back from within winecfg?
Hmm, I feel like I've seen that before. Where???
No idea. Maybe you should submit a patch to Wine :)
Vincent
On Saturday 23 April 2005 02:22, Vincent Béron wrote:
The other thing is if/when z: doesn't map to / anymore... how do you add it back from within winecfg?
By clicking on the 'Browse' button on winecfg's "Drives" property sheet and selecting '/'. ;)
Besides aesthetics, I think a more fundamental problem with z: mapping to '/' is that wine paths are case insensitive.
Bye,
On Sat, 22 Apr 2005, Vincent Béron wrote:
Le ven 22/04/2005 à 20:09, Francois Gouget a écrit :
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote:
What about writing Unix paths like an URL ? So you would have unix://path/to/file
Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices...
People wanting access to unix paths in Wine want a "normal" unix path, ie /path/to/file instead of z:/path/to/file (or z:\path\to\file). The z: part is not unix, and that breaks the integration (use of a drive letter while on unix).
Sorry, my message was ironic but apparently the irony was missed. You say the 'z:' part is not Unix but neither is the 'unix:' part. 'unix:' may be easier to remember but it plays exactly the same role as 'z:' and is fundamentally no different. If users want to be able to just type a normal Unix path and find 'z:/...' too cumbersome, then I don't see how they could be happy to type 'unix:/...'.
Steven has a point in that 'unix:' could let us make this 'drive' case sensitive. Case sensitivity was selectable on a per-drive basis in the past and if we add it back for the 'unix:' drive then I don't see why other drives could not have the same option.
The other thing is if/when z: doesn't map to / anymore... how do you add it back from within winecfg?
The same way you create any other drive in winecfg today.
Finally, if a 'unix:' drive is implemented it should be optional because probably not everyone wants it. This means we get back to the problems of 'but what happens if the unix: drive is missing'. Well, the user is the one who wants it so then he should make sure it is enabled.
Hmm, I feel like I've seen that before. Where???
No idea. Maybe you should submit a patch to Wine :)
Obviously I was refering to the current drive implementation...
This is a Windows program and people want to use Unix paths. So the 'unix://' in front of the path is a protocol, not a path.
Like when you are browsing the internet using http, and wamt to download from an FTP server, you preface the address with ftp://
Andrew
You can be the captain I will draw the chart Sailing into destiny Closer to the heart
Closer to the Heart by Rush (A Farewell to Kings, 1977)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vincent Béron wrote:
Le ven 22/04/2005 à 20:09, Francois Gouget a écrit :
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote:
What about writing Unix paths like an URL ? So you would have unix://path/to/file
Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices...
People wanting access to unix paths in Wine want a "normal" unix path, ie /path/to/file instead of z:/path/to/file (or z:\path\to\file). The z: part is not unix, and that breaks the integration (use of a drive letter while on unix).
The other thing is if/when z: doesn't map to / anymore... how do you add it back from within winecfg?
Hmm, I feel like I've seen that before. Where???
No idea. Maybe you should submit a patch to Wine :)
Vincent
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote:
This is a Windows program and people want to use Unix paths. So the 'unix://' in front of the path is a protocol, not a path.
'This is a Windows program and people want to use Unix paths' and 'unix://xxx' is not a Unix path. So I don't see how it solves the problem any better than 'z:/xxx'.
Like when you are browsing the internet using http, and wamt to download from an FTP server, you preface the address with ftp://
But the same people who object to using 'z:/' would object to using 'file://'. So they would objcet to having to use 'unix://' or 'z:/' just the same.
I can understand people wanting to use standard plain Unix paths, it makes sense from an 'aesthetic' and integration point of vue. But IMHO having to use 'z:/' is really a minor issue as far as people are concerned. The one situation it can get more tricky or cumbersome is when you want Unix scripts to interoperate with Windows applications. But even in this situation, I suspect that most cases can be solved by having wrapper scripts that convert the paths between Windows and Unix forms using winepath.exe.
-
Alexandre Julliard -
Andrew Neil Ramage -
Eric Frias -
Francois Gouget -
Marcus Meissner -
Michael Jung -
Michael Lin -
Mike McCormack -
Troy Rollo -
Vincent Béron