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

2010.11.30 19:43 "Re: [Tiff] Win32 ReadFile() / WriteFile() heads-up", by Kevin Myers

I haven't looked into this very much *at all*, so what I am about to say could easily be *very* wrong. That being said, wouldn't changing libtiff to use read() and write() break large file handling (greater than 4GB) under Win32? If so, that would be a bad thing.

s/KAM

On 30/11/10 2:15 PM, John Emmas wrote:

You guys are probably already aware of this but I thought I'd flag it up anyway....

As you know, libTIFF is widely used by 3rd party products and libraries. Among them is the cross-platform library libgtk. On the Windows platform, this is called libgtk-win32. LibTIFF is actually used by libgdk_pixbuf which is a graphical image library, supporting many different image types (BMP. PNG, JPEG etc).

Because it interfaces with so many different types it generically uses the CRT function _wfopen() to open the image files. The FILE* returned by _wfopen() is then passed to _fileno() to obtain a file handle. That file handle then gets used to manipulate the file (reading / writing etc) using the interface provided by each specific library. This all works very well as long as you don't use the win32 versions of libgdk_pixbuf and libTIFF.

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().

I'm not saying there's anything wrong with libTIFF. LibTIFF works fine as long as you use its own interface function to open TIFF files - but libgdk_pixbuf is an important library and it'd be nice if libTIFF could work seamlessly with it. At the moment it only works (under Windows) if you use a *nix style build system, such as Cygwin or minGW. Things fall down badly if you want to use Visual C++. libgdk_pixbuf needs to use generic handles that can be applied to all file types across all platforms - it shouldn't be getting brought down by special file handles that only apply to libTIFF and Visual C++ but nothing else.

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.

Can't the existing tif_unix entry points be used, if the application wants to use POSIX file handles?

It makes sense to me to have tif_win32 use Win32 file handles; and changing this would break existing code.

--Toby

P.S - incidentally, the link shown on your home page for subscribing to this mailing list seems to be broken:-

http://remotesensing.org/mailman/listinfo/tiff

>> _______________________________________________
>> Tiff mailing list: Tiff@lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/tiff
>> http://www.remotesensing.org/libtiff/