Microsoft Windows is an operating system level product that supports graphical user interfaces on the Intel 80x86 platform (PC's, AT's, clones, etc.). Version 3 of Windows is one of the most popular software packages ever developed. Half a million copies were shipped in the first six weeks after its introduction in 1990, and over a million copies per month were selling at one time. Windows NT, a version of the system that runs in 32-bit mode on Intel and other hardware, now makes the Windows environment available outside of the PC world. The huge potential market for application software that runs under Windows has naturally attracted the attention of many product developers, including several who have developed state-of-the-art UIMS packages.

The popularity of Windows is certainly due in part to the availability of inexpensive but powerful compatible hardware, the 80x86 machines from dozens of competitive vendors. But Microsoft has maintained its leading position in this market by continually improving the software's functionality. Windows today provides a sophisticated event-oriented user interface, memory management, the ability to run several programs at the same time, and various ways for those programs to communicate. The last two features make it possible for you to write applications that effectively share the code of other applications that the user already has. Here are some of the interapplication communication protocols that Windows supports:

Dynamic Link Libraries (DLL). These are toolbox routines to draw and run various controls, or to take procedural actions like sorting data. Many of them come with Windows, and you can inexpensively license additional routines from independent software developers and distribute them with an application. So if you need a gas gauge display in your application and Windows doesn't have one, you can license the code from someone else. You can also write your own DLL in a language such as C.

Dynamic Data Exchange (DDE, soon to be replaced by DDEML). This is the fundamental protocol for interapplication communication. It allows your program (the client) to send data to another application (the server), asking that application to execute a menu item or a macro. (Note that these are different definitions for client and server than X- Windows uses; in fact, they're almost the opposite.) It also lets your program receive data sent by another application. This is the technique you'd use if you wanted to have a spreadsheet do calculations and return the result. Of course, the spreadsheet has to recognize DDE communication, but competitive major applications typically will.

Object Linking and Embedding (OLE). Object linking and embedding are two related techniques that allow the user to create documents containing objects created and maintained by different applications. For example, these features allow a user to include a "live" drawing in a word processing document. Clicking on the drawing will bring up the graphics application that created the drawing, with the drawing loaded and ready to edit. If the drawing is only linked, then displaying it is always handled by the graphics program, even when it's displayed in the word processor window. If it's embedded, then the word processing program maintains a static copy of the display, so the graphics program doesn't have to be running.

HyperTopic: Robustness in the Shared-Code Approach

Writing a program that calls on another application's existing functionality is a powerful approach, but John's experience with macros and programmed links between systems from different vendors suggests that you should keep in mind the potential for problems with long-term reliability. Here are some specific points to consider:

Can the user accidentally edit files (blank forms or macros, perhaps) that are critical to your program's behavior?
Can the user set options in a server application that will affect your program's behavior? Is the user REQUIRED to set those options before the system will run?
Can the user clearly distinguish between bugs in your program (not that there are any!) and bugs in one of the server programs? And is your customer support staff ready to track down those problems so the user isn't left between two vendors, both saying, "It's YOUR fault!"
If one of the server applications is upgraded, will it still run the macros you've written?
If operating system upgrades require it, will the vendors of the server applications all upgrade their products promptly?

The shared-code approach has a lot of things going for it. But while taking advantage of its power, you should be especially conscious of one of Nielsen and Molich's heuristics: "Prevent errors."

If you decide to use interapplication communication in Windows, you'll need to know what applications your users already have available, and you'll need reference manuals that describe the interapplication communication conventions for those applications. For example, what's the syntax for the DDE command to average data in the spreadsheet, and how do you specify which data to average? You'll also need to build the code and the interface that's unique to your program, as well as the "glue" that links everything together. To simplify that part of the job there are several good UIMS packages for Windows programmers. One of these is Microsoft's Visual Basic.

Visual Basic combines a visual interface editor with an event-driven programming language. Creating an interface is a matter of creating windows ("forms"), menus, buttons, and other controls interactively. You click on the control you want in a palette, drag it into place, and specify its characteristics in a dialog box. The effect of each control is defined with Basic code written into the control's code window, and controls send messages to each other and to handlers that you write to define the program's functionality. Programs you distribute need to include a run-time Basic support module, implemented as a DLL file. The system can be extended with DLL code that you write yourself or license from third parties.

All this sounds very much like HyperCard, and conceptually it is. But Visual Basic is intended as a full-fledged program development environment, and it provides significant support for that goal. Menus, windows, dialog boxes, and all other common Windows controls can be created using visual programming. Additional controls licensed as third-party DLL routines are also fully integrated into the visual environment. Many of these controls are included in Professional Toolkit for Visual Basic, also sold by Microsoft. Taken together, these features allow a program written in Visual Basic to look and act like any other program in the Windows environment.

Modular code in Visual Basic is supported by allowing multiple files with several levels of variable scope: local to a procedure (the default), shared by all procedures in a form or module, or global for access by any procedure. The technique of run-time support through a DLL file is common in Windows, and Visual Basic helps you create an Installer for your application to ensure that all necessary files are in place and up-to-date on the user's machine. Interapplication communication is also supported. You can call other DLL's, send and receive messages from other programs using the DDE protocol, and make other programs act as OLE servers (although the program you write can only be a client).

Industry response to Visual Basic has been very positive. Developers are using it to prototype applications, then deciding to deliver the final application in the same language. There is some concern with speed, but this can often be addressed by recoding critical routines as a DLL. For programmers who aren't comfortable with the event- oriented paradigm, other UIMS packages offer interface- building functionality similar to Visual Basic, but with a more procedural language.

HyperTopic: What to Look for in a UIMS -- and Where

There are many UIMS packages available, and more will be introduced in the future. Here's a checklist of features you should watch for if you're shopping for a UIMS or trying to convince your manager that one is needed. You should decide which items are critical for your project.

FEATURES TO WATCH FOR

Action Logging: Built-in features that let you capture a trace of the user's actions are useful for some phases of usability testing, as well as for tracking down intermittent bugs during beta testing. You'd like the trace to be at a fairly high level ("pulled down Edit menu"), not just a list of keystrokes and X,Y positions of mouse clicks. Macro packages running on top of your application may also give you this capability.
Big Program Support: Look for programming language and environment features that support good programming practices: modularity (multiple files, separate compilation, version support), scoped and typed variables, a good debugger, etc. Make sure the speed of the generated executables will meet your needs.
Code Generation: Does the UIMS generate executable code or does it produce a file of source code to be compiled with your usual compiler? The first approach is more convenient, while the second gives you a little more flexibility. Keep in mind, though, that automatically generated source code is often unmaintainable by human programmers.
Extensibility of the Interface: Can you add new controls and widgets to the programming environment, and will they have the same ease of programming as the original control set? Equally important, what extensions are available?
Extensibility of the Program: Can the program you generate call routines written in other languages?
4GL programming: Some UIM systems are part of a more extensive 4th generation programming language that simplifies development of the main program as well as the interface. This is especially likely for database programming applications.
Operating-System Specific Techniques: The UIMS should support any special interface techniques that users of other programs in the operating system have come to expect. A UIMS on the Macintosh, for example, should support the Macintosh clipboard, and it should generate applications that can be started by double-clicking on their data files. A UIMS for Windows should support OLE and help you build an application installer.
Prototype to Final Application Capability: You'd like to begin and end development with a single UIMS.
Stand-alone Application Generation: It's more convenient if the UIMS generates applications that don't require the user to purchase a separate run-time support package.
Style Guide Support: Some UIM systems will automatically check or enforce interface style guide provisions, such as "every dialog box must have an OK button," or "no more than 7 items in a menu."
Vendor Support and Longevity: Does the UIMS vendor have a history of maintaining the package and responding to upgrades in the operating system? Will the vendor still be in business when your application becomes a success?
Visual Programming With Structure: Can you lay out the interface visually? Can you specify constraints on that layout, preferably either with drawing tools ("align left") or programmable constraints ("all buttons of this class must be 50 pixels high").

WHERE TO FIND OUT MORE

Here are some of the resources you can use to find out about the UIMS and prototyping systems available for your computing environment.

First, talk to people in your organization. If someone already has a system they're happy with, then you'll have the benefit of their expertise if you choose the same system. It will also make it easier for applications developed in different parts of your organization to communicate and to have similar interfaces. (This is the "borrowing" principle again.)

Next, start browsing through trade journals. Find a library with back issues of the "________ World" magazine (fill in the name of your computer system), and skim the tables of contents for the last couple of years. Look especially for review articles -- you may find several prototyping systems compared and contrasted. In any case, look at the recent ads and send for information on systems that seem interesting. Try out the library's on-line or paper index to journal articles, but be sure to supplement any "hits" you find there with additional browsing in the stacks.

Another place to look is a large bookstore, especially a technical or university bookstore. The store will usually have a larger selection of magazines than most libraries, and it may also have a good selection of up-to-date technical "how-to" books ("Grover Cleveland's Six Easy Steps to Programming in UltraSystem 6.0," and the like). These books are of such narrow and short-term value that libraries can seldom afford them.

Still another resource is programmers outside your organization. If you belong to a user group, talk to people there (and look in back issues of the user group magazine). If you have access to a network, watch the discussions on- line, or post a query.