largefile problems - win32 / libc

(2)

index
-summary
-history
-testscript
perl / python

problems
-with callframes
-with structures
-largefile seeks
-broken builds

systems
-freeBSD/darwin
-linux/solaris
-64on32 mix
-distro makers
-win32/other (2)

libraries
-libc ..(3264)
-zlib ..(-32-)
-gtk2 ..(-64-)

converting
-old non-off_t code
-going largefile
-longlong default
-face dualmode
-make twinlibs
-and defend (it)

programming
-largefile default
-off_t in headers
-make export64
-find mismatch
-the autowrappers
-environ changes
-best practice?

old library
-dualmode renames
-the extra function
-largefile64_source
-glibc headers
-libgz example ***

new library
-dual export
-largefiles win32
-compat32 calls
-compat32 library
-long32 dualmode

links
-some quotes
-sitemap / mpl
-large.file Group*
-ac-archive Site*

Win32 / libC

http://mail.gnu.org/archive/html/autoconf/2003-11/msg00039.html

A little discussion sprang up orginally started how to enable largefile support for C programs within a win32 environment. That's not quite the same as in posixish systems as there is no off_t available and no magic define in the compiler environment. In the course of discussion, we did wonder how much the win32 C library (usually in MSVCRT) does actually provide us with largefile support - finally, Bob Friesenhahn had the final word on it, answering to my question:

On Mon, 10 Nov 2003, Guido Draheim wrote:
>
> With win32 systems that might be slightly different however since
> here the libc is not system-specific but compiler-specific. Each
> compiler vendor and compiler version may link its programs with
> a different libc implementation and it is uncertain whether that
> libc implementation takes advantage of kernel largefile calls.
> Actually, I just do not know but I expect that the most simple
> path has been used and the win32 stdio api is fully limited to
> 32bit on 32bit cpus, but that nay FUD and we better ask a guru.

Regardless of the wonders of Windows-NT, XP, etc., the WIN32 API is
still hobbled by an expectation that most pre-compiled programs will
be able to run under Windows '95.

Microsoft at least exposes the underscore "raw" API calls necessary to
support 64-bits. It seems that Borland does not. MinGW uses the libc
DLL that comes on every Windows system so it does provide access to
the underscore API calls.

It seems that at least for the Microsoft compiler, Cygwin, and MinGW,
Autoconf could arrange to provide some compatibility defines to allow
POSIX-style read/write code to compile and run with large file
support.

At the moment however, there is no automatism in autoconf to allow largefile be used for an application. You have to add your own checks and header defines that forward the calls to raw file access on to their *i64 largefile variants exported by the kernel. And do not expect the C library's stdio part to use largefile internally. Assume there is no fseeko() function and that fileno() returns a 2gig-limited handle. A vFAT filesystem does not support larger files anyway, only NTFS does.