Win32 System Programming

Win32 vs. The C Run-Time Library for File I/O

This information augments the discussion on Pages 65-66 regarding the choice between Win32 and the Standard C Library (SCL) and the more comprehensive C Run-Time Library (CRTL) when performing file I/O. The SCL are those functions defined by the standard and described in Plauger's book, The Standard C Library. The CRTL includes the CRTL but also includes all the non-standard extensions, such as the generic string functions, extended FILE functions, _beginthreadex(), and many more.

The SCL library advantages cited in the book are: portability, line- and character-oriented functions, and ease of use. Disadvantages include the inability to traverse directories, manage files or deal with file attributes, and the inability to use security, memory mapping, file locking, or asynchronous I/O.

Here is some supplementary information, written in terms of the advantages of using Win32 rather than the Standard C Library. This discussion was prompted by some postings on comp.os.ms-windows.programmer.win32 and some email in response to those postings.

This discussion is confined to the Standard C Library as documented, for instance, in Plauger's book. You will find that Visual C++ CRTL provides an extensive set of extensions that allow you, for example, to lock a file. Using these extensions provides no real advantages over the Win32 calls, other than allowing you to use a FILE pointer rather than a HANDLE. There is, in fact, a _get_osfhandle() function that obtains the HANDLE associated with a FILE.

Direct Access to "Large Files". A "large file" is a file longer than 4GB (the limit for a 32-bit file pointer). A "small file" is shorter than 4GB. Many applications require large files, but, on the other hand, many programmers are not concerned with this issue and can use fseek(). Win32 can perform direct access, using SetFilePointer or the offset fields in the OVERLAPPED structure, to position anywhere in a file. One email correspondent pointed out that the library functions fgetpos and fsetpos use a 64-bit file position and therefore overcome the limitation. The file position parameter, however, is opaque and, in the standard, is not to be manipulated by the programmer. You can only obtain the current position with fgetpos, store it, and use it later with fsetpos. This will be adequate for some applications, but not for those that compute a file position (consider a file management function that computes a file position with a hash function). It turns out that fgetpos and fsetpos do, in fact, ultimately call the _lseeki64() function using the position parameter, so you actually could get away with computing a file position for fsetpos. Such a non-standard use is, however, dangerous and provides little advantage.
Memory-Mapped Files. MMF provide the convenience of in-memory algorithms without I/O concerns. Chapter 6 has several examples, such as in-memory sorting and using the C Library character and string processing functions on a mapped file. This argument is most appropriate for files that are small enough to be mapped (2GB is the strict upper bound). The memory-mapped file performance advantages noted in Appendix C require file mapping, but, as discussed below, only apply to relatively short files; see atou for more data on memory-mapped file performance.
File Locking. File locking is not a part of the Standard C library. The VC++ CRTL does provide a _locking() function, but it is limited to "small" files.
File and Directory Management. The SCL does not allow control (either getting or setting) file attributes (length, time stamp, etc.) nor can you scan a directory.
Handle Inheritance and Redirection. A HANDLE can be inheritable and copied to a new child process, whereas a FILE pointer cannot. Likewise, standard I/O can be redirected to a handle. This is illustrated in Chapter 9 with anonymous pipes.
Device Independence. A program written to use a HANDLE for I/O can be device independent; the HANDLE can be associated with a file or a pipe, for instance.
Asynchronous I/O. Asynchronous I/O requires a Win32 HANDLE.

Nonetheless, if you are performing simple processing of a moderate-sized file, the STL is hard to beat for simplicity, convenience, and even performance.

The extended C Library provided with Visual C++ is quite rich with any number of functions that are not a part of the standard. Some, such as _popen(), allow you to perform many tasks that the book performs with Win32 functions. However, while these functions are stylistically similar to the C library, they do not appear to be any easier to use and are neither Win32 nor standard C. Furthermore, some functions, such as _umask(), appear to be useful, but, after examining the library source code, are found to be very limited.