+1 for Serge's latest suggestion.

FWIW, packagers for some distros frown upon external libraries such as zlib or minizip being included directly into the source of a program.

[QUOTE=debrouxl;277413]+1 for Serge's latest suggestion.

FWIW, packagers for some distros frown upon external libraries such as zlib or minizip being included directly into the source of a program.[/QUOTE]

We should then include the ZLIB source only on Windows. But its more difficult than I thought since the whole of savefile.c needs rewriting as it has a lot of code unique to Windows to avoid hitting the 4GB file size issue. I need to find out from Jason whether the non-Windows path in safefile.c will work on Windows when zlib.h is included.

Oh, I hadn't thought of that. The problem on Windows is that you can read a file with size > 4GB using the standard C file IO functions if the file is opened as binary, but you cannot write to it because Microsoft's C runtime library uses a 32-bit file offset. Native Windows API read and write operations work of course, but then you give up the buffered file IO operations that the standard library gives you.

So if the zlib source uses native windows calls for its low level read and write operations, then everything should work fine. Otherwise we'd have to use the same windows code we have now to feed bytes to zlib for compressing or decompressing.

[QUOTE=jasonp;277420]Oh, I hadn't thought of that. The problem on Windows is that you can read a file with size > 4GB using the standard C file IO functions if the file is opened as binary, but you cannot write to it because Microsoft's C runtime library uses a 32-bit file offset. Native Windows API read and write operations work of course, but then you give up the buffered file IO operations that the standard library gives you.

So if the zlib source uses native windows calls for its low level read and write operations, then everything should work fine. Otherwise we'd have to use the same windows code we have now to feed bytes to zlib for compressing or decompressing.[/QUOTE]

ZLIB 1.2.5 uses the current Microsoft runtime libraries via all the calls that provide 64-bit offsets (fseeki64, ftelli64, etc.). So this should be OK.

But if savefile.c needs to work without ZLIB we would have to maintain the existing Windows code or adapt the non Windows code path to map the file functions it uses to the 64-bit versions on Windows.

Then, only the nestedness of conditions should be changed. It is in two files: include/util.h and common/savefile.c
[CODE]#ifdef NO_ZLIB
#if defined(WIN32) || defined(_WIN64)
//...
#else
//...
#endif
#else
#include "zlib.h"
#endif
[/CODE]

That arrangement won't work because the Windows includes are needed irrespective of the value of NO_ZLIB. We need:
[CODE]
#if defined(WIN32) || defined(_WIN64)
....
#else
....
#endif

#ifdef NO_ZLIB
...
#else
#include "zlib.h"
#endif
[/CODE]

I would be grateful for volunteers to test a Windows msieve binary with ZLIB (either normal or CUDA).

[QUOTE=Brian Gladman;277678]I would be grateful for volunteers to test a Windows msieve binary with ZLIB (either normal or CUDA).[/QUOTE]

Is this in SVN or you do you have a binary to send? Either way I can help test.

Jeff.

Hi Jeff,

It is now in the msieve SVN. I would certainly be grateful for some testing as I hate conditions in conditional compilation, which I get wrong so often :-(

I'll have a free machine available by Saturday so I can test msieve.

Thanks for the offer. Can you send me a private message to give me an email address to send the binary to? I also need to know whether you will use the 32 or 64 bit version and whether you want the normal or the CUDA enabled one.