unix filenames in notepad

[Eric Frias]

James Hawkins wrote:
> On 5/5/05, Troy Rollo <wine at 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