2010.11.30 19:15 "[Tiff] Win32 ReadFile() / WriteFile() heads-up", by John Emmas

2010.12.05 18:05 "Re: [Tiff] Win32 ReadFile() / WriteFile() heads-up", by Edward Lam

On Tue, November 30, 2010 14:15, John Emmas wrote:

The problem is that in libTIFF (_tiffReadProc() for example, in tif_win32.c) reading gets handled by the Windows function, ReadFile() and similarly for WriteFile(). Unfortunately, those functions seem to only work with handles returned by CreateFile(). They don't work for handles obtained from fopen() or _wfopen(). Of course, if one sticks entirely with libTIFF and uses the recommended open function TIFFOpen(), all will be fine (because that does call CreateFile() and thereby obtains a suitable handle). However, any library that's cross-platform probably wouldn't even consider CreateFile() / ReadFile() / WriteFile() etc. It would tend to prefer generic CRT functions, such as read() and write().

Sorry for arriving late on this conversation as I just got back from vacation. I'm still jet lagged but this sounds like a problem that my patch for bug 1941 (http://bugzilla.maptools.org/show_bug.cgi?id=1941) would fix.

Personally, I was hoping that it would make it into libtiff 4.0 but the 4.0 release always seemed to be imminently on the horizon and the source breaking nature of it kind of held it back.

FWIW I've done some experiments today to replace the Windows-centric file functions with their standard CRT equivalents and the initial signs were pretty encouraging. How do others feel about using read() and write() etc, instead of ReadFile() and WriteFile()? I'm not familiar enough with libTIFF to understand what the ramifications might be.

If you do this, then you might as well just compile libtiff with tif_unix.c instead (the default behaviour). I'm actually surprised that the libgtk-win32 tool chain doesn't do this already. The drawback with using tif_unix.c on Windows is that you lose the ability to deal with tiff files larger than 2 GB (previously noted here: http://www.asmail.be/msg0055289033.html).

Best Regards,

-Edward