Juergen Schmied wrote in message
<[EMAIL PROTECTED]>...
>> Last choice is to follow Microsoft's strategy and disable access to
>> folders with pathnames longer than MAX_PATH. FO dialog and Windows
Explorer
>> show error message "Can't access this folder. Path is too long." when you
>> try to enter such directories.
>Know you dont like it but if there are not really good reasons I would
stick with this.
Well, considering job to be done I would prefer to keep MAX_PATH
limitation. 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.
>There are many structures like SHFILEINFO where a element in a structure is
limited
>to MAX_PATH. We can't change this without breaking binary compatibility.
>Second point: buffers in windows applications are often allocated on the
stack. If
>we give paths longer than MAX_PATH back to such a application we will get a
buffer
>overrun.
Obviousely, 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 realy imagine required amount of work.
Regards,
Serg Ivanov
[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]".
