Help compiling seek-bzip2 on Windows

Question

I cannot get James Taylor's excellent little "seek-bzip2" to compile under Windows? It can index a bzip2 archive and then use that index to provide random access to the individual blocks of the archive.

It's written in C and requires 64 bit long longs and is available here: http://bitbucket.org/james_taylor/seek-bzip2

I am unable to get it to compile on any free Windows C compiler.

• Borland doesn't have some required header files.
• lcc compiles it but it fails with "unexpected EOF" on any bzip2 file.
• mingw will compile it if you remove the "-m64" flag but it will fail in the same way as lcc above.

The free compilers don't seem to have very good debugging support and MS Visual Studio refuses to install on my removable hard drive and my netbook's C and D drives lack sufficient space.

---

EDIT I've reworded this question since I was asking somebody to port it for me but I'm happy to try to port it myself. I just don't know where to begin. I haven't touched C since before 64-bit types became common.

Answer 1

By default stdin and stdout will work in text mode, translating 0A -> 0D 0A. You need to modify seek-bunzip's main to _setmode stdin and stdout as binary before uncompressblock:

int main( int argc, char *argv[] )
{
    unsigned long pos = atol( argv[1] );
    int status;
    _setmode(0, _O_BINARY);
    _setmode(1, _O_BINARY);
    status = uncompressblock( 0, pos );
    if ( status )
        fprintf( stderr, "\n%s\n", bunzip_errors[-status] );
}

That does the trick for me with MSVC++10. You may need to lose leading underscores from _setmode and _O_BINARY on other compilers - I'm not sure. Other than that I needed to:

• remove unistd.h includes
• add includes:
  • micro-bunzip.h: sys/types.h
  • micro-bunzip.c: sys/types.h
  • seek-bunzip.c: sys/types.h, io.h, fnctl.h
• forward-declare get_bits, read_bunzip and start_bunzip from micro-bunzip.c in micro-bunzip.h
• change write and lseek to _write and _lseek (again might be MSVC only)

Then it worked for me, after I realised that the command-line parameter was a bit offset (i.e. 32 for first block) not a byte offset.