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

  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'

  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,

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:


  under the "CS-360 (GUI and Windows Programming)" link.


  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.


       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 

       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

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

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.