James Hawkins wrote:
On 5/5/05, Troy Rollo wine@troy.rollo.name wrote:
Precisely. WINE is not just for running apps compiled for Windows - it's also for making the Windows API available under UNIX. For this second application, users need to (at a minimum) be seeing UNIX paths (and not Windows paths at all) in the dialog. It is also reasonable in this context for the application to expect to use APIs with UNIX paths without having to convert them.
wine wasn't designed to accept unix paths in the apis directly or to display them in open file dialogs, and that's why we have virtual drives.
Whether or not wine was originally designed for this, winelib as it exists right now is great for making a unix-native version of a windows program. The commercial porting library I have experience with behaves exactly this way -- Windows API functions took and returned native unix paths, and everything displayed to the user looked like a normal unix path. We found this to be a very natural way for a porting library to behave.
I'm not saying that this should be the only way winelib should behave, or even that it should be the default way. It seems like several of us have already made our own hacks to get winelib to work this way -- it would be a shame not to at least make unix paths an option.
In our application, we would often take a filename that came from a windows API function, (say, a Save File dialog), and do something like construct a std::ofstream() using that path. Since the standard library wasn't compiled against wine, it gets confused by the windows paths, and creates a file named 'z:\tmp\foo.txt' in the current directory, instead of '/tmp/foo.txt' like I want it to. Yes, we could've figured out how to compile all of our third-party libraries against wine and it would've worked, but that can be a *lot* of work and you still don't end up with an application that looks at home on unix.
I'm leaning toward the separate entry point solution (the various approaches were canvassed here a couple of weeks ago) since it avoids problems with Microsoft adding new flags of their own later that use the same values as WINE specific flags.
This just adds complexity to an already complex beast. Keep it simple.
So far, the separate entry point solution sounds like the best one to me also, at least for selecting what the API functions expect & return. I'm not sure about the best way to select whether unix paths are displayed to the user or not. Since that could also benefit windows-native applications, that preference might be better off stored in the registry or elsewhere.
Eric