Yes, but there are obvious approaches to getting around that.
See
http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT for information about DBF format.
One way is to simply use 8 bytes of data in the header to describe the number of records, stretching the header by four bytes. This would be OK, because the version number would be changed for this format, and old programs (that are written properly) would not try to read it.
If this approach is taken, it would be very wise to also lift the 10-character limit on field names. Padding the new format with extra reserved space would be a good idea.
I imagine that so many users want large file support that they're willing to buy a new copy of FoxPro, and new copies of any programs they use that read/write DBF format. The alternative is the giant, never-ending hassle of chopped-up data files that we have now.
Other ideas aren't so good:
A 'clever' approach would be to hide the extra 4 needed bytes somewhere else in the header. Compatability is hard to ensure here, so it really doesn't help all that much.
Another idea is to produce a standard header, but to pack extended 64-bit specific info into a special field definition. Compatability still breaks, and this one is just as ugly as the last idea.