2019.10.02 12:29 "Re: [Tiff] TIFF_IO_MAX too large for Windows XP", by Edward Lam

On 10/1/2019 3:37 PM, Roger Leigh wrote:

 >

Did you try building with tif_win32.c instead of tif_unix.c?

I can see some documented limits here: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile (nNumberOfBytesToWrite). Whether they apply for your case, I don't know.

This documentation note is a great find! Quoting it here for posterity:

"""

Windows Server 2003 and Windows XP: Pipe write operations across a network are limited in size per write. The amount varies per platform. For x86 platforms it's 63.97 MB. For x64 platforms it's 31.97 MB.

"""

If this limitation is indeed also being applied to ReadFile() [1], then it doesn't help much to use tif_win32.c either because we also do ReadFile()/WriteFile() calls there with INT_MAX, albeit with a hard-coded constant of 0x80000000UL instead of using TIFF_IO_MAX. It will similarly need to be limited to something less than 31.97 MB (unless we do both a WinXP and 32/64-bit platform test).

-Edward

1. On Windows, read()/_read() calls ReadFile() underneath. I double-checked the SDK source.

Did you try building with tif_win32.c instead of tif_unix.c?

For the change you made, would this not have quite negative performance

> implications for platforms supporting rather larger sizes?  This rather

small when individual images can be many gigabytes.

If this was to be supported, I think it would need to be set within an XP-specific #ifdef so that all the other platforms continue to use the larger size.

However, without wanting to sound too negative, Windows XP is thoroughly

> obsolete at this point.  It's five major releases behind, completely

unsupported for over five years, and I don't see and value in expending effort in supporting and maintaining it in 2019. Same for Vista, also

> unsupported now for two years.  Extended support for 7 ends in January.

https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet has the current lifecycles dates. If you need to support it, that's quite fine if you want to modify libtiff locally for your own use, but I'm unsure sure of the greater value in having such changes incorporated generally, especially if they will negatively effect currently supported

> platforms.  However, I'm willing to be persuaded if there are good reasons.

Kind regards,