Pages
Your First Windows Program
12:19 PM
Posted by Technovium
Now it’s time to do some coding. Let’s begin by looking at a very short Windows program and, for comparison, a short character-mode program. These will help us get oriented in using the development environment and going through the mechanics of creating and compiling a program.
A Character-Mode Model
Here’s the program that you’ll find in most of the programming books.
main () { printf ("hello, world\n") ; }
Yes, once upon a time C programmers used C run-time library functions such as printfwithout declaring them first. But this is the ’90s, and we like to give our compilers a fighting chance to flag errors in our code. Here’s the revised code from the second edition of K&R:
#include <stdio.h> main () { printf ("hello, world\n") ; }
This program still isn’t really as small as it seems. It will certainly compile and run just fine, but many programmers these days would prefer to explicitly indicate the return value of themain function, in which case ANSI C dictates that the function actually returns a value:
#include <stdio.h> int main () { printf ("hello, world\n") ; return 0 ; }
We could make this even longer by including the arguments to main, but let’s leave it at that—with an include statement, the program entry point, a call to a run-time library function, and a return statement.
The Windows Equivalent
The Windows equivalent to the “hello, world” program has exactly the same components as the character-mode version. It has an include statement, a program entry point, a function call, and a return statement. Here’s the program:
/*-------------------------------------------------------------- Helloprog.c -- Displays "Hello, Windows 98!" in a message box (c) code name Sammy , 2010 --------------------------------------------------------------*/ #include <windows.h> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("Helloprog"), 0) ; return 0 ; }
Before I begin dissecting this program, let’s go through the mechanics of creating a program in the Visual C++ Developer Studio.
To begin, select New from the File menu. In the New dialog box, pick the Projects tab. Select Win32 Application. In the Location field, select a subdirectory. In the Project Name field, type the name of the project, which in this case is Helloprog. This will be a subdirectory of the directory indicated in the Location field. The Create New Workspace button should be checked. The Platforms section should indicate Win32. Choose OK.
A dialog box labeled Win32 Application – Step 1 Of 1 will appear. Indicate that you want to create an Empty Project, and press the Finish button.
Select New from the File menu again. In the New dialog box, pick the Files tab. Select C++ Source File. The Add To Project box should be checked, and Helloprog should be indicated. Type Hellorpog.c in the File Name field. Choose OK.
Structurally, HELLOMSG.C is identical to the K&R “hello, world” program. The header file STDIO.H has been replaced with WINDOWS.H, the entry point main has been replaced withWinMain, and the C run-time library function printf has been replaced with the Windows API function MessageBox. However, there is much in the program that is new, including several strange-looking uppercase identifiers.
Let’s start at the top.
The Header Files
HELLOMSG.C begins with a preprocessor directive that you’ll find at the top of virtually every Windows program written in C:
#include <windows.h>WINDOWS.H is a master include file that includes other Windows header files, some of which also include other header files. The most important and most basic of these header files are:
- WINDEF.H Basic type definitions.
- WINNT.H Type definitions for Unicode support.
- WINBASE.H Kernel functions.
- WINUSER.H User interface functions.
- WINGDI.H Graphics device interface functions.
These header files define all the Windows data types, function calls, data structures, and constant identifiers. They are an important part of Windows documentation. You might find it convenient to use the Find In Files option from the Edit menu in the Visual C++ Developer Studio to search through these header files. You can also open the header files in the Developer Studio and examine them directly.
Program Entry Point
Just as the entry point to a C program is the function main, the entry point to a Windows program is WinMain, which always appears like this:
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
This entry point is documented in /Platform SDK/User Interface Services/Windowing/Windows/Window Reference/Window Functions. It is declared in WINBASE.H like so (line breaks and all):
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd );
You’ll notice I’ve made a couple of minor changes in HELLOMSG.C. The third parameter is defined as an LPSTR in WINBASE.H, and I’ve made it a PSTR. These two data types are both defined in WINNT.H as pointers to character strings. The LP prefix stands for “long pointer” and is an artifact of 16-bit Windows.
I’ve also changed two of the parameter names from the WinMain declaration; many Windows programs use a system called “Hungarian notation” for naming variables. This system involves prefacing the variable name with a short prefix that indicates the variable’s data type. I’ll discuss this concept more in my further post. For now, just keep in mind that the prefix i stands for int and sz stands for “string terminated with a zero.”
The WinMain function is declared as returning an int. The WINAPI identifier is defined in WINDEF.H with the statement:
#define WINAPI __stdcallThis statement specifies a calling convention that involves how machine code is generated to place function call arguments on the stack. Most Windows function calls are declared as WINAPI.
The first parameter to WinMain is something called an “instance handle.” In Windows programming, a handle is simply a number that an application uses to identify something. In this case, the handle uniquely identifies the program. It is required as an argument to some other Windows function calls. In early versions of Windows, when you ran the same program concurrently more than once, you created multiple instances of that program. All instances of the same application shared code and read-only memory (usually resources such as menu and dialog box templates). A program could determine if other instances of itself were running by checking the hPrevInstance parameter. It could then skip certain chores and move some data from the previous instance into its own data area.
In the 32-bit versions of Windows, this concept has been abandoned. The second parameter to WinMain is always NULL (defined as 0).
The third parameter to WinMain is the command line used to run the program. Some Windows applications use this to load a file into memory when the program is started. The fourth parameter to WinMain indicates how the program should be initially displayed—either normally or maximized to fill the window, or minimized to be displayed in the task list bar.
The MessageBox Function
The MessageBox function is designed to display short messages. The little window thatMessageBox displays is actually considered to be a dialog box, although not one with a lot of versatility.
The first argument to MessageBox is normally a window handle. The second argument is the text string that appears in the body of the message box, and the third argument is the text string that appears in the caption bar of the message box. In HELLMSG.C, each of these text strings is enclosed in a TEXT macro. You don’t normally have to enclose all character strings in the TEXT macro, but it’s a good idea if you want to be ready to convert your programs to the Unicode character set. The fourth argument to MessageBox can be a combination of constants beginning with the prefix MB_ that are defined in WINUSER.H. You can pick one constant from the first set to indicate what buttons you wish to appear in the dialog box:
#define MB_OK 0x00000000L #define MB_OKCANCEL 0x00000001L #define MB_ABORTRETRYIGNORE 0x00000002L #define MB_YESNOCANCEL 0x00000003L #define MB_YESNO 0x00000004L #define MB_RETRYCANCEL 0x00000005L
When you set the fourth argument to 0 in HELLOMSG, only the OK button appears. You can use the C OR (|) operator to combine one of the constants shown above with a constant that indicates which of the buttons is the default:
#define MB_DEFBUTTON1 0x00000000L #define MB_DEFBUTTON2 0x00000100L #define MB_DEFBUTTON3 0x00000200L #define MB_DEFBUTTON4 0x00000300L
You can also use a constant that indicates the appearance of an icon in the message box:
#define MB_ICONHAND 0x00000010L #define MB_ICONQUESTION 0x00000020L #define MB_ICONEXCLAMATION 0x00000030L #define MB_ICONASTERISK 0x00000040L
Some of these icons have alternate names:
#define MB_ICONWARNING MB_ICONEXCLAMATION #define MB_ICONERROR MB_ICONHAND #define MB_ICONINFORMATION MB_ICONASTERISK #define MB_ICONSTOP MB_ICONHAND
There are a few other MB_ constants, but you can consult the header file yourself or the documentation in /Platform SDK/User Interface Services/Windowing/Dialog Boxes/Dialog Box Reference/Dialog Box Functions.
In this program, the MessageBox function returns the value 1, but it’s more proper to say that it returns IDOK, which is defined in WINUSER.H as equaling 1. Depending on the other buttons present in the message box, the MessageBox function can also return IDYES, IDNO, IDCANCEL, IDABORT, IDRETRY, or IDIGNORE.
Is this little Windows program really the equivalent of the K&R “hello, world” program? Well, you might think not because the MessageBox function doesn’t really have all the potential formatting power of the printf function in “hello, world.” But we’ll see in the next chapter how to write a version of MessageBox that does printf-like formatting.
Compile, Link, and Run
When you’re ready to compile HELLOMSG, you can select Build Hellomsg.exe from the Build menu, or press F7, or select the Build icon from the Build toolbar. (The appearance of this icon is shown in the Build menu. If the Build toolbar is not currently displayed, you can choose Customize from the Tools menu and select the Toolbars tab. Pick Build or Build MiniBar.)
Alternatively, you can select Execute Hellomsg.exe from the Build menu, or press Ctrl+F5, or click the Execute Program icon (which looks like a red exclamation point) from the Build toolbar. You’ll get a message box asking you if you want to build the program.
As normal, during the compile stage, the compiler generates an .OBJ (object) file from the C source code file. During the link stage, the linker combines the .OBJ file with .LIB (library) files to create the .EXE (executable) file. You can see a list of these library files by selecting Settings from the Project tab and clicking the Link tab. In particular, you’ll notice KERNEL32.LIB, USER32.LIB, and GDI32.LIB. These are “import libraries” for the three major Windows subsystems. They contain the dynamic-link library names and reference information that is bound into the .EXE file. Windows uses this information to resolve calls from the program to functions in the KERNEL32.DLL, USER32.DLL, and GDI32.DLL dynamic-link libraries.
In the Visual C++ Developer Studio, you can compile and link the program in different configurations. By default, these are called Debug and Release. The executable files are stored in subdirectories of these names. In the Debug configuration, information is added to the .EXE file that assists in debugging the program and in tracing through the program source code.
If you prefer working on the command line, the companion CD-ROM contains .MAK (make) files for all the sample programs. (You can tell the Developer Studio to generate make files by choosing Options from the Tools menu and selecting the Build tab. There’s a check box to check.) You’ll need to run VCVARS32.BAT located in the BIN subdirectory of the Developer Studio to set environment variables. To execute the make file from the command line, change to the HELLOMSG directory and execute:
NMAKE /f HelloMsg.mak CFG="HelloMsg _ Win32 Debug"or
NMAKE /f HelloMsg.mak CFG="HelloMsg _ Win32 Release"You can then run the .EXE file from the command line by typing:
DEBUG\HELLOMSG
Windows Programming Options
12:18 PM
Posted by Technovium
To illustrate the various techniques of Windows programming, this post has lots of sample programs. These programs are written in C and use the native Windows APIs. I think of this approach as “classical” Windows programming. It is how we wrote programs for Windows 1.0 in 1985, and it remains a valid way of programming for Windows today.
APIs and Memory Models
To a programmer, an operating system is defined by its API. An API encompasses all the function calls that an application program can make of an operating system, as well as definitions of associated data types and structures. In Windows, the API also implies a particular program architecture that we’ll explore in the chapters ahead.
Generally, the Windows API has remained quite consistent since Windows 1.0. A Windows programmer with experience in Windows 98 would find the source code for a Windows 1.0 program very familiar. One way the API has changed has been in enhancements. Windows 1.0 supported fewer than 450 function calls; today there are thousands.
The biggest change in the Windows API and its syntax came about during the switch from a 16-bit architecture to a 32-bit architecture. Versions 1.0 through 3.1 of Windows used the so-called segmented memory mode of the 16-bit Intel 8086, 8088, and 286 microprocessors, a mode that was also supported for compatibility purposes in the 32-bit Intel microprocessors beginning with the 386. The microprocessor register size in this mode was 16 bits, and hence the C int data type was also 16 bits wide. In the segmented memory model, memory addresses were formed from two components—a 16-bit segment pointer and a 16-bit offset pointer. From the programmer’s perspective, this was quite messy and involved differentiating between long, or far, pointers (which involved both a segment address and an offset address) and short, or near, pointers (which involved an offset address with an assumed segment address).
Beginning in Windows NT and Windows 95, Windows supported a 32-bit flat memory model using the 32-bit modes of the Intel 386, 486, and Pentium processors. The C int data type was promoted to a 32-bit value. Programs written for 32-bit versions of Windows use simple 32-bit pointer values that address a flat linear address space.
The API for the 16-bit versions of Windows (Windows 1.0 through Windows 3.1) is now known as Win16. The API for the 32-bit versions of Windows (Windows 95, Windows 98, and all versions of Windows NT) is now known as Win32. Many function calls remained the same in the transition from Win16 to Win32, but some needed to be enhanced. For example, graphics coordinate points changed from 16-bit values in Win16 to 32-bit values in Win32. Also, some Win16 function calls returned a two-dimensional coordinate point packed in a 32-bit integer. This was not possible in Win32, so new function calls were added that worked in a different way.
All 32-bit versions of Windows support both the Win16 API to ensure compatibility with old applications and the Win32 API to run new applications. Interestingly enough, this works differently in Windows NT than in Windows 95 and Windows 98. In Windows NT, Win16 function calls go through a translation layer and are converted to Win32 function calls that are then processed by the operating system. In Windows 95 and Windows 98, the process is opposite that: Win32 function calls go through a translation layer and are converted to Win16 function calls to be processed by the operating system.
At one time, there were two other Windows API sets (at least in name). Win32s (“s” for “subset”) was an API that allowed programmers to write 32-bit applications that ran under Windows 3.1. This API supported only 32-bit versions of functions already supported by Win16. Also, the Windows 95 API was once called Win32c (“c” for “compatibility”), but this term has been abandoned.
At this time, Windows NT and Windows 98 are both considered to support the Win32 API. However, each operating system supports some features not supported by the other. Still, because the overlap is considerable, it’s possible to write programs that run under both systems. Also, it’s widely assumed that the two products will be merged at some time in the future.
Language Options
Using C and the native APIs is not the only way to write programs for Windows. However, this approach offers you the best performance, the most power, and the greatest versatility in exploiting the features of Windows. Executables are relatively small and don’t require external libraries to run (except for the Windows DLLs themselves, of course). Most importantly, becoming familiar with the API provides you with a deeper understanding of Windows internals, regardless of how you eventually write applications for Windows.
Although I think that learning classical Windows programming is important for any Windows programmer, I don’t necessarily recommend using C and the API for every Windows application. Many programmers—particularly those doing in-house corporate programming or those who do recreational programming at home—enjoy the ease of development environments such as Microsoft Visual Basic or Borland Delphi (which incorporates an object-oriented dialect of Pascal). These environments allow a programmer to focus on the user interface of an application and associate code with user interface objects. To learn Visual Basic, you might want to consult some other Microsoft Press books, such as Learn Visual Basic Now (1996), by Michael Halvorson.
Among professional programmers—particularly those who write commercial applications—Microsoft Visual C++ with the Microsoft Foundation Class Library (MFC) has been a popular alternative in recent years. MFC encapsulates many of the messier aspects of Windows programming in a collection of C++ classes. Jeff Prosise’s Programming Windows with MFC, Second Edition (Microsoft Press, 1999) provides tutorials on MFC.
Most recently, the popularity of the Internet and the World Wide Web has given a big boost to Sun Microsystems’ Java, the processor-independent language inspired by C++ and incorporating a toolkit for writing graphical applications that will run on several operating system platforms. A good Microsoft Press book on Microsoft J++, Microsoft’s Java development tool, is Programming Visual J++ 6.0 (1998), by Stephen R. Davis.
Obviously, there’s hardly any one right way to write applications for Windows. More than anything else, the nature of the application itself should probably dictate the tools. But learning the Windows API gives you vital insights into the workings of Windows that are essential regardless of what you end up using to actually do the coding. Windows is a complex system; putting a programming layer on top of the API doesn’t eliminate the complexity—it merely hides it. Sooner or later that complexity is going to jump out and bite you in the leg. Knowing the API gives you a better chance at recovery.
Any software layer on top of the native Windows API necessarily restricts you to a subset of full functionality. You might find, for example, that Visual Basic is ideal for your application except that it doesn’t allow you to do one or two essential chores. In that case, you’ll have to use native API calls. The API defines the universe in which we as Windows programmers exist. No approach can be more powerful or versatile than using this API directly.
MFC is particularly problematic. While it simplifies some jobs immensely (such as OLE), I often find myself wrestling with other features (such as the Document/View architecture) to get them to work as I want. MFC has not been the Windows programming panacea that many hoped for, and few people would characterize it as a model of good object-oriented design. MFC programmers benefit greatly from understanding what’s going on in class definitions they use, and find themselves frequently consulting MFC source code. Understanding that source code is one of the benefits of learning the Windows API.
The Programming Environment
In this post,I’ll be assuming that you’re running Microsoft Visual C++ 6.0, which comes in Standard, Professional, and Enterprise editions. The less-expensive Standard edition is fine for doing the programs. Visual C++ is also part of Visual Studio 6.0.
The Microsoft Visual C++ package includes more than the C compiler and other files and tools necessary to compile and link Windows programs. It also includes the Visual C++ Developer Studio, an environment in which you can edit your source code; interactively create resources such as icons and dialog boxes; and edit, compile, run, and debug your programs.
If you’re running Visual C++ 5.0, you might need to get updated header files and import libraries for Windows 98 and Windows NT 5.0. These are available at Microsoft’s web site. Go to http://www.microsoft.com/msdn/, and choose Downloads and then Platform SDK (“software development kit”). You’ll be able to download and install the updated files in directories of your choice. To direct the Microsoft Developer Studio to look in these directories, choose Options from the Tools menu and then pick the Directories tab.
The msdn portion of the Microsoft URL above stands for Microsoft Developer Network. This is a program that provides developers with frequently updated CD-ROMs containing much of what they need to be on the cutting edge of Windows development. You’ll probably want to investigate subscribing to MSDN and avoid frequent downloading from Microsoft’s web site.
API Documentation
This post is not a substitute for the official formal documentation of the Windows API. That documentation is no longer published in printed form; it is available only via CD-ROM or the Internet.
When you install Visual C++ 6.0, you’ll get an online help system that includes API documentation. You can get updates to that documentation by subscribing to MSDN or by using Microsoft’s Web-based online help system. Start by linking tohttp://www.microsoft.com/msdn/, and select MSDN Library Online.
In Visual C++ 6.0, select the Contents item from the Help menu to invoke the MSDN window. The API documentation is organized in a tree-structured hierarchy. Find the section labeled Platform SDK. All the documentation I’ll be citing in this post is from this section. I’ll show the location of documentation using the nested levels starting with Platform SDK separated by slashes. (I know the Platform SDK looks like a small obscure part of the total wealth of MSDN knowledge, but I assure you that it’s the essential core of Windows programming.) For example, for documentation on how to use the mouse in your Windows programs, you can consult /Platform SDK/User Interface Services/User Input/Mouse Input.
I mentioned before that much of Windows is divided into the Kernel, User, and GDI subsystems. The kernel interfaces are in /Platform SDK/Windows Base Services, the user interface functions are in /Platform SDK/User Interface Services, and GDI is documented in/Platform SDK/Graphics and Multimedia Services/GDI.
The Windows Environment
12:17 PM
Posted by Technovium
Windows hardly needs an introduction. Yet it’s easy to forget the sea change that Windows brought to office and home desktop computing. Windows had a bumpy ride in its early years and was hardly destined to conquer the desktop market.
A History of Windows
Soon after the introduction of the IBM PC in the fall of 1981, it became evident that the predominant operating system for the PC (and compatibles) would be MS-DOS, which originally stood for Microsoft Disk Operating System. MS-DOS was a minimal operating system. For the user, MS-DOS provided a command-line interface to commands such as DIR and TYPE and loaded application programs into memory for execution. For the application programmer, MS-DOS offered little more than a set of function calls for doing file input/output (I/O). For other tasks—in particular, writing text and sometimes graphics to the video display—applications accessed the hardware of the PC directly.
Due to memory and hardware constraints, sophisticated graphical environments were slow in coming to small computers. Apple Computer offered an alternative to character-mode environments when it released its ill-fated Lisa in January 1983, and then set a standard for graphical environments with the Macintosh in January 1984. Despite the Mac’s declining market share, it is still considered the standard against which other graphical environments are measured. All graphical environments, including the Macintosh and Windows, are indebted to the pioneering work done at the Xerox Palo Alto Research Center (PARC) beginning in the mid-1970s.
Windows was announced by Microsoft Corporation in November 1983 (post-Lisa but pre-Macintosh) and was released two years later in November 1985. Over the next two years, Microsoft Windows 1.0 was followed by several updates to support the international market and to provide drivers for additional video displays and printers.
Windows 2.0 was released in November 1987. This version incorporated several changes to the user interface. The most significant of these changes involved the use of overlapping windows rather than the “tiled” windows found in Windows 1.0. Windows 2.0 also included enhancements to the keyboard and mouse interface, particularly for menus and dialog boxes.
Up until this time, Windows required only an Intel 8086 or 8088 microprocessor running in “real mode” to access 1 megabyte (MB) of memory. Windows/386 (released shortly after Windows 2.0) used the “virtual 86″ mode of the Intel 386 microprocessor to window and multitask many DOS programs that directly accessed hardware. For symmetry, Windows 2.1 was renamed Windows/286.
Windows 3.0 was introduced on May 22, 1990. The earlier Windows/286 and Windows/386 versions were merged into one product with this release. The big change in Windows 3.0 was the support of the 16-bit protected-mode operation of Intel’s 286, 386, and 486 microprocessors. This gave Windows and Windows applications access to up to 16 megabytes of memory. The Windows “shell” programs for running programs and maintaining files were completely revamped. Windows 3.0 was the first version of Windows to gain a foothold in the home and the office.
Any history of Windows must also include a mention of OS/2, an alternative to DOS and Windows that was originally developed by Microsoft in collaboration with IBM. OS/2 1.0 (character-mode only) ran on the Intel 286 (or later) microprocessors and was released in late 1987. The graphical Presentation Manager (PM) came about with OS/2 1.1 in October 1988. PM was originally supposed to be a protected-mode version of Windows, but the graphical API was changed to such a degree that it proved difficult for software manufacturers to support both platforms.
By September 1990, conflicts between IBM and Microsoft reached a peak and required that the two companies go their separate ways. IBM took over OS/2 and Microsoft made it clear that Windows was the center of their strategy for operating systems. While OS/2 still has some fervent admirers, it has not nearly approached the popularity of Windows.
Microsoft Windows version 3.1 was released in April 1992. Several significant features included the TrueType font technology (which brought scaleable outline fonts to Windows), multimedia (sound and music), Object Linking and Embedding (OLE), and standardized common dialog boxes. Windows 3.1 ran only in protected mode and required a 286 or 386 processor with at least 1 MB of memory.
Windows NT, introduced in July 1993, was the first version of Windows to support the 32-bit mode of the Intel 386, 486, and Pentium microprocessors. Programs that run under Windows NT have access to a 32-bit flat address space and use a 32-bit instruction set. (I’ll have more to say about address spaces a little later in this chapter.) Windows NT was also designed to be portable to non-Intel processors, and it runs on several RISC-based workstations.
Windows 95 was introduced in August 1995. Like Windows NT, Windows 95 also supported the 32-bit programming mode of the Intel 386 and later microprocessors. Although it lacked some of the features of Windows NT, such as high security and portability to RISC machines, Windows 95 had the advantage of requiring fewer hardware resources.
Windows 98 was released in June 1998 and has a number of enhancements, including performance improvements, better hardware support, and a closer integration with the Internet and the World Wide Web.
Aspects of Windows
Both Windows 98 and Windows NT are 32-bit preemptive multitasking and multithreading graphical operating systems. Windows possesses a graphical user interface (GUI), sometimes also called a “visual interface” or “graphical windowing environment.” The concepts behind the GUI date from the mid-1970s with the work done at the Xerox PARC for machines such as the Alto and the Star and for environments such as SmallTalk. This work was later brought into the mainstream and popularized by Apple Computer and Microsoft. Although somewhat controversial for a while, it is now quite obvious that the GUI is (in the words of Microsoft’s Charles Simonyi) the single most important “grand consensus” of the personal-computer industry.
All GUIs make use of graphics on a bitmapped video display. Graphics provides better utilization of screen real estate, a visually rich environment for conveying information, and the possibility of a WYSIWYG (what you see is what you get) video display of graphics and formatted text prepared for a printed document.
In earlier days, the video display was used solely to echo text that the user typed using the keyboard. In a graphical user interface, the video display itself becomes a source of user input. The video display shows various graphical objects in the form of icons and input devices such as buttons and scroll bars. Using the keyboard (or, more directly, a pointing device such as a mouse), the user can directly manipulate these objects on the screen. Graphics objects can be dragged, buttons can be pushed, and scroll bars can be scrolled.
The interaction between the user and a program thus becomes more intimate. Rather than the one-way cycle of information from the keyboard to the program to the video display, the user directly interacts with the objects on the display.
Users no longer expect to spend long periods of time learning how to use the computer or mastering a new program. Windows helps because all applications have the same fundamental look and feel. The program occupies a window—usually a rectangular area on the screen. Each window is identified by a caption bar. Most program functions are initiated through the program’s menus. A user can view the display of information too large to fit on a single screen by using scroll bars. Some menu items invoke dialog boxes, into which the user enters additional information. One dialog box in particular, that used to open a file, can be found in almost every large Windows program. This dialog box looks the same (or nearly the same) in all of these Windows programs, and it is almost always invoked from the same menu option.
Once you know how to use one Windows program, you’re in a good position to easily learn another. The menus and dialog boxes allow a user to experiment with a new program and explore its features. Most Windows programs have both a keyboard interface and a mouse interface. Although most functions of Windows programs can be controlled through the keyboard, using the mouse is often easier for many chores.
From the programmer’s perspective, the consistent user interface results from using the routines built into Windows for constructing menus and dialog boxes. All menus have the same keyboard and mouse interface because Windows—rather than the application program—handles this job.
To facilitate the use of multiple programs, and the exchange of information among them, Windows supports multitasking. Several Windows programs can be displayed and running at the same time. Each program occupies a window on the screen. The user can move the windows around on the screen, change their sizes, switch between different programs, and transfer data from one program to another. Because these windows look something like papers on a desktop (in the days before the desk became dominated by the computer itself, of course), Windows is sometimes said to use a “desktop metaphor” for the display of multiple programs.
Earlier versions of Windows used a system of multitasking called “nonpreemptive.” This meant that Windows did not use the system timer to slice processing time between the various programs running under the system. The programs themselves had to voluntarily give up control so that other programs could run. Under Windows NT and Windows 98, multitasking is preemptive and programs themselves can split into multiple threads of execution that seem to run concurrently.
An operating system cannot implement multitasking without doing something about memory management. As new programs are started up and old ones terminate, memory can become fragmented. The system must be able to consolidate free memory space. This requires the system to move blocks of code and data in memory.
Even Windows 1.0, running on an 8088 microprocessor, was able to perform this type of memory management. Under real-mode restrictions, this ability can only be regarded as an astonishing feat of software engineering. In Windows 1.0, the 640-kilobyte (KB) memory limit of the PC’s architecture was effectively stretched without requiring any additional memory. But Microsoft didn’t stop there: Windows 2.0 gave the Windows applications access to expanded memory (EMS), and Windows 3.0 ran in protected mode to give Windows applications access to up to 16 MB of extended memory. Windows NT and Windows 98 blow away these old limits by being full-fledged 32-bit operating systems with flat memory space.
Programs running in Windows can share routines that are located in other files called “dynamic-link libraries.” Windows includes a mechanism to link the program with the routines in the dynamic-link libraries at run time. Windows itself is basically a set of dynamic-link libraries.
Windows is a graphical interface, and Windows programs can make full use of graphics and formatted text on both the video display and the printer. A graphical interface not only is more attractive in appearance but also can impart a high level of information to the user.
Programs written for Windows do not directly access the hardware of graphics display devices such as the screen and printer. Instead, Windows includes a graphics programming language (called the Graphics Device Interface, or GDI) that allows the easy display of graphics and formatted text. Windows virtualizes display hardware. A program written for Windows will run with any video board or any printer for which a Windows device driver is available. The program does not need to determine what type of device is attached to the system.
Putting a device-independent graphics interface on the IBM PC was not an easy job for the developers of Windows. The PC design was based on the principle of open architecture. Third-party hardware manufacturers were encouraged to develop peripherals for the PC and have done so in great number. Although several standards have emerged, conventional MS-DOS programs for the PC had to individually support many different hardware configurations. It was fairly common for an MS-DOS word-processing program to be sold with one or two disks of small files, each one supporting a particular printer. Windows programs do not require these drivers because the support is part of Windows.
Dynamic Linking
Central to the workings of Windows is a concept known as “dynamic linking.” Windows provides a wealth of function calls that an application can take advantage of, mostly to implement its user interface and display text and graphics on the video display. These functions are implemented in dynamic-link libraries, or DLLs. These are files with the extension .DLL or sometimes .EXE, and they are mostly located in the \WINDOWS\SYSTEM subdirectory under Windows 98 and the \WINNT\SYSTEM and \WINNT\SYSTEM32 subdirectories under Windows NT.
In the early days, the great bulk of Windows was implemented in just three dynamic-link libraries. These represented the three main subsystems of Windows, which were referred to as Kernel, User, and GDI. While the number of subsystems has proliferated in recent versions of Windows, most function calls that a typical Windows program makes will still fall in one of these three modules. Kernel (which is currently implemented by the 16-bit KRNL386.EXE and the 32-bit KERNEL32.DLL) handles all the stuff that an operating system kernel traditionally handles—memory management, file I/O, and tasking. User (implemented in the 16-bit USER.EXE and the 32-bit USER32.DLL) refers to the user interface, and implements all the windowing logic. GDI (implemented in the 16-bit GDI.EXE and the 32-bit GDI32.DLL) is the Graphics Device Interface, which allows a program to display text and graphics on the screen and printer.
Windows 98 supports several thousand function calls that applications can use. Each function has a descriptive name, such as CreateWindow. This function (as you might guess) creates a window for your program. All the Windows functions that an application may use are declared in header files.
In your Windows program, you use the Windows function calls in generally the same way you use C library functions such as strlen. The primary difference is that the machine code for C library functions is linked into your program code, whereas the code for Windows functions is located outside of your program in the DLLs.
When you run a Windows program, it interfaces to Windows through a process called “dynamic linking.” A Windows .EXE file contains references to the various dynamic-link libraries it uses and the functions therein. When a Windows program is loaded into memory, the calls in the program are resolved to point to the entries of the DLL functions, which are also loaded into memory if not already there.
When you link a Windows program to produce an executable file, you must link with special “import libraries” provided with your programming environment. These import libraries contain the dynamic-link library names and reference information for all the Windows function calls. The linker uses this information to construct the table in the .EXE file that Windows uses to resolve calls to Windows functions when loading the program.
Subscribe to:
Posts (Atom)