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.