On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote:
This patch allows winelib to be conditionally compiled with USE_NATIVE_UNIX_PATHS macro. Enabling this will cause the common dialogs to display using unix paths instead of drive letters.
Fantastic! What would rule even more is if this was not a conditional compilation flag, but something that could be toggled at runtime. That way you can have a single Wine installation that has both half-native winelib apps and regular win32 binaries run at once. As it is, this patch is only really useful for when you are distributing your own app-specific copy of Wine, no?
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?
thanks -mike
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
-
Eric Frias -
Mike Hearn