Juergen Schmied wrote in message
<[EMAIL PROTECTED]>...
>> 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????
Ok. The problem (actually bunch of them) is that MAX_PATH limitation is not
enforced in FileOpen and Shell32 (Wine counterparts). I.e. you can create
new / change current directory to path with length more than MAX_PATH
characters, though API doesn't support such file length. So there are
bufferes overflow, cuted filenames, etc. For Microsoft 'designers' of
Shell32 it wasn't a problem because MAX_PATH limit was in file system. So
even if they don't check path length in shell32 they will get error from
filesystem. In our case we have to do it manually.
>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.
Not exactly. File API functions either accept null terminating strings which
potentially can be any length, or have parameter specifying size of output
buffer, and if it is not big enough return reqired size. So even native
windows applications, if written properly, can potentially handle long
names. Shell32 is not part of core OS, and the fact that it is limited to
MAX_PATH by-design gives another example of incapability of Microsoft to
create something integral and well desined.
>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.
As a choice I suggested to extend shell32 introducing new functions similar
to SHGetFileInfo and others but without buffer length limitation. This will
not break compatibility as far as original ones will have original interface
(and problems). In this case FileOpen dialog will be potentially capable
open/save any file, native linux apps using extended interface will be truly
native. I know it's not that simple as it sounds, but I just wonder - are we
willing to go in this way?
Regards,
Serge.
[EMAIL PROTECTED]
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
