windows file dialogs with unix file path

Michael Jung mjung at iss.tu-darmstadt.de
Thu Apr 21 02:53:57 CDT 2005


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
>
> 	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.

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,
-- 
Michael Jung
mjung at iss.tu-darmstadt.de



More information about the wine-devel mailing list