99c
Subj : Re: Filesize beyond FAT32 ?
To   : borland.public.cpp.borlandcpp
From : "Ed Mulroy [TeamB]" <ed@mulroyREMOVETHESECHARS.org>
Date : Mon Aug 04 2003 11:04 pm

Borland C++ 3.0 supported DOS 3.3 and Windows 3.0.  It is from 12 years ago
so not even one byte in it is to support the Win32 FAT32 file system so it
has no support for files with sizes in the Gigabyte range.

Borland C++ 5 is not posted for download.  What you have downloaded is the
command line tools from C++ Builder version 5, a compiler that only supports
Win32.  It does have a linker and the libraries are different, not only
because they are 32 bit libraries but also because the languages have gone
through many changes in the past 12 years.

fsetpos, fgetpos, ftell and fseek all work on a 4 byte argument, not an
__int64 or 8 byte argument so cannot deal with the size file you wish to
handle.  Call fflush and then call the Win32 function SetFilePointer.  The
Windows file handle needed for that call can be gotten from the FILE* handle
by calling _get_osfhandle with an argument of
fileno(file_ptr)  A couple of simple wrapper functions could handle that
easily.  An alternative and what I would use were I to have no ability to
avoid using a 2 Gig file is using the Win32 file handling functions.

C++ Builder is handled in other newsgroups, all of which have the word
'cppbuilder' in their name.  Two that may be of interest to you are:

  borland.public.cppbuilder.commandlinetools
  borland.public.cppbuilder.nativeapi

..  Ed

> Trandog wrote in message
> news:3f2f0647$1@newsgroups.borland.com...
> I have a lot of code written in Borland C (3.0); a lot of work
> to recompile and link all the code.
>
> One of my programs is now dealing with a file > 4 Gig.  I
> need to be able to jump around the file, but I can't seem
> to do that with this compiler.  Is there a way to fgetpos
> (or ftell) and fsetpos (or fseek) with __int64 values?  I tried
> the fgetpos(ptr,&__int64num), but it doesn't seem to work
> on values > INT_MAX.
>
> I downloaded the BC5, but it seems to not include the linker,
> and requires a new set of run-time/link-time libraries. It seems
> as fpos_t is still defined as long
>   (32 bit).  If 64 bit locations are supported, I am willing to try to
update
> all my system,but I hate to do that without assurance that it will solve
my problem.
>
> Does anyone have a viable solution?  Thanks.

.

0