Native unix style paths in wine common dialogs

Eric Frias efrias at
Tue Jan 4 11:38:52 CST 2005

Mike Hearn wrote:
 > On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote:
 >>Btw, if anyone is interested we also have another module which
 >>can be used to convert the windows-style drive letters returned
 >>by the common dialogs into unix-style paths (if you want to use
 >>these paths will "normal" file i/o functions such as C++ stream i/o).
 > Isn't that what wine_get_unix_file_name does?

I was responsible for this bit of hackery, so I'll try to explain.  The 
patch Dan sent in before only changes how the common dialogs display the 
filenames, it doesn't change how they deal with them internally.  The 
GetOpenFileName() function returns a structure containing the filenames 
the user selected.  Since the patch only changed the appearance of the 
dialog, GetOpenFileName() would still report that the user had opened 
the file "e:\\foo\\bar" instead of "/tmp/foo/bar".  This may or may not 
be what you want.  If you're porting a windows application that passes 
these filenames to Win32 functions like OpenFile(), it will work.  But 
if you're passing those filenames to native unix functions like fopen() 
(or to c++ iostreams, which in turn call fopen()), you'll have problems.

The module Dan was referring to above implements wrappers around the 
common dialog box routines that return filenames.  It just converts the 
filenames that the real routine returns to us to unix-style names by 
calling wine_get_unix_file_name, and properly modifying the structure 
that gets returned.  It was non-invasive, and works independently of the 
patch that affects the appearance of the dialogs.

You could make a case that the appearance of the dialogs should be 
controlled by a registry key, but the type of filenames they return must 
be known by the application for it to function properly.


More information about the wine-devel mailing list