CS-360 Fall, 2000 Class 0 R. Eckert An Introduction to GUI and Windows Programming User Interfaces-- User interfaces provide a connection between the computer and the user. There are two principal types of user interfaces: Command Line Interfaces and Graphical User Interfaces (GUI). Command Line Interfaces-- Command line interfaces are text-based. The user types in commands and the system responds. PC-DOS is a good example of a system with a command line interface. A disadvantage to command line interfaces is the fact that the user must remember what the commands are. Also, in some cases, the result of entering a command is a rapidly-scrolling screen that cannot be understood (e.g., the DOS DIR command). Command line interfaces can be interactive (e.g., the DOS HELP command), but again the user must remember what the commands are and how to use them. And, in general, if the user types a wrong command, the system will respond with some cryptic, unfriendly message (e.g., "Bad command or file name" in response to an illegal DOS command). Also, there is little direct interaction between the user and what is displayed on the screen. The flow of information is from the keyboard to the program to the display. The user can't "point and click" directly at objects on the screen and have something happen as a result. Graphical (Visual) User Interfaces-- GUIs display graphical objects (images, icons, buttons, scroll bars, etc.) on the screen. The user interacts by using a pointing device (often a mouse) and clicking on or dragging objects displayed on the screen. This leads to an intimate, intuitive, direct interaction and can also lead to a better use of screen real estate. Different areas (panes) can be associated with different activities and can overlap. Underlying panes can be brought to the top (<Alt>-<Tab> or <Alt>-<Esc> in Windows). Modern graphical interfaces use a Desktop Metaphor in which window panes containing work activities are like papers on a desk. Well, not exactly, since most desktops don't have objects that jump out at the user when he/she pokes them! GUIs make extensive use of computer graphics to organize the user's workspace. They present the user intuitive ways of accomplishing tasks. For example files can be copied by "dragging" them from one "folder" to another in a manner reminiscent of a person picking up a paper and carrying it to a filing cabinet. GUI environments allow many tasks to be performed simultaneously. The windows associated with different tasks share screen space. Because of the extensive use of graphics images, GUIs provide a visually rich way of conveying information. In many cases they provide a "What You See Is What You Get" (WYSIWYG) display of documents. Main Feature of a GUI: The Window-- This is a rectangular area of the screen onto which a program draws text and graphics. The user interacts with a program by using a pointer device to select objects inside the window area. Some components of a window are: the window border, the title bar, the client area, the menu bar, scroll bars, maximize/minimize/close/System Menu and other buttons, tool bars with icons, tool tips, etc. A Brief History of GUIs-- In 1968 Doug Engelbart of the Stanford Research Center's Augmentation Research Center, funded by the Department of Defense's Advanced Research Projects Agency (ARPA), implemented the first windowing system. In this system, the display screen was sliced up into stacks of overlapping "window panes", each of which could display textual information. This saved on screen space. The system permitted underlying windows to be brought to the top. Window selection was done with a light pen. This device was imprecise and unreliable, so Engelbart invented the mouse. In 1970, researchers at the Xerox Palo Alto Research Center (PARC) designed the first true GUI-based computer, the Alto Computer. In this system a cursor on the screen tracked the position of the mouse. Text was displayed very precisely within windows on the screen, thus providing a WYSIWYG feel. Nontextual information could be displayed as well. At the same time the PARC people also designed and implemented the first painting program which ran on the Alto computer. As a result of this and other graphics-oriented work, Xerox PARC became the center of the graphical computing universe at that time. More recently, in 1983, Apple came out with the Lisa computer. This was the first personal computer with a graphical user interface. The system was a failure. The following year Apple came out with the first Macintosh, which set the standard for personal computer GUIs. In 1985, Microsoft released its Windows 1.0 operating system for IBM-PCs based on the Intel 8086 microprocessor. The system was built on top of the DOS operating system and proved very difficult to program and use. It was also prone to crashing the system. It was amazing that the first Windows OS worked at all, given the limitations of the 8086 and DOS (64K memory segments, real mode addressing only, 640 Kbyte memory limit, etc.) The system needed hardware that wasn't yet available. In 1987 Microsoft released Windows 2.0, which was still a real mode system, although it ran on the Intel 80286 processor. The following year Microsoft released Windows/386, which was supposed to take advantage of the Intel 80386 processor's Virtual 86 addressing mode. This allowed for multiple DOS sessions, each running in a separate window. In 1990 Microsoft released Windows 3.0--the first Windows system to use the power of the 80x86 processor's protected virtual addressing mode. This permitted use of up to 16 Mbytes of memory and cooperative multitasking (see below). Windows 3.0 was Microsoft's first "successful" windowing operating system. In 1992 Microsoft released Windows 3.1, which enhanced its predecessor by adding scalable TrueType fonts and incorporated many multimedia features. Windows 3.1 ran only in protected mode. About a year later, Windows for Workgroups 3.11, a networking version of 3.1, was released. In 1993 Microsoft released its first version of Windows NT (which stands for "New Technology" or "NeTwork", depending on whom you believe). It used Intel's 32-bit flat memory model (requiring, at the minimum, a 80386-based PC with 16 Mbyes of RAM and 70 MBytes of disk space) and thread-based, pre-emptive multitasking (see below). This was the first version of Windows that did not depend on DOS; it was a separate operating system. Because of the facts that NT can also run on several RISC-based workstations and has many built-in protection and security mechanisms as well as extensive network support, it has been and continues to be used extensively in networked environments. Windows NT has shown itself to be quite reliable and stable. In 1995, Microsoft released Windows 95, which offered many enhancements over Windows 3.1. Some of these are: 32-bit threaded, pre-emptive multitasking (as in NT); long file names; plug and play; new common dialog boxes; new window controls; multiple character set support; a new help system; a new desktop and window style. Because of these and other new features, Windows 95 has a different look and feel from Windows 3.1. For several reasons, including the facts that Windows 95 still runs under DOS (although not obviously) and still retains a large amount of 16-bit code (for backward compatibility), Windows 95 is not as scalable, secure, reliable, or portable as Windows NT. It also lacks support for features like asynchronous I/O and Unicode. At its best, Windows 95 is not the pure 32-bit operating system that NT is; instead, it is a 16- to 32-bit hybrid. Just recently Windows 98 made its appearance on the scene. A principal addition is added World Wide Web support and an attempted integration of Microsoft's Web browser (Internet Explorer) with the underlying operating system. Law suits from the federal government and many states make it unclear at this time what the future of Windows 98 will be. Other GUI-Windowing Systems-- IBM's OS/2 and its windowing system (Presentation Manager) was originally developed by Microsoft for IBM, but a conflict between the two companies caused them to go their separate ways. One result was the development of Microsoft's Windows NT, and it seems that IBM and OS/2 have lost the battle for market share. Several other windowing systems that are used to some extent are: the Coomodore Amiga's Intuition system, Atari's GEM, and Sun Microsystems' NeWS. In the mid-nineties Sun came out with its Java programming language. Part of that language was the Abstract Window Toolkit (AWT) package, which contained many classes which facilitate the building of Graphical User Interfaces and windowing applications. In 1997 Sun came out with the Java Foundation Classes (JFC), which enhanced the AWT and made GUI applications platform independent. From the point of view of GUI development and windowing applications the most important parts of the JFC are the "Swing" components. These include everything from buttons to split panes to tables. In the UNIX world (primarily), the X Window System reigns. This was developed at MIT's Technology Laboratory for Computing Science as part of MIT's Project Athena with support from a consortium of computer manufacturers (IBM, DEC, and others) in the late 1980s. Although in practice X is used mostly in the UNIX world, it is really a networked graphics programming interface that is independent of machine architecture and operating system. It has become an industry standard and permits the development of portable graphical interfaces for networked workstations. X uses a Client-Server model in which the X Display server is a process that runs on a specific workstation and controls that workstation's display device(s). X Client applications running on any machine on the network can request drawing and input services from a remote display server which enable them to display their output on the display device controlled by the X display server. The display server coordinates requests from any clients wanting to use the display device it controls. It is responsible for all drawing on the workstation's screen and getting user input from the mouse and keyboard. It provides resources such as windows, graphics contexts, fonts, cursors, color maps, etc. Class Content-- In this class we'll be learning how to use Microsoft's Visual C++ (v6.0) and the integrated development environment that comes with it (Developer Studio) to prepare Microsoft Windows application programs. While some time will be spent learning how to use the development environment, the majority of the course will cover the nuts and bolts of the Win32 Applications Programming Interface (API) which consists of a library of C language functions providing the programming interface between a Windows application and the Windows operating system. We will also spend the last part of the semester learning how to use the Microsoft Foundation Class (MFC) library--a library of C++ classes that wrap and hide the API functions--and in learning the basics of X Windows programming. Time permitting, we will also take a quick look at the Java AWT and Swing. Many example programs will be discussed. These programs and all the course notes are on line at: http://www.cs.binghamton.edu/~reckert/index.html under the "CS-360 (GUI and Windows Programming)" link. FEATURES OF WINDOWING SYSTEMS-- Most windowing systems (including Microsoft Windows) provide some of the following features: -A consistent user interface in which all applications have the same look and feel. Some aspects of this consistent interface are: Display of text and graphics inside a self-contained window. Menus to initiate program functions. Use of controls (child windows) to get data from the user. Some controls are: buttons, scroll bars, edit boxes, list boxes, etc. Controls are often grouped inside popup child windows called dialog boxes in order to provide for many pieces of user input. Use of a mouse pointing device to point to, select, deselect, drag, and perform other operations on objects on the screen. All Windows programs use the same built-in logic to do things like drawing text or graphics, displaying menus, and receiving user input. -Multitasking: Each program acts like a RAM-resident popup (a la "Sidekick"). Programs run "simultaneously." Each program occupies its own window, which can be moved and sized. Users can switch between programs. Some characteristics of Windows Multitasking: Under Windows 3.xx, the multitasking was non pre-emptive (i.e., cooperative). Programs must give up control so others can run. Programs coexist with other programs and must be "good citizens." In other words, they should relinquish control after they have "done their thing" so as not to "hog" the processor Under Windows 95/NT/98, the multitasking is pre-emptive. A system timer allocates time slices to each process (running program). A process consists of one or more threads of execution (dispatchable units of executable code). Individual threads of a process are multitasked, so we can have two or more pieces of the same process running simultaneously. If done correctly, this can lead to very efficient programs. Under both cooperative and pre-emptive multitasking, the Windows operating system moves code and data around in memory and swaps it into and out of memory as necessary. -Windows Object Orientation: Windows are handled like C++ objects in the following ways: (1) Each window has a user-defined type (Windows "Class") which serves as a template and defines its general properties. (2) An instance of the window "Class" is created at run time. This is the actual window. We can have several windows based on the same window class. (3) Messages sent to windows affect their behavior. As we'll see, messages received by windows usually result from direct or indirect user interaction with the window. -Windows Memory Management: Older versions of Windows used a 16-bit, segmented memory management scheme. This was dictated by the architecture of the earlier Intel microprocessor chips and made those aspects of Windows programming having to do with memory allocation quite difficult. Windows NT/95/98 use a 32-bit flat memory model, which has simplified things considerably. As old programs terminate, new ones start; code and data are continually swapped into and out of memory. So fragmentation can occur. The Windows operating system must consolidate memory space, and thus moves blocks of code and data continuously. There can be several instances of a program running at the same time. The code is only loaded into memory once, so program instances must share the same code. In addition, programs can share code located in other files. Many of these files are dynamic link libraries (DLLs). -Dynamic Linking versus Static Linking: In static linking (see diagram below), when a program makes a call to a function stored in a library, the compiler will generate instructions to the linker to incorporate the code for the required function in the executable. The function's code thus becomes a part of the executable, which can lead to large programs. Windows uses dynamic linking extensively; in fact, much of the Windows operating system is actually contained in dynamic link libraries. In dynamic linking (see diagram below) when a program makes a call to a function in a DLL, the compiler and linker generate relocation tables that contain information which, at run time, will enable the system to load the library (if it's not already in memory) and find the code for the required function. Since in dynamic linking the actual code does not become a part of a program's executable, Windows programs can be much smaller than their statically-linked counterparts. In addition, since the DLL is only loaded once, there is no memory price to pay for the fact that the same code is being used by many different applications. Another advantage of dynamic linking is the fact that updates and enhancements to dynamic link libraries can be accomplished without having to recompile existing applications that use them. A disadvantage of dynamic linking is the fact that the DLL must be present at run time. In other words, if an application calls a function in a DLL, the application is no longer self contained. It will not run if the DLL is not on the system. -Device Independent Graphics Interface: Windows doesn't access the I/O hardware devices (like video displays or printers) directly. Instead it makes calls to generic functions within a DLL called the Graphics Device Interface (GDI). The GDI translates these into hardware commands. (See first diagram below.) This means that the same program will run on many different hardware platforms. In some cases a new piece of hardware may not be supported by the GDI. In that case it is the responsibility of the manufacturer to supply a "device driver" (hardware control program) that will translate GDI commands to the specific commands needed to output to the hardware. (See second diagram below.) Often these device drivers are DLLs. The Windows API-- As mentioned above, the Windows Application Programming Interface (API) is a library of more than 1000 functions written in C that provides the programming interface between Windows programs and the Windows operating system. There are actually several APIs. The Win32 API contains functions that support the 32-bit flat memory addressing and thread-based pre- emptive multitasking that is used under Windows 95/NT/98. This is primarily a superset of the older Win16 API which contains functions that only support the 16-bit segmented memory allocation system and cooperative multitasking used by Windows 3.xx. There is also something called the Win32s API which patches Win16 so that 32 bit applications will run under Windows 3.xx. Since the Win16 and Win32s APIs have become all but obsolete, we will not consider them further. Classical Windows Programming-- The most direct way of programming Windows applications is to use C (or C++ without classes) to access to the raw Win32 API functions directly. This, in some sense, is the hard way to go, but it is also the most basic. In addition it provides the most flexibility and the best performance. Most important of all, Win32 API programming provides a deep understanding of how Windows works and how our applications and the Windows operating system interact with each other. It also provides a firm foundation for using class libraries (e.g. MFC) to program Windows applications. Using Class Libraries to Program Windows Applications-- Microsoft (and other compiler producers) have prepared libraries of C++ classes that encapsulate most of the Win32 API in a set of logically organized classes. Borland's verion is called the OWL (Object Windows Library). Microsoft's version is called MFC (Microsoft Foundation Classes) and is probably the closest to being a standard for this kind of Windows programming. There are about 200 MFC classes, and they provide a framework upon which to build Windows applications. Some of the characteristics of MFC are: -They offer the convenience of RESUABLE CODE. -They produce smaller executables. -They can lead to faster program development, but there is a substantial learning curve required! -MFC Programs must be written in C++ and require the use of classes, so the programmer needs to have a good grasp of C++ and object-oriented programming. The Event-Driven Programming Paradigm-- In a standard, sequential (command line interface) program, the program solicits input and waits for the user to respond. In other words it spends a lot of its time in a polling loop. This approach follows a structured sequence of events, and the program, instead of the user, is in control. An example would be a program that uses the following algorithm to average a set of grades: Input name Input first grade Input second grade Input third grade Compute average Output average The user is forced into following the sequence required by the program. In other words, the program does something and the user must respond. (If we consider the user to be more important than the program, this way of doing things is kind of like the tail wagging the dog!) In a cooperative multitasking system, this approach would be disastrous since no other applications could run while this application is waiting for the user to provide data. Windows uses a different programming paradigm: Event-driven programming. This programming paradigm is designed to avoid the limitations of sequential, procedure-driven methodologies. Here the operating system receives events from users as they occur. (See diagram below.) Events might be things like: "User enters a number from the keyboard", "User clicks on a 'compute average' button". Each time an event occurs, the operating system receives it, interprets it, and sends an appropriate message to the application the event is targeted to. In the above examples, some messages might be: "I am providing a grade", "Compute the average". The application is sitting in a "message loop" waiting for incoming messages. When a message arrives, code in the message loop will examine the message and, depending on what it is, take the appropriate action. In the examples above, the application's response to the first message might be to add the grade to an accumulator and increment a counter, while the response to the other message might be to divide the accumulator by the counter. In any case, after processing the message, the application returns control to the operating system. In this type of programming, events are processed as they occur. The program doesn't solicit input; rather it waits for messages that indicate user actions. And the user can act at any time. It is the operating system's responsibility to detect and interpret events, and to send the correct messages to the application they are targeted to. Messages can occur in any order and can be targeted to any application. Since it is the operating system that is in control, no single application can hog the system (unless it does so in response to a message). We can see that in this kind of programming, the user controls the program and is not forced to fit into a procedural mold dictated by the program--in other words, the dog wags the tail.