|go text: || - index - problems - [ systems ] - libraries - converting - programming - old library - new library - links -
||topics: || - freeBSD/darwin - linux/solaris - 64on32 mix - distro makers - [ win32/other ] - Win32 / Other / Older Systems

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...)