A Word about Windows



Windows programs are fundamentally different in almost every way from DOS programs. In traditional DOS programs, you have 100 percent of the processor time, 100 percent control over all the devices and files in the machine. You also need an intimate knowledge of all of the devices on a user's machine (you probably remember old DOS games, which almost always required you to input DMA and IRQ settings for sound cards). When a game crashed, you didn't need to worry too much about leaving things in a state for the machine to piece itself together; the user could just reboot. Some old 320x200x256 games would crash without even changing the video mode back to normal, leaving the user screen full of oversized text with the crash information.
In Windows, things are totally different. When your application is running, it is sharing the processor with many other tasks, all running concurrently (at the same time). You can't hog control of the sound card, the video card, the hard disk, or any other system resource for that matter. The input and output is abstracted away, and you don't poll the keyboard or mess with interrupts; Windows manages all that for you.
This is both a good and bad thing. On one hand, Windows applications have a consistent look and feel. Unless you want to get picky, almost any window you create is automatically familiar to Windows users. They already know how to use menus and toolbars, so if you build your application with the basic Windows constructs, they can pick up the user interface quickly. Also, a lot of mundane GUI tasks are completely handled by the Windows API, such as displaying complex property pages, freeing you to write the interesting code.
Aside "Reinventing the wheel," or rewriting existing code, can make sense sometimes, especially when writing games. However, not on the scale of operating systems; nobody wants to reimplement the functionality of the Windows API.
On the other hand, you have to put a lot of faith into Windows and other applications. Until DirectX came around, you needed to use the default Windows drawing commands (called the GDI). While the GDI can automatically handle any bit depth and work on any monitor, it's not the speediest thing in the world. (In fact it is probably the slowest!) For this reason, many DOS developers swore off ever working in Windows. Pretty much the best you could do with graphics was rendering onto a bitmap that was then drawn into a window, which is pretty slow. You used to have to give up a lot when writing a Windows application.
However, there are a lot of things that Windows can do that would be a nightmare to code in the old world of DOS. You can play sound effects using a single line of code (the PlaySound function), query the time stamp counter, use a robust TCP/IP network stack, get access to virtual memory, and the list goes on. Even though you have to take a few speed hits here and there, the advantages of Windows far outweigh the disadvantages.
I'll be using the Win32 environment to write all of the applications for this book. Win32 is not a programming language; it is an application programming interface (API). In other words, it is a set of C functions that an application uses to make a Windows-compliant program. It abstracts away a lot of difficult operations like multitasking and protected memory, as well as providing interfaces to higher-level concepts. Supporting menus, dialog boxes, and multimedia have well-established, fairly easy-to-use (you may not believe me about this!) library functions written for that specific task.
Windows is an extremely broad set of APIs. You can do just about anything, from playing videos to loading web pages. And for every task, there are a slew of different ways to accomplish it. There are some seriously large books devoted just to the more rudimentary concepts of Windows programming. Subsequently, the discussion here will be limited to what is relevant to allow you to continue on with the rest of the book. Instead of covering the tomes of knowledge required to set up dialogs with tree controls, print documents, and read/write keys in the registry, I'm going to deal with the simplest case: creating a window that can draw the world, passing input to the program, and having at least the beginnings of a pleasant relationship with the operating system. If you need any more info, there are many good resources out there on Windows programming.

Post a comment

0 Comments