-
2004.11.23 20:34 "Re: [Tiff] compatibility patch", by Andrey Kiselev
-
2004.11.23 20:58 "Re: [Tiff] compatibility patch", by Bob Friesenhahn
-
2004.11.23 21:24 "Re: [Tiff] compatibility patch", by Edward Lam
- 2004.11.23 21:28 "Re: [Tiff] compatibility patch", by Edward Lam
-
2004.11.23 21:51 "Re: [Tiff] compatibility patch", by Bob Friesenhahn
-
2004.11.23 22:04 "Re: [Tiff] compatibility patch", by Edward Lam
- 2004.11.23 22:33 "Re: [Tiff] compatibility patch", by Jeff Breidenbach
- 2004.11.28 14:46 "Re: [Tiff] compatibility patch", by Andrey Kiselev
-
2004.11.23 22:04 "Re: [Tiff] compatibility patch", by Edward Lam
-
2004.11.23 21:24 "Re: [Tiff] compatibility patch", by Edward Lam
-
2004.11.23 20:58 "Re: [Tiff] compatibility patch", by Bob Friesenhahn
2004.11.23 22:33 "Re: [Tiff] compatibility patch", by Jeff Breidenbach
> > But what a problem with the standard tif_win32.c? Your new
> > tif_win32crt.c will be not portable anyway and specific for Windows.
As stated in the patch, the problem with the standard tif_win32.c is that I can't make the following call from a windows application:
fp = fopen( "foo.tif", "rb")
TIFFFdOpen(fileno(fp),"r");
This matters because my application only has a file pointer (FILE *fp) available when it calls libtiff. This is a very clean and convenient interface. It works great with libtiff on *nix. With the patch, it also works for Win32.
So somehow combining the best of both files. I think we want:
- 4GB files
- memory-mapped files
- the more user-friendly Win32 error handler from tif_win32.c
Let's put "consistant calling interfaces between Win32 and Unix" on the list as well.
Cheers,
Jeff
Jeff Breidenbach <jbreiden@parc.com>
Palo Alto Research Center (PARC)