Dear BrowserUK,

Your answer proves that you exactly should bring this up on p5p rather than here :)

Of course it is not good that 5.8.1-pre do not compiles now with Borland C++ without touching source code tree (need some *.h patching), yet 5.8.0 builds with Borland fine -- no USE_LARGE_FILES, but source tree builds fine. Hence incompatibility was introduced somewhere in between. At least this needs immediate patches in p5p, may be you'll be in time before RC5 snapshot.
And 5.10.0-to-be also needs to be updated.

It is wrong to state that p5p is not aware of Borland compiler, it is really supported, but sometimes there is no Borland wisdom handy. You're very welcomed to add your efforts. Honestly.

I also must disagree with your "From Borland's perspective, the compiler is free and doesn't support huge files. If you want that then buy their professional compiler suite". Our department payed for professinal compiler suite, as of Borland C++ Builder 4, and it uses *exactly same compiler* as free compiler suite. If you buy commercial suite, you pay for IDE, VCL (another Borland CRT, but also lacking _*i64()). It has absolutely same and interchangeable compiler inside!

Now I'll do a humble attempt to answer your question, but don't expect much from stupid dog :)

You see many wrapper functions in ./win32/ sources. You don't even realize which of those are used and wrapped to what. The only I can say to you right now with probability of 99% is that fgetpos function from win32.c is *not* used, instead there is a forest of wrappers and ifdefs, and it is far from obvious what namely is called, look at occurences of fgetpos in miscellaneous files, especially this from perl.h:

#ifdef USE_64_BIT_STDIO
....
#   if defined(USE_FGETPOS64)
#       define fgetpos fgetpos64
#   endif

and

#ifdef USE_64_BIT_STDIO
#   ifdef HAS_FPOS64_T
#       undef Fpos_t
#       define Fpos_t fpos64_t
#   endif

yet in config_H.vc contains
#define Fpos_t fpos_t        /* File position type */
[download]

So underlying API finally will be called with fpos64_t which is no longer 32 bit.

Anyhow, this becomes more and more complicated and I gave up when I looked into this last time, and I just beleived that "all works if API has 64 bit support and do not work otherwise".

However, still source code needs fixing to revive Borland build. The problem exists because many people propose patches into ./win32 files and they do not check Borland build, so they break it from time to time

And please do not mystify p5p and go discuss your thoughts there. You have your patches, so go and propose them.
Even I speak there. Hence anyone could speak there (provied there is something on-topic to say).
www.perl.com clearly suggests subscribing and discussing on p5p, so why not just go and do this?

Courage, the Cowardly Dog