-
2008.07.28 13:01 "[Fwd: Re: [Tiff] CVS access]", by Edward Lam
- 2008.07.28 14:02 "Re: [Tiff] CVS access", by Mateusz Loskot
-
2008.08.11 20:55 "Re: [Tiff] windows 64 bit build", by Bob Friesenhahn
-
2008.08.11 19:35 "Re: [Tiff] windows 64 bit build", by Mikhail Kruk
- 2008.08.11 17:57 "[Tiff] windows 64 bit build", by Mikhail Kruk
- 2008.08.11 20:03 "Re: [Tiff] windows 64 bit build", by Edward Lam
- 2008.08.11 20:51 "Re: [Tiff] windows 64 bit build", by Bob Friesenhahn
-
2008.08.11 19:35 "Re: [Tiff] windows 64 bit build", by Mikhail Kruk
2008.08.12 04:04 "Re: [Tiff] windows 64 bit build", by Mikhail Kruk
Sorry, don't have any test files. I don't need it for large file support, I just need a native 64 bit build.
On Mon, Aug 11, 2008 at 11:53 PM, Edward Lam <edward@sidefx.com> wrote:
On Mon, August 11, 2008 22:44, Bob Friesenhahn wrote:
On Mon, 11 Aug 2008, Edward Lam wrote:
OK, second take then. We keep everything the same but fix it differently in tif_win32.c. In TIFFFdOpen(), we use _get_osfhandle() to convert the given ifd into a HANDLE that we pass to TIFFClientOpen(). In the calls to TIFFFdOpen(), we call _open_osfhandle() to allocate an fd corresponding to the HANDLE.
If you can submit a tested patch, I will be happy to commit it.
Does anyone know where I can get a test file? :) Is it enough to generate sufficiently large image (say of constant color) with no compression?
Are the _get_osfhandle() and _open_osfhandle() functions available in older versions of Windows? (e.g. Windows '98?).
According to MSDN [1], it is. But then I have no idea how accurate MSDN is. :) MSDN also shows _get_osfhandle() as returning an int but on my MSVC 2005 io.h I see it returning an intptr_t.
1. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx