I recently had the experiance of writting a database using Borlands free Compiler, which needed to store more than 4 gigabytes of data.
This proved to be something of a challenge, partially because there is nowhere that documents how to do it. This file should hopefully change that.
Note that I am not covering the ushall C-style FILE * interface or the C++ stream system, this is because I can't find a solution for this, besides, if you are going to be working directly with 64 bit files you will probably be after low level access anyway so you can do the caching & writeback yourself.

Explanation
Only bother to read this if you are planning to modify my techneque, as it documents the why, & gotchas that will, well, get you. Otherwise skip to the solution

Firstly, Borlands libc does not export 64 bit file access, neither is there any windows calls that will do it. So there are actually no functions avaliable for you to use. Other than changing compiler (40K makefile in this case, I think not...) the only sensible solution I could find is msvcrt.dll, a dll that provides the 64 bit file functions and has been included in default installations of windows since Windows 2000, and latter Service Pack versions of 98, which seeing as you require NTFS for 64 bit file access covers all bases.

The first problem with this is that the dll exports most of a libc library, it is microsofts dynamicly linked libc afterall, which means it is going to clash with borlands libc, not to mention the borland functions we want to use. Unfortunatly, you can't replace the borland libc version with this, as the borland libc has extra parts that this dll dosn't have, some of which you require. You can't include it after your libc library either, as whilst the i64 functions will be visible, others, such as open, won't, and you need to be consistant about which file functions you use, as the data on the other end of the handle is only stored in one memory space.
The (static) solution is therefore to create an export library for the dll which just exports the file functions, and link that dll before the borland libc file, so you use the msvcrt.dll functions for all your file i/o. There is also the dynamic solution, which I won't explore here, but would be required if your program was to work on pre-patched versions of windows '98. Its pritty obvious how that would work anyway.


Solution
To solve this problem you need several files - I've included them here to be downloaded. If you want to create them yourself I have that documented below.
Files:
An include file: ms_large_files.h
A lib file: msvcrt.lib

To use the file access functions you simply include the header file and link against the lib file.
The key point is to link to msvcrt.lib before you link to the borland libc library, this requires that you don't let the compiler link and do it yourself. i.e. use the -c flag to create the object files then link them using something such as:

ilink32 c0w32.obj {Your object files go here} ,, IMPORT32.LIB msvcrt.lib cw32mt.lib

If you don't understand the above line (Especially if c0w32.obj is the correct object file for you) have a look at this website which details how to link seperatly and the various .obj/.lib files the compiler would ushally link for you.

In terms of actually coding just open the header file and look - the functions are mostly the same as the borland set, it should be reasonably obvious.


Creating the above Files
This details how to do it without downloading any files from this website, for people who like to understand things. I would recomend downloading the files though, as there quite a pain to create.

Firstly you need the microsoft include files, I got them by downloading the microsoft free command line compiler. You then need to construct the header file I created, simply by taking the microsoft definitions and sticking them in a file. I also did the various defines passed into the functions at the same time for completness. Thats the easy file, now for the hard one.

To create the lib file you need to run implib on the correct def file - the def file I generated can be downloaded here. The command required is

implib -f msvcrt.lib msvcrt.def

To create the .def file you need to run tlib on the .lib of the .dll to get a complete .def file, from which you must then remove everything you don't require, i.e.

implib -f msvcrt.lib msvcrt.dll
tlib msvcrt.lib,msvcrt.def


Further Note
Uli Hofmann e-mailed me to point out that I was generating the dll-lib link by ordinal, not function name, and as the ordinals appear to change between windows versions this will cause it to crash. I've updated the above to reflect this. (And fixed a mistake I spotted whilst doing so.) He sugested the solution to this as generating the .lib directly from the dll, i.e.

implib -f msvcrt.lib msvcrt.dll

However, whilst this will work for some programs there is a gotcha. msvcrt.dll only exports a certain set of C library routines, whilst the borland one, cw32mt.lib, exports another set. The msvcrt set then hide the borland set, except for the functions borland provides which m$ dosn't. This could potentially catch you out, and whilst I didn't determine why causes the program which drove this aricle to crash. (If my memory serves me correctly it was related to replacing the borland malloc/free etc with the m$ one, didn't like it for some reason.) This is why I go to the effort of an intermediate .def, which I prune down to just the file IO functions so it does not hide the other borland functions.


That should just about cover everything, its not really hard, at least not compared to any real use of this information. (Thats a subtle hint that if your a newbie you don't want to be doing this, as the bugs that can result if you get it wrong can be really, really nasty;-)) Hopefully this should save someones time in google in complete disbelief that it can't be done, not to mention exploring possible solutions. If you find any mistakes or need any help with the above don't hesitate to e-mail me at "tom AT thaines DOT com". (remove the spaces, change the AT & DOT..)