AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
August 2008

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2008.08.11 17:57 "windows 64 bit build", by Mikhail Kruk
2008.08.11 19:29 "Re: windows 64 bit build", by Bob Friesenhahn
2008.08.11 19:35 "Re: windows 64 bit build", by Mikhail Kruk
2008.08.11 20:03 "Re: windows 64 bit build", by Edward Lam
2008.08.11 20:55 "Re: windows 64 bit build", by Bob Friesenhahn
2008.08.11 20:51 "Re: windows 64 bit build", by Bob Friesenhahn
2008.08.12 00:36 "Re: windows 64 bit build", by Edward Lam
2008.08.12 02:44 "Re: windows 64 bit build", by Bob Friesenhahn
2008.08.12 03:53 "Re: windows 64 bit build", by Edward Lam
2008.08.12 04:04 "Re: windows 64 bit build", by Mikhail Kruk
2008.08.12 12:54 "Re: windows 64 bit build", by Edward Lam
2008.08.12 04:47 "Re: windows 64 bit build", by Bob Friesenhahn
2008.08.12 13:04 "Re: windows 64 bit build", by Edward Lam
2008.08.13 04:23 "tif_win32.c patch proposal (was: windows 64 bit build)", by Edward Lam
2008.08.13 05:32 "Re: tif_win32.c patch proposal (was: windows 64 bit build)", by Bob Friesenhahn
2008.09.04 14:12 "Re: tif_win32.c patch proposal", by Edward Lam
2008.08.12 00:41 "Re: windows 64 bit build", by Edward Lam

2008.09.04 14:12 "Re: tif_win32.c patch proposal", by Edward Lam

Seeing that there's been no movement on this patch, I've now submitted 
this under bug 1941 (http://bugzilla.maptools.org/show_bug.cgi?id=1941)

Cheers,
-Edward

Bob Friesenhahn wrote:
> On Wed, 13 Aug 2008, Edward Lam wrote:
>>> If you can submit a tested patch, I will be happy to commit it.
>>
>> Ok, here's a patch attached for discussion. The approach I previously 
>> mentioned ran into a slight snag. Once you've created an fd for a 
>> HANDLE, the C runtime library (CRT) takes ownership of it. Thus, when 
>> you call _close(fd), it closes the associated HANDLE as well. Plus, in 
>> _tiffCloseProc(), there was no way (that I found) to query the CRT to 
>> return the associated fd given the HANDLE. So in the end, I did 
>> something more drastic, albeit cleaner.
> 
> It seems that this approach is drastic enough that we should wait for 
> some feedback from potentially impacted users before moving ahead with it.
> 
> Being more from the Unix mind-set than the Windows mind-set, I like your 
> approach better than the approach which is currently used.
> 
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>