> Well, considering job to be done I would prefer to keep MAX_PATH
> limitation.
Why? If should compile out of the box even with a MAX_PATH of 2048. If
not this has to be fixed because of wrong use of the constant.
Where is the problem with it????
> But as far as we are aming to create not only "emulator" for
> runing Windows applications, but a framework for crossplatform development I
> would rather put some efforts to make it good enough to handle filenames
> supported by OS.
Hmm, it supports the winapi on these platforms.
Winapi means MAX_PATH=258. Only new developed applications where you mind
paths bigger MAX_PATH during development could benefit from it. Old applications
compiled with your version of winelib might not work.
> Obviously, I didn't suggest to write over structure/buffer boundaries. We
> have nothing to do with such functions. But interface that can possibly
> support long names (like FileOpen dialog) must do it in a full measure. And
> for "bad" functions we can add alternative calls supporting arbitrary length
> strings. But I don't really imagine required amount of work.
As example: The FileOpen dialog relays heavily on the shell32 if it comes to
any path/file specific operation. This can't be changed if you like to use
shell extensions like "MyFolder" within a FileDialog.
The SHGetFileInfo (the only official way to get informations about a file with
shell32) is restricted by definition (structure) to MAX_PATH.
You would have to add and expose a bunch of proprietary interfaces between
the wine dll's and would need a additional internal layer within these dlls. It
would mean a nearly complete rewrite of the code with a loss of
compatibility for the emulator part. You would loss the possibility to run
as example a native dll (eg. shlwapi) and a wine (eg. shell32.dll) together.
If you know what functionallity you need for you winelib application you could
probably use eg. a KDE or Gnome filedialog.
Ciao
Juergen
---
[EMAIL PROTECTED]
... from sunny Berlin
