Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-i.b-one.net (mx-i.one.com [91.198.169.56])
	by mail9.b-one.net (Postfix) with ESMTP id 16D06400614
	for <info@awaresystems.be>; Tue, 30 Nov 2010 20:44:48 +0100 (CET)
Received: by mx-i.b-one.net (Postfix, from userid 106)
	id 0B4951D28F0B; Tue, 30 Nov 2010 20:44:35 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=4 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-i.b-one.net (Postfix) with ESMTP id 799B61CFEF72 for
 <info@awaresystems.be>; Tue, 30 Nov 2010 20:44:34 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 533291D1AEDC6; Tue, 30 Nov 2010
 14:43:55 -0500 (EST)
Received: from hrndva-omtalb.mail.rr.com (unknown [71.74.56.123]) by
 lists.maptools.org (Postfix) with ESMTP id E8B001D1AED27 for
 <tiff@lists.maptools.org>; Tue, 30 Nov 2010 14:43:08 -0500 (EST)
X-Authority-Analysis: v=1.1 cv=6ptpMFIBtxRk0xdOb6IhJTbTLVRlKjWFes7R4SsWCrA=
 c=1 sm=0 a=npYu1qErv9wA:10 a=8nJEP1OIZ-IA:10 a=ZMbh+xkmLanH4ztLziQR/g==:17
 a=8981fWPbAAAA:8 a=l4aQWd-FAAAA:8 a=n0vAvVC2AAAA:8 a=e9oLxYfYBtE5b8LJ6hAA:9
 a=Rv1FDnekKJmIdTC4bY8A:7 a=opvmYXddZPYMxeCqNd82ll5NKj0A:4 a=wPNLvfGTeEIA:10
 a=ZMbh+xkmLanH4ztLziQR/g==:117
X-Cloudmark-Score: 0
X-Originating-IP: 66.25.158.123
Received: from [66.25.158.123] ([66.25.158.123:1037] helo=KAM6400) by
 hrndva-oedge01.mail.rr.com (envelope-from <KevinMyers@austin.rr.com>)
 (ecelerity 2.2.3.46 r()) with ESMTP id A8/7F-26142-2C355FC4; Tue, 30 Nov 2010
 19:42:58 +0000
Message-ID: <14DCF6D0C50244AE92D1B17BAECB6F5D@KAM6400>
From: "Kevin Myers" <KevinMyers@austin.rr.com>
To: <tiff@lists.maptools.org>
References: <76394064-A6C2-46E1-BC59-DB187EDDD275@tiscali.co.uk>
 <4CF55000.7000109@telegraphics.com.au>
Date: Tue, 30 Nov 2010 13:43:09 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Subject: Re: [Tiff] Win32 ReadFile() / WriteFile() heads-up
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

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


----- Original Message ----- 
From: "Toby Thain" <toby@telegraphics.com.au>
To: <tiff@lists.maptools.org>
Sent: Tuesday, November 30, 2010 13:26
Subject: Re: [Tiff] Win32 ReadFile() / WriteFile() heads-up


> 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
>
>> John
>> 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/
>>
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/ 

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