The Windows Win32 API

The Windows Win32 API

We have, so far, focused mostly on UNIX. Now it is time to briefly describe Windows. Windows and UNIX differ in a primary way in their respective programming models. A UNIX program contains code that does something or other, making system calls to have certain services performed. On the contrary, a Windows program is usually event driven. The main program waits for some event to happen, then calls a procedure to handle it. Typical events are keys being struck, the mouse being moved, a mouse button being pushed, or a CD-ROM inserted. Handlers are then called to process the event, update the screen and update the internal program state. All in all, this leads to a somewhat different style of programming than with UNIX, but since the focus of this book is on operating system function and structure, these different programming models will not concern us much more.

Certainly, Windows also has system calls. With UNIX, there is almost a one-to-one relationship between the system calls (e.g., read) and the library procedures (e.g., read) used to invoke the system calls. In other words, for each system call, there is roughly one library procedure that is called to invoke it, as indicated in "SYSTEM CALLS" figure. Moreover, POSIX has only about 100 procedure calls.

With Windows, the situation is completely different. To start with, the library calls and the actual system calls are highly decoupled. Microsoft has defined a set of procedures called the Win32 API (Application Program Interface) that programmers are expected to use to get operating system services. This interface is (partially) supported on all versions of Windows since Windows 95. By decoupling the interface from the actual system calls, Microsoft retains the ability to change the actual system calls in time (even from release to release) without invalidating existing programs.  What in fact forms Win32 is also slightly confusing because Windows 2000, Windows XP, and Windows Vista have many new calls that were not available in the past. In this section, Win32 means the interface supported by all versions of Windows.

The number of Win32 API calls is very large, numbering in the thousands. Moreover, while many of them do invoke system calls, a considerable number are executed entirely in user space. As a result, with Windows it is impossible to see what is a system call (i.e. performed by the kernel) and what is just a user-space library call. Actually, what is a system call in one version of Windows may be done in user space in a different version, and vice versa. When we discuss the Windows system calls in this blog, we will use the Win32 procedures (where appropriate) since Microsoft guarantees that these will be stable over time. But it should be remembered that not all of them are true system calls (i.e., traps to the kernel).

The Win32 API has a great number of calls for managing windows, geometric figures, text, fonts, scrollbars, dialog boxes, menus, and other features of the GUI. To the extent that the graphics subsystem runs in the kernel (true on some versions of Windows but not on all), these are system calls; otherwise they are simply library calls. Should we discuss these calls in this blog or not? Since they are not really related to the function of an operating system, we have decided not to, even though they may be carried out by the kernel. Readers interested in the Win32 API should consult one of the many books on the subject (e.g., Hart, 1997; Rector and Newcomer, 1997; and Simon, 1997).

Even introducing all the Win32 API calls here is out of the question, so we will limit ourselves to those calls that roughly correspond to the functionality of the UNIX calls listed in "System Calls for Process Management" figure (a). These are listed in the following figure.

We shall now briefly go through the list of the following figure. CreateProcess creates a new process. It does the combined work of fork and execve in UNIX. It has many parameters specifying the properties of the newly created process. Windows does not have a process hierarchy as UNIX does so there is no concept of a parent process and a child process. After a process is created, the creator and createe are equals. WaitForSingleObject is used to wait for an event. Many possible events can be waited for. If the parameter specifies a process, then the caller waits for the specified process to exit, which is done using ExitProcess.

The next six calls operate on files and are functionally similar to their UNIX counterparts although they differ in the parameters and details. Still, files can be opened, closed, read, and written pretty much as in UNIX. The SetFilePointer and GetFileAttributesEx calls set the file position and get some of the file attributes.

 The Win32 API calls that roughly correspond to the UNIX calls

Windows has directories and they are created with CreateDirectory and RemoveDirectory API calls, respectively. There is also a concept of a current directory, set by SetCurrentDirectory. The current time of day is obtained using GetLocalTime.

The Win32 interface does not have links to files, mounted file systems, security, or signals, so the calls corresponding to the UNIX ones do not exist. Obviously, Win32 has a great number of other calls that UNIX does not have, particularly for managing the GUI. And Windows Vista has an complicated security system and also supports file links.

One last note about Win32 is perhaps worth making. Win32 is not a terribly uniform or constant interface. The main problem here was the need to be backward compatible with the previous 16-bit interface used in Windows 3.x.



Tags

system calls, file system, process