printer / text mode version win32/other

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*

 

 

 

(C) 2002-01-26 <guidod>
 Guido U. Draheim

Win32 / Other / Older Systems

A talkback to the freshmeat article did ask:

Is largefile support in (for example) Windows any better? Win32 provides support for applications to use files >2GiB, and it is AFAIK supported on nt4 with ntfs, however I rather suspect that a lot of applications cannot deal with it correctly.

The same is probably true of libraries on other platforms too.

This is actually quite right - the win32-API provides a different `transitional API` to support 64bit file-access for applications using lseeki64/telli64/fstati64. Note the "i64" suffix instead of the "64" suffix in the unix `transitional API`. That's perhaps due to the fact that the win95/nt APIs were defined before the unix98 APIs were discussed.

The win32-API does not use off_t for the file-access methods, and it uses plain `long` instead, - just like the old unix systems will do. Even with the widespread adoption of off_t, Microsoft did never change its APIs by introducing a `typedef long off_t` around. Even today the win32-API shows usage of `long` for lseek/tell/stat functions (those w/o i64)

That makes win32 immune to dualmode problems, and the absence of `off_t` makes it even inappropriate to add a shapeshifting -Define somewhere that could make magically standard posixish programs to use 64bit file-offsets on platforms being otherwise 32bit. At the same time, I can not recall any contemporary unix-compatible system that is missing the `off_t` typedef, even that such is not impossible in theory - see autoconf AC_TYPE_OFF_T which would add a `typedef long off_t` in such a case. I guess that the only unix-compatible systems be missing off_t are also those that do not use 64bit file-access internally - contrary to win32 platforms.

To get to the point - I do not expect any programmer to use the `transitional API` directly, suddenly using tell64/telli64 directly. The off_t magic allows to run 64on32 with just a -Define, one should just care to add that -Define everywhere. That will make the software still compatible with very old system that do not use 64bit file-access internally, however it does also make it use plain 32bit file-access on those systems that did never introduce off_t, thereby missing the chance to change the default sizeof off_t later.

Note however that the unix98 largefile spec allows to do the same as on win32 - simply define -D_LARGEFILE64_SOURCE - which will make the 64bit file-calls to get visible (normally they are suppressed to not pollute the application namespace). Then you can declare variables of type "off64_t" and call functions like lseek64/tell64/fstat64 with these entities. However, portable software would then need to deploy a lot of #ifdef's around to select either of lseek/lseek64 calls. That's what the 64on32 typeshifting is about where the #ifdef's are put out into the system headers.

(win32 largefile usage in the C library...)