# Native unix style paths in wine common dialogs

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.

Eric