***** Computer Select, November 1992 : Doc #2621 *****

Journal: Dr. Dobb's Journal Oct 1992 v17 n10 p18(19)
* Full Text COPYRIGHT M&T Publishing 1992.
-----------------------------------------------------------------------------
Title: Sizing up application frameworks and class libraries; tools for
reducing coding effort and leveraging prefab functionality.
(includes related articles on the history of application
frameworks and on the spec for a sample application)
Author: Valdes, Ray.
AttFile: Program: BOROWL.EXE Self-extracting archive.
Program: CPPVUS.EXE Self-extracting archive.
Program: DDJAFX.TXT Program specification.
Program: INZAPP.EXE Self-extracting archive.
Program: MSMFC.EXE Self-extracting archive.
Program: OBJMNU.EXE Self-extracting archive.
Program: OOPAFX.ASC Source code listing.
Program: OWLYAO.EXE Self-extracting archive.

Abstract: Application frameworks, class libraries and graphical user
interface (GUI) toolkits are three different technological
approaches to the problem of increasing application complexity.
Five object-oriented application frameworks and class libraries
are described in an attempt to make it easier for programmers to
determine which approach is best for them. Application frameworks
are difficult to analyze because much of their machinery lies
under the surface; they are examined here by having expert
programmers at various tool vendors code up a small but
non-trivial example program. Analysis of different
implementations of the same functional requirements provides
concrete information that helps decide the appropriate tool for a
specific purpose. The focus is on single-user, graphics-oriented
applications using Borland's ObjectWindows Library, Inmark's zApp
Application Framework, Island Systems' object-Menu for C++,
Liant's C++/Views Class Library, and Microsoft's Foundation
Classes.
-----------------------------------------------------------------------------
Descriptors..
Topic: Object-Oriented Programming
Program Development Software
C Programming Language
Comparison
Software Design
Applications Programming
Computer Software Industry
Program Development Techniques
Program Libraries.
Feature: illustration
table
program.

Record#: 12 603 796.
-----------------------------------------------------------------------------
Full Text:

As today's applications increase in complexity, so do the tools for building
them. Application frameworks, class libraries, and GUI toolkits are three
such categories of tools, yet they represent very different technological
approaches. Still, the tool categories, though different, all address the
same basic software-development issues: reducing coding effort, speeding time
to market, increasing maintainability, adding robustness, and leveraging
prefab functionality.

Although comparing these tools is like comparing apples, oranges, and
bananas, when you start a development project, you might end up saying, "All
these products look like fruit to me." In this article we'll provide you with
a basis for deciding which of these approaches is right for you, focusing on
five object-oriented application frameworks and class libraries. In future
articles, we'll cover GUI toolkits not based on object-oriented languages,
as well as additional class libraries.

The View from Square One

When your project is at square one, there's a simple question: Do you stay
with the raw API (basic DOS or Windows services), or do you choose something
at a higher level? If you choose the latter (the "fruit scenario"), then
you're at square two: choosing between an application framework, a class
library, or a GUI toolkit.

Once you decide on one of these three categories, the next question is, which
particular toolkit? Your decision can be as critical to your success as your
choice of algorithm or programming language. These categories are new enough
that no clear standards have emerged, and many plausible contenders exist.
Even properly derming these categories is sticky. (See the textbox, "What is
an Application Framework?")

The trade-offs are numerous. With an application framework, you can cruise
above the API at a high altitude, but you'll have the steepest learning
curve. Their productivity-increasing power implies great complexity. Also,
because the framework constrains your design decisions, you run the risk of
crashing into a brick wall. If you use a GUI toolkit, you stay much closer
to the ground-level API and enjoy a gentle learning gradient as well as free
choice in architectural-design approach. The downside, of course, is that
you must do much more of the work yourself. Smack-dab in the middle between
GUI toolkit and application framework is the class-library category.

This is where we found ourselves when we needed a program to display
digitized samples for our "Handprinting Recognition Contest." We chose the
safe but slow ground-level route of writing the program using the native
Windows API. (Actually, we first wrote a DOS version which used the
compiler's library of rudimentary graphics primitives.) Like programmers
everywhere, we had a deadline and were leery of diving into a large, complex
product we had no experience with. In retrospect, we wondered which tool was
the right one for the job; hence this article.

The Problem with "Saturday Night" Reviews

Because much of an application framework's machinery lies under the surface,
evaluating application frameworks is a uniquely difficult task. A few hours
spent with the manual or looking over example programs won't cut it for
complex and subtle tools.

So how do you make an informed choice? Not by reading most product reviews
we've seen. The limited hours allotted for a standard product
review--typically, an evening with the manual, plus a weekend working with
sample code--do not give the reviewer sufficient exposure to realworld use of
the framework. (A recent review of several application frameworks in another
programming magazine presents, with a straight face, the source code to
"Hello World" using four different products, averaging about a dozen lines of
code each. Although "Hello World" is a convenient wax to meet a framework
it's not something on which you want to build a long-term relationship. It's
like buying a he)use based on the look of the front door.) As with a
programming language, the best way to evaluate a tool is to live with it for
a while on a nontrivial development project.

But the live-in approach has problems too. First, the steep learning curve
precludes conducting more than one or two such evaluations. Although the
products are meant to make life simpler, they are complex pieces of software
machinery as Tables 1 and 2 show. Second, weeks or even months can elapse
before you run into product limitations that stymic further development or
require contrived workarounds. When you finally discover that your framework
is in fact a straight-jacket, it may be too late. A third problem is that,
even if a flamework is well designed and bug free, it may offer multiple ways
of accomplishing a given task, and it is not always clear to the novice which
is the best approach. By contrast the experienced user of a framework knows
which methods offer best performance and are easiest to code, but SuCll
knowledge is often hard-won.

The tack we settled on was to ask expert programmers at various tool vendors
to code up the same small, but non trivial example program. We wrote a
program specification (see the textbox, "The Spec for the Sample
Application") that exercised many of the most interesting features of these
different packages, yet can be implemented by an expert user of a flamework
in three or fewer working days. Someone new to the framework. by contrast,
could spend a couple of weeks accomplishing the same task.

By examining different implementations of the same functional requirements,
you can obtain concrete information to help you decide which available tools
are appropriate. You can then weigh the resulting programs in light of your
own particular trade-offs. The program specification, programmer's notes,
complete source code, and executables are avaflable electronically; see
"Availability" on page 5.

This isn't a confrontational "shoot-out." Arguing about the "best" framework
is like arguing about the best cuisine, text editor, or programming language.
Our position is that dffferent tools satisfy different needs and tastes: Some
support portability between platforms, others focus on high-level object
orientation,, others emphasize closeness to the W'mdows API, and still others
swear by performance optimization. Every programmer has a unique set of
opinions about which characteristics are important and which can be
sacrfficed in real-world trade-offs. Not only that, but strongly held
opinions often change in the course of development, in response to changing
market conditions.

We find it more interesting to get a re=d-world useful application that work
rather than a contrived example that displays 20 different clialog boxes that
we'll never use. With this in mind, our specification offers plenty of
leeway to the implementor to solve the problem in a way best suited to the
application and tool. This wide latitude in design choices reflects the
implementations described here: We had no dogmatic preferences about UI
widgets; we just cared about getting the job done. Our philosophy is that
any program is better than no program, and the world's fanciest empty dialog
box is useless compared to a complete rudimentary program that accomplishes
the given task. In the case of our own implementations (the raw Windows API
and the DOS versions), the results are inclcecl homely but usable
nevertheless.

Our focus is on the single-user, graphics-oriented application. The example
does not do anything related to textediting, multiform clara entry, database
access, or multiuser processing. Nor does our spec address cut, copy, paste,
selection by pointing, raster-image data, and the all-important Undo command.
In homage to real-world randomness, we'll leave these for another time.

The Participants

We've not tried to be comprehensive in our selection of vendors. (There are
way too many to cover in one or two issues of the magazine.) Rather, our
focus remains on technology issues rather than specific products. We've
tried to make our list representative rather than comprehensive. Comparing
apples, oranges, and bananas is a stated goal; comparing all such instances
is not.

Although the boundaries are not always clear-cut, we look this month at
object-oriented application frameworks and class libraries. Future articles
will focus on GUI toolkits and bare-bones class libraries.

This article sizes up the following tools:

* Borland's ObjectWindows Library (OWL).

* Inmark's zApp Application Framework.

* Island Systems' object-Menu for C++.

* Liant's C++/Views Class Library.

* Microsoft's Foundation Classes (MFC).

In the coming months, we'll present implementations using packages such as
Autumn Hill's Menuet, MetaGraphics' MetaWindow, XVT Software's XVT, and
others.

The Results

The results are indeed striking in both diversity and homogeneity--a
fascinating case study in user-interface design as well as engineering
trade-offs. Figures 1 through 5 show screen displays from the various
implementations. Table 3 summarizes which features were actually
implemented. Tables 4, 5, and 6 provide some rudimentary metrics (lines of
code, executable size, and runtime memory profile, respectively) on the
various implementations. These metrics, like EPA mileage estimates, are for
rough comparisons only; relative standings may vary depending upon your
application.

The following sections discuss, in alphabetical order, each of the five
toolkits and their corresponding implementations. While there's not enough
room in this article to fully describe any one of the five products covered
here, we'll introduce them briefly and touch upon interesting highlights.
Keep in mind that our goal is not detailed coverage, but rather to direct
your attention to areas for further investigation.

The tools in this article all run on the PC platform. Four of the five
packages--Borland's OWL, Microsoft's MFC, Inmark's zApp, Liant's
C++/Views--are Windows-based, while Island's object-Menu is DOS-based.
Others, such as Glockenspiel's CommonView and Autumn Hill's Menuet/CPP, are
certainly worth considering. Fortunately or unfortunately, the area of
application frameworks and class libraries is one in which there will be many
available choices and little consensus of opinion about which is best, for
some time to come.

Borland's Object Window Library

OWL from Borland, while not the first framework on the PC market, is
certainly the most visible and likely the one with the most number of
installations, given the popularity of Borland's C++ language products.

The technology in OWL evolved from an earlier effort by the Whitewater Group
(authors of the Actor language/environment for Windows), which has been in
use for some years and is generally well regarded. OWL relies on a
nonportable extension to C++ known as dynamic-dispatch virtual tables (DDV'D,
which simplifies the handling of Windows messages. While Borland has Shown a
version running on NT and has announced plans to support 0S/2, OWL currently
runs only on Windows. Note that OWL does not!support DOS apps; for that, you
must use Borland's companion framework, TurboVision.

OWL classes (of which there are 25, plus 405 methods) cover the middle layer
of user-interface components, such as dialogs, controls, and text-edit
windows, as well as some higher-level components (application classes, MDI
frame windows). Graphics classes (those that correspond to the Windows GDI)
can be found in the Whitewater Group's Object-Graphics library, designed to
complement OWL. OWL does not provide low-level components such as
data-structure classes (collections, sets,. arrays, lists) and date and time
classes. These low-level classes are part of Borland's Class Library, which
runs on both DOS and Windows and supports both OWL and TurboVision.
Borland's Class Library comes with the OWL package, and for this reason we
count OWL and the Class Library together in our discussion and in the table
summaries. (Windows expert and noted author Paul Yao has ported our DOS
implementation to Windows using OWL, resulting in an implementation of 1050
lines. This implementation is also available electronically, if you want to
see another approach to OWL programming.)

Figure 1 shows the interface Borland programmers designed. Listing One (page
106) shows some of the code implementing the main application window.
Borland's implementation of our sample application required the most lines of
code; see Table 4. Despite the number of lines, the resulting executable is
still small; see Table 5. Unlike those implementations with large
executables, programs written with OWL do require about 312K of runtime DLLs.
The runtime support, however, is shared by all OWL applications running at
the time, much as Windows itself is shared by Windows apps.

Inmark's zApp

Of the Windows-hosted products discussed here, zApp and C++/Views are the two
which strive to take the high road above the Windows API. zApp and C++/Views
each define higher-level abstractions that offer a modern, event-driven GUI
application model, which is portable to platforms other than Windows (OS/2,
DOS, and Motif). The advantage of the "high-road" approach is that the
design is not burdened or warped by the historical vagaries of the Windows
API. The disadvantage for the programmer is that there is a brand-new set
of concepts to learn, with the potential danger that some of these
abstractions may be poorly conceived and not stand the test of time.

Unlike C++/Views, which is strongly influenced by the classic Smalltalk MVC
paradigm, zApp has its own unique design. The design, however, results from
years of experience in building GUI apps. (The architects of zApp started
out as a consulting firm doing GUI software development in C++.)

There's a saying that good design is invisible. As Ward Cunningham puts it,
"Good class libraries whisper the design in your ear." This is the case with
zApp, which straightforwardly provides all the usual classes you'd expect in
building event-driven GUI programs: a main application class, a small
hierarchy of event-handling classes, classes for graphic display,
window-containing classes, and the usual GUI widgets (push button, check box,
list box, combo box, and so on). There are no radical concepts or unpleasant
surprises, greatly easing any learning curve associated with a brand-new API.

Inmark's implementation is shown in Figure 2. Listing Two (page 108) shows
some of the principal member functions in Inmark's implementation of our
sample application.

Island Systems' object-Menu

Object-Menu is the only DOS-based product we cover in this article. Like the
other packages here, it's written in C++ and provides a set of classes that
serve as a configurable framework for a GUI application. Island Systems
plans to release a Windows version later this year.

The programmers at Island Systems came up with the most complete
implementation of our sample application (see Table 3), showcasing many of
the features in their product. The application's visual components (see
Figure 3) have a sculpted, three-dimensional look reminiscent of Motif. One
slightly disconcerting element for people used to Windows (and the Mac) is
that the mouse pointer arrow angles to the right rather than to the left.

Among the features of the sample implementation, multiple scrollable browser
windows can be opened to view part or all of the handwriting-data samples.
Listing Three (page 110) shows excerpts from Island's implementation. Each
window can be iconized, and has its own menu. An object-Menu window includes
functionality for maximize, minimize, close, resize, drag, and autoplacement
of internal items. object-Menu can use automatic placement directives to
define positioning of visual components, similar to the facility in zApp and
C++/Views. Unlike other implementations that use scrollbars to select next
and previous characters in the alphabet, the scroll bars here truly scroll
the items in a given window's display.

One nice feature in Island Systems' implementation is a window that allows
you to type in a string and see the corresponding letters from the
handwriting sample data. Another unique feature is the use of tear-off
menus, similar to those on the Mac and in OpenLook; the Edit/Copy menu is the
only tear-off menu in this implementation. Island's implementation
apparently does not directly support printing, but accomplishes the task via
the use of Graf-Drive Plus (from Fleming Software). Note also that
object-Menu does not contain graphics primitives, but can work with a number
of low-level graphics libraries (Borland's BGI, MetaWindow, Genus FX, and
Flash Graphics).

The executable size of Island Systems' implementation was larger than the
others. However, considering that the other. packages are relying on
Windows for extensive support (approximately one megabyte of runtime support,
up to five megabytes on disk), the size of the Island Systems implementation
does not seem so large.

With regard to performance, all of the Windows-based implementations felt
about the same on our test hardware (a 386/33 with 8 Mbytes of RAM).
Island's DOS-based implementation was the only one that seemed sluggish. One
reason for this is that the other implementations were running in Windows
Enhanced mode, which uses both extended and virtual memory. In DOS, of
course, any memory above 640K generally lies unused. Because the code we
supplied reads the entire data file (250K worth) into memory, there's not
much room left, and the overlay manager must kick into action. Using a disk
cache helped, but the sluggishness remained. object-Menu can get around this
overlay swapping by using Phar Lap's DOS extender and Metaware's 32-bit C++
compiler, but we did not try this version.

Another way to speed up performance might be to use an optimized graphics
library, such as MetaWindow or FlashGraphics instead of BGI.

Liant's C++/Views

Of the five tools covered here, Liant's C++/Views may have the longest
heritage. C++/Views evolved from a C-based package that attempted to bring
to C some of the benefits of the Smalltalk language and class libraries. The
package was called "c_talk" (from CNS, later acquired by Liant) and came out
in 1988. It was noteworthy because it included a class-browser utility
similar to that found in Smalltalk-80 and Digitalk's Smalltalk/V. A class
browser is a program that allows you to view and edit the source code for
classes by using a multipane window display. In one window pane is a
scrolling hierarchical list of classes, on a second pane is a scrolling list
of methods (termed "member functions" in C++), and in a third pane is the
code for the method itself, which can be edited and changed.

The design of the class browser stems from the object-oriented nature of the
Smalltalk environment, in which there is no real concept of source files,
header files, or module linking as there is in C and C++. By contrast, the
integrated development environments (IDE) from Borland and Microsoft are
designed with the individual source-code file as the main focus of a
programmer's attention. As time passes, these IDEs have evolved to better
support object-oriented programming by supplying graphical views of class
hierarchy and so on. In the DOS or UNIX C/C++ environment, you can always
drop down out of the IDE to work at the command-line level, editing source
files with your favorite text editor and running the compiler directly (or
via make). In the Smalltalk environment, the class browser provides the sole
access to the source code. Liant's version allows you to work in both ways.
Source code is maintained in source files, rather than in a persistent object
database of classes and methods.

C++/Views is strongly influenced by Smalltalk's Model/ View/Controller (MVC)
paradigm. This approach to structuring applications consists of three parts:
a control component that manages events, a view component that manages the
presentation of data to the user, and a model component that encapsulates
application-specific data and processes. (See Adele Goldberg's "Information
Models, Views, and Controllers," DDJ, July 1990.) According to this protocol,
any changes made to the application's data model (say it's a collection of
numbers) can be automatically reflected in multiple views (such a bar chart,
pie chart, or spreadsheet view) without the model knowing which views are
presenting the data. In my opinion, this design strategy has not been
surpassed in the 15 years since it was first conceived.

Despite this heritage, C++/Views is more than a clone of Smalltalk-80; it has
its own design. The VNotifier class is the controller that handles events.
The VView class (a subclass of VWindow) is an abstract class from which view
classes are derived. Graphics output is accomplished through the VPort
class. The application's data model can be constructed using user-defined
classes in conjunction with C++/Views data-structure classes (sets,
dictionaries, lists, and the like).

Liant's implementation of our sample application is not the most
feature-filled, but has, as Figure 4 shows, a clean, intuitive feel. The
implementation strategy decomposes the main window into a nested set of
panes, or views, corresponding to the various visual elements on the
application. Listing Four (page 111) shows a sample of the browser code.
One nice feature in Liant's class library is the VRatio class, which is used
in conjunction with the VFrame class (a window frame) to flexibly specify the
screen size of display objects. This is similar to the automatic sizing
facility in zApp.

Microsofts Foundation Class Library

Most articles on Microsoft's MFC say it's a "thin veneer" or "wrapper" around
the Windows native API. This myth is not substantiated by the facts.
Metrics such as line count, number of classes, and number of methods indicate
otherwise.

The reason behind the myth is likely that MFC is designed to sit at a close
conceptual distance from the Windows API. Classes in MFC map on a one-to-one
basis with entities in the Windows API, such as display context, bitmap,
brush, button, MDI child window, and so on.

In terms of lines of code, the source for MFC library is larger than the

source for OWL or zApp (although all are in the same general ballpark).
Those lines of MFC source code are not just idly sitting there: Microsoft was
able to implement our sample application using the fewest lines of code. In
addition, Microsoft's implementation had the smallest executable and required
the least amount of runtime support from DLLs. Listing Five (page 113) shows
sample code that makes up the browser UI.

Microsoft's implementation was not as comprehensive as some of the others
(such as Inmark's or Island Systems'), although it did fully satisfy the
specs we provided. Microsoft's implementation (Figure 5 shows the UI
implemented by Microsoft) provided one nice feature that the others did not:
a drop-down list box that shows the graphical shapes of the handwriting data.
Using this UI component as a means for selecting letters, rather than having
to handcode the tabular display of shapes, may have contributed to the
compact implementation.

One possible reason for the small executable size is the use of a dialog box
as the main application window, rather than using a "heavy-weight"
user-defined window. In Windows, dialog boxes are built-in components, in
that they don't require user code for registration or full-fledged window
proes, thus saving space in the executable and/or the runtime. Using dialogs
means the main window is not scrollable or resizable (not required by the
spec). Note that other implementors also used the dialog-box technique (in
Borland's implementation, for example, TMainWindow is a subclass of TDialog),
but without equivalent savings in space.

Microsoft has demonstrated MFC on DOS text mode (via Mewel, like Inmark's
zApp), on Windows/NT, and apparently has plans to create a portability layer
for the Macintosh plafform (according to leaks published in the trade press).
Inelegant yes, but portable nonetheless.

The design of MFC requires a form of exception handling and template classes,
which are implemented in a nonstandard way due to deficiencies in Microsoft's
C7 compiler (unlike Borland's compiler, C7 does not support templates). But
these mechanisms are implemented using macros and other standard constructs,
and are therefore theoretically portable to other compilers. It would be an
interesting exercise to port MFC to Borland's compiler. For those who don't
mind sitting within spitting distance of the native Windows API, such a
combination may well be the best of both worlds.

Conclusion

All the tools discussed here were able to deliver on our program spec. Each
has different strengths and weaknesses; you'll have to decide which one fits
your requirements profile. Try out the sample implementations. Ask the
vendors for additional information and demo diskettes.

Although these products are full-featured and mature, it seems that none of
the PC-based products yet contain the rich functionallty present in
non-PC-based frameworks like MacApp or PenPoint. This situation will likely
change. In the meantime, you can still get a leg up on program development
by using one of these products.

Ray is senior technical editor at DDJ. He can be reached through the DDJ
offices, at 76704,51 on CompuServe, or at rayval@well. sf. ca. us.

What is an Application Framework ?

Although application frameworks are not a new concept, they have only
recently arrived as a mainstream development tool on the PC platform.
Object-oriented languages are ideal vehicles in which to embody an
application framework, and the advent of C++ to the PC platform has allowed
mainstream PC programmers to finally enjoy the benefits of application
frameworks.

From the early '80s to the start of this decade. C++ was found mostly on
UNIX systems and researcher's workstations, rather than on PCs and in
commercial settings. C++, along with other object-oriented languages,
enabled a number of university and research projects to produce the
precureors to today's commercial frameworks and class libraries. The most
visible of these early efforts were Mark Linton's InterViews, Keith Gorlen's
NIH class library, the Andrew toolkit from CMU, and Erich Gamma's ET++
framework.

These tools had their roots in the Smalltalk-80 system, the granddaddy of
frameworks and class libraries. In Smalltalk80, there's no concept of an
application distinct from the enclosing framework or environment. The act of
programming in Smalltalk consists of navigating the class hierarchy in search
of appropriate classes to reuse or subclass. And, it turns out, there are
quite a few. The typical Smalltalk-80 environment has over 120 classes, 4000
methods, 6000 instantiated objects, and 1.3 Mbytes of source code.

In 1985, Apple Computer's MacApp system rigorously systematized the key ideas
of a commercial application framework: a generic app on steroids that
provides a large amount of general-purpose functionality within a
wellplanned, well-tested, cohesive structure. More specifically, Apple
defines an application framework as "an extended collection of classes that
cooperate to support a complete application architecture or application
model, providing more complete application development support than a simple
set of class libraries." This suppot means not just visual components such as
list boxes and dialogs, but all the other facilities needed by an
application, such as support for undoing commands, printing, and debugging.

For our purposes, we define an application framework as an integrated
object-oriented software system that offers all the application-level classes
(documents, views. and commands) needed by a generic application. An
application framework is meant to be used in its entirety, and fosters both
design reuse and code reuse. An application framework embodies a particular
philosophy for structuring an application, and in return for a large mass of
prebuilt functionality, the programmer gives up control over many
architectural-design decisions. The architectural approach used by many
application frameworks is an evolutionary descendant of Smalltalk's
Model/View/Controller triad.

Class libraries and GUI toolkits are generally smaller and simpler systems
than application frameworks. We define a class library as an object-oriented
set of workhorse classes that can be incorporated piecemeal into an
application, rather than the other way around. (Apple's definition of a
class library is "a collection of classes designed to work together to make a
given set of programming tasks easier, i.e., numerics, graphics memory
management, etc.") By allowing the programmer to pick and choose, a class
library does not enforce any particular architectural approach. Class
libraries are object-oriented implementations, unlike GUI toolkits. The
services offered by class libraries include both user-interface functions
(menus, dialog boxes, and graphics primitives), as well as general-utility
functions (date and time conversion, data-structure manipulations, and so
on).

Finally, GLI toolkits offer services similar to those of a class library, but
using a procedure-oriented rather than an object-oriented interface. GUI
toolkits predate object-oriented languages, and some of the most successful
products in this category are written in assembler. Most DOS-based GU'I
libraries are at the same basic level of abstraction as Windows (or at least
the early versions of WindowS). Unlike class libraries, GUI toolkits
generally do not offer nongraphical utility routines (queue management
routines, for example).

Both class libraries and GUI toolkits often come bundled with design tools
that allow you to interactively specify application components, such as
dialog boxes and menus.

In practice, the distinctions between one product and another are not as
clear-cut as these definitions. For example, one class-library vendor
directly compares their product against a popular application framework.
Another classlibrary vendor avoids comparisons with application frameworks,
yet the sample programs bear an uncanny philosophical resemblance to those of
the application framework.

Although the ancestral lines are often blurred, a collective unconsdous
(community memory) is at work here. For example, one particular vendor (not
part of this issue's roundup.) was unaware of the basic concepts of MacApp,
Smalltalk, and the MVC triad, even though his product competes directly
against frameworks that embody the architectural heritage of these OOP
pioneers.

--R.V.

The Specfor the Sample Application

We've all been there. Your boss comes to you on a Friday afternoon with a
request for a "simple program" that's needed ASAP. In this particular case,
it happens to be a graphics-oriented program to display some digitized
vectors.

"It's real easy," your boss tells you. "All you have to do is let the user
pick from a list of files, then read in the data, which is just a bunch of
points, and then display those points using MoveTo and LineTo. Do you think
you can have it ready by Monday morning?"

This, in essence, is what we asked the tool vendors to do. The application
is called HWX Browser, and it allows users to read in different sets of
handwriting data from files on disk and display the alphabets in an
application window.

The program is not a contrived example meant to exercise items on vendors'
feature lists. Rather. the specs come from an entirely different project
and predate the current effort. The program is in many ways representative
of graphics-oriented programs, as well as offering its own unique challenges
to the implementor.

The DDJHWX Browser allows the user to view handwriting samples which have
been gathered from a number of people. Each file represents samples
collected from a single person, in the form of a series of alphabets. The
file has a particular structure, consisting of a short header, followed by
the data for individual letters of the alphabet, each letter being
represented by multiple instances or versiorks. The data for a single
instance is basically a sequence of coordinates as gathered by the digitizer;
a set of points for each stroke in a character.

Each vendor received the same specs and had the same amount of time. The
basic areas of functionality are: file operations, character selection.
display of the image in a window. printing, and debugging. For each area,
we specified minimum requirements and identified optional features. Our spec
provided plenty, of leeway to the impiementor to highlight features unique to
their product. The complete spec is available electronically.

We supplied the data files and the specification for the file format; we also
implemented DOS-based functions to read the data from the disk into an
in-memory data structure, and other functions to display a letter on the
screen using MoveTo() and LineTo('.) callback functions. Implementors were
free to change the code to their liking, as long as functionality was
preserved.

This was not a programming exam in the sense of trick questions or hidden
problems to solve. We're only interested in looking at the final result, in
understanding what it took to get there, and in discussing the technological
issues surrounding frameworks, class libraries, and GUI toolkits. Also, we
hoped to provide some good fun. In retrospect, it looks like we succeeded in
that goal: More than one implementor told us that he welcomed the chance to
do some uninterrupted programming.

--R.V.


***** Computer Select, November 1992 : Doc #9088 *****

Journal: PC Week August 31 1992 v9 n35 p59(2)
* Full Text COPYRIGHT Ziff-Davis Publishing Company 1992.
-----------------------------------------------------------------------------
Title: Inmark framework eases transition to 32-bit NT apps. (Inmark
Development Corp.'s xApp for Windows NT program development
software; Microsoft Corp.'s Microsoft Windows NT operating system
applications) (Application Development) (Product Announcement)
Author: Cunningham, Cara A.

Abstract: Inmark Development Corp introduces the $395 zApp for Windows NT
program development software for Microsoft Corp's Microsoft
Windows NT operating system. The program includes more than 150
C++ class libraries of code that support Microsoft Windows NT
compatible code. zApp encapsulates the Windows NT application
programming interface (API) and its libraries allow developers to
write applications that take advantage of some 32-bit Windows NT
features. The program also shields program developers from the
differences between Windows' 16-bit API and Windows NT's 32-bit
API. The program is compatible with zApp for MS-DOS and for
Microsoft Windows, so application written in one environment can
be recompiled to run in the other environments.
-----------------------------------------------------------------------------
Descriptors..
Company: Inmark Development Corp. (Product introduction)
Microsoft Corp. (Products).
Ticker: MSFT.
Product: zApp for Windows NT (Program development software) (Product
introduction)
Microsoft Windows NT (Operating system) (Computer programs).
Topic: Product Introduction
Program development software.

Record#: 12 589 193.
-----------------------------------------------------------------------------
Full Text:

To give Windows NT developers a jump start on building 32-bit applications,
Inmark Development Corp. released earlier this month a Windows NT version of
its C++ application framework.

The framework, called zApp for Windows NT, is a collection of more than 150
C++ class libraries of code that support NT-compatible code, said Howard
Love, president of Inmark in Mountain View, Calif.

The product encapsulates the Windows NT application programming interface
(API) in modular code objects, he said. The zApp libraries let developers
write applications that take advantage of some 32-bit NT features, such as
address space, pre-emptive multitasking and a graphical coordinate system,
Love added.

At the same time, zApp shields developers from the differences between
Windows' 16-bit API and Windows NT's 32-bit API, he said. This reduces the
time it takes for developers to learn how to build 32-bit applications, Love
added.

One zApp user said he hopes the class libraries in the NT version will
encapsulate NT's distinguishing features, such as multiple threads and
support for symmetric multiprocessing.

"I hope that Inmark will object orient all of those additional NT features
just like it does the features in Windows," said Kentyn Reynolds, president
of Reynolds Software Inc. in Santa Fe, N.M. Reynolds, whose company develops
real-time applications, said he hopes to start developing with zApp on NT in
the near future.

zApp for Windows NT shares single-source-code compatibility with the DOS and
Windows versions of the product, so an application written with zApp for one
environment can be recompiled to run under other supported environments, Love
said.

Inmark will release versions of zApp for OS/2 and for OSF/Motif before the
end of the year, said Love. Those versions will also share
single-source-code compatibility with the existing versions.

zApp for Windows NT works with Microsoft Corp.'s C/C++ 7.0 compiler, which is
included with the Windows NT Software Development Kit. Support for
additional NT compilers will be added to zApp for Windows NT as they become
available, he said.

The zApp package is priced at $395. Customers will be able to upgrade free
of charge to later versions that conform to the features built into Windows
NT.

Inmark is a privately held company that develops application frameworks and
financial software. The company can be reached at (800) 346-6275.


***** Computer Select, November 1992 : Doc #12946 *****

Journal: Computer Language August 1992 v9 n8 p81(2)
* Full Text COPYRIGHT Miller Freeman Publications Inc. 1992.
-----------------------------------------------------------------------------
Title: Software Publishing Corp.: Superbase 4 Windows v. 1.3. (Software
Review) (one of six graphic database evaluations in 'Graphics
databases')(Product Wrap-up) (Evaluation)
Author: Murphy, Thomas.

Abstract: Software Publishing Corp's $695 Superbase 4 Windows 1.3 data base
management system (DBMS) gives users a complete DBMS package,
offering powerful data-manipulation facilities and the ability to
import old data from several formats. It lets users develop
anything from a simple database to a stand-alone application with
graphic image support and custom forms; it supports dynamic data
exchange but not OLE. Superbase 4 consists of Superbase, which
lets users create databases and use SPC's data management language
to write applications, and Forms Designer, which lets users paint
the screens. The Superbase feature is easy to use and compact.
Forms Designer is more complex, and it is harder to get the
appearance desired. Adding bitmap images to a form is extremely
easy; users just pick the picture control and drag out a box.
-----------------------------------------------------------------------------
Descriptors..
Company: Software Publishing Corp. (Products).
Ticker: SPCO.
Product: Superbase 4 Windows 1.3 (Data base management system)
(evaluation).
Topic: Data Base Management Systems
Evaluation
Graphics Software.

Record#: 12 452 577.
-----------------------------------------------------------------------------
Full Text:

Superbase 4 is a complete relational database tool. It lets you develop
anything from a simple database running within Superbase to a stand-alone
application with custom forms and graphic images support. Superbase supports
dynamic data exchange but does not currently support OLE. This system
consists of two main programs: Superbase and the Forms Designer. Superbase
lets you create databases and use SPC's data management language (DML) to
write applications. Using the Forms Designer, you "paint" the screens and
off you go.

Superbase is a very compact program for the amount of power it affords-the
actual program comes on a single disk! It truly amazed me in this day of
16-disk installs. A copious amount of documentation is available in two
volumes. This system is simple to use for creating a database, assigning
keys, and setting up verification fields for data entry. You have simple
pushbutton control over all datafields for type and representation. I really
enjoyed the ease with which this could be done.

The form generator is not quite as simple to use. You work in a paint-type
program with all of the standard Windows "things" available. Still, it isn't
like creating a form with Visual Basic or using any of the Windows screen
generators because you don't rely on the typical Windows look with its heavy
emphasis on dialogues. You can produce very nice-looking forms, but I found
it a bit difficult to get the appearance I wanted. On the other hand, I
really liked the ability to lay out a form and change the order of data entry
later.

Forms, of course, contain buttons. These buttons are connected to DML
commands, which control the flow of the system. This feature was
occasionally cryptic, but learning a new language is generally a
time-consuming event. Still, the documentation for using the Form Designer
and language was not as clean as that of the SuperBase program. If you opt
to purchase this system, I highly recommend working through the Application
Guide; it will save you a lot of time.

The addition of bitmap images to a form is extremely easy. You just pick the
picture control and drag out a box. A dialogue pops up so you can define the
image characteristics, and you are done. Of course, this process can be
controlled from the DML. (In fact, you could write the whole application in
the DML if you disliked the designer.) I had absolutely no problem with
images in my application. You can adjust scaling, color usage, and type.
The incorporation of images is nicely integrated. I had a record field
listing the image file's name, and I would read in the text and the image.
Once an image was up, I changed from color to greyscale by pushing a button
to execute a single line of the DML.

After I found my way to the applications guide and worked through it, I found
SuperBase 4 Windows to be a very powerful system. it's two strongest points
were the powerful data-manipulation facilities and the ability to import old
data from several formats. If you haven't already spent years learning how
to make Clipper dance and want one complete integrated package, you should
look into SuperBase.

Doing it from scratch

As a final challenge, I decided to build the application from scratch using
Borland's C++ compiler with their B-Tree class and the Magic Fields data
entry screens package from Blue Sky Software. Magic Fields is a new package
that lets you add data validation to your Windows applications.

Building it from scratch was the most fun way to accomplish the task. I used
Blue Sky's WindowsMaker to lay out all of my various windows and dialogues,
incorporated Magic Fields to do all of my input verification, and added some
help files using Blue Sky's ROBOhelp. This approach made the interface a
point-and-shoot affair as simple as Visual Basic (except even Visual Basic
programs could benefit from RoboHELP). The important thing was having all of
the user input checked dynamically. Magic Fields data validation is
straightforward and effective.

You can attach help to show users what type of input you want, and if you
have things such as phone numbers, any punctuation you specify will
automatically be filled in. The ability to have this type of data checking
easily available to C++ is a gigantic plus with me; I have spent many days
having to add such checks to inputs that I thought no user could miss.

Connecting to Borland's B-Tree class is simple enough: create a new object
class for the database structure, instantiate the class, and add your
objects. The trick is in guessing how to add a 250-color bitmap to a
dialogue. WindowsMaker Pro complained when I tried to attach a bitmap to the
dialogue with an "image too big" message. I knew that if PC Paintbrush and
Visual Basic could do it, I had to be able to do it in C, too.

Fortunately, a new tool called zApp happened to land on my desk. zApp is a
new applicationframework package from Inmark for DOS and Windows. It has
text and picture fields with input templates to cover my needs for input
verification and a form class with which to create my query and new record
dialogues. What made zApp invaluable in this case was its zBitmap and
zDisplay classes. I constructed a new bitmap display and my picture was back
once again.

So, with all of my tools assembled, it was quite simple to produce the
application in C++. The main difference in programming ease vs. Visual
Basic, is that with Visual Basic, you have one language by one manufacturer
and all of the add-in tools work in a set, cohesive manner. With C++, you
have many compilers and styles and can pick what suits you, but you can't mix
and match randomly. Then again, we aren't comparing programming languages
here, we're just seeing how to put a picture in a database.

The moral of the story

The thing I learned the most by looking at this set of products is that it is
very easy to produce databases incorporating pictures. This type of system
has many great uses, and you could create a variety of applications with few
modifications to a simple shell. If your main business is database oriented
and things have been a little dry lately, this could be your ticket. Heck,
even if you have never written a database application, it could be the time
to try.

In the world of DOS, any of the packages I looked at will create quick and
attractive databases. They will run happily on even a 8088-based machine
with 640K of RAM. Think of all those real-estate brokers who could be
showing their clients' properties using your package. The ability to produce
very nice-looking grey-scale printouts just adds that final touch.

With the Clipper applications I built, I incorporated the Flipper Graphics
Library, which gave me great control over fonts, and the ability to add menus
and buttons (even the nice three-dimensional kind) and use a mouse. Flipper
also can display images on the screen but only up to standard VGA. This
should be remedied in the next release, but who has time to wait?

I recommend using T-BASE with Clipper and Flipper and producing great new
applications here and now. The thing that gives TBASE the edge with me is
simple: royalty free. I like dGT as a product slightly more because it is so
compact--instead of the TB_SHOWGIF and TB_SHOW of T-BASE, you call the VCR
image name, and it picks the format up automatically. It comes with a much
smaller manual not because it has less power, but because it is more compact.
T-BASE comes with ChromaTools, which adds in a whole set of toys to doctor
those pictures up. You can't go wrong with any of the products in this
group.

In the world of Windows, things are a little more diverse. SuperBase 4
Windows gives you a ready-toroll database. It lets you produce a plethora of
looks, takes care of tons of your labor, and happily handles up to a billion
records per file. Unlike trying to program your own in Visual Basic or C++,
SuperBase has support built in for networking and telecommunications and will
export or import data to a multitude of formats. In addition, it has
reporting, SQL links, and can merge mail or edit text. With SuperBase, you
are left only to set up the actual record format and design forms. All of
the messy work underneath has been taken care of for you. With the DML, you
may be able to produce your way into the hearts of corporate America.

Don't worry, hard-core programmers. The job of creating great-looking
database applications in Windows isn't all that bad for you either. The
tools of Coromandel make it a snap to create a database in Visual Basic and,
with a few more button clicks and waves of the magic wand, you can add
dynamic data exchange and object linking and embedding. If you go this way
and want to have pictures that look great, you shouldn't forget Dazzle.
Without it, your applications will be crying for help with 16 colors. If
Coromandel and Blue Sky could just get together and make Magic Fields for
Visual Basic, you couldn't beat it.

Which brings us to what could beat it--C++ (still the product of choice for
those six-pizza jobs). Despite some add-ons, Visual Basic can still make you
hungry for the custom controls, verification tools, and layout tools
available for C++. In my application, I grabbed the Borland B-Tree class and
went to work, but lots of nice SQL libraries are out there for building all
the databases your heart could desire.

Though getting 256-color bitmap pictures into my windows wasn't as easy as it
was with Dazzle, it can be done without too much dancing and having the
protection and feature of Magic Fields is indispensible. Maybe these two
could just trade technologies with Dazzle for C++ and Magic Fields for Visual
Basic.

There really isn't a right or wrong choice in any of these products. The
biggest difference is your market and how you like to get the job done. All
of these companies have demonstration programs available for the asking, and
I highly recommend taking a look-see at these to put images on top of what I
have written here. No matter what tool you buy, you too can soon be
producing graphics databases.

Thomas Murphy is product review editor for COMPUTER LANGUAGE.



***** Computer Select, November 1992 : Doc #23248 *****

Journal: PC Magazine June 16 1992 v11 n11 p54(1)
* Full Text COPYRIGHT Ziff-Davis Publishing Co. 1992.
-----------------------------------------------------------------------------
Title: Microsoft C/C++ 7.0: catching up to Borland in the compiler race.
(Microsoft Corp.'s compiler)(Borland International Inc.)(includes
related article on usage of Microsoft C/C++ 7.0) (Software Review)
(First Looks) (Evaluation)
Author: Shaw, Richard Hale.

Abstract: Microsoft Corp's $499 C/C++ compiler supports Microsoft Windows
graphical user interface (GUI) program development. System
requirements include an Intel 80386 microprocessor-based
microcomputer, 4Mbytes of RAM, 10Mbytes of disk storage space and
MS-DOS 3.1 or later. The compiler supports 32-bit addressing.
C++ 7.0 includes the Microsoft Foundation Classes (MFC), a
Microsoft Windows application framework, and it supports all
objects. When compared to Borland International Inc's Object
Windows Library (OWL), MFC is less object-oriented and more
Microsoft Windows-oriented; the program requires significant
experience to use effectively. C++ 7.0 did not perform well in
testing. For compiling C programming language code, C++ 7.0
worked an average of 51 percent slower than its predecessors, and
for compiling C++ it performed 34 percent slower than Borland C++
3.0. While this compiler may be attractive to Microsoft Windows
enthusiasts, it is not a superior product.
-----------------------------------------------------------------------------
Descriptors..
Company: Microsoft Corp. (Products).
Ticker: MSFT.
Product: Microsoft C/C++ 7.0 (Compiler) (evaluation).
Topic: Evaluation
Compilers
C Programming Language
Program Development Software
32-Bit.
Feature: illustration
table.

Record#: 12 157 350.
-----------------------------------------------------------------------------
Full Text:

After nearly two years, Microsoft has finally released its new C compiler:
Microsoft C/C++ 7.0. With full support for AT&T C++ 2.1, a Windows
application framework, updated tools, precompiled headers, and mounds of
documentation, the $499 C++ 7 package also includes the entire Windows 3.1
Software Development Kit (SDK). But developers looking for faster compiles
and performance gains will be disappointed.

C++ 7 is now a 32-bit, protected-mode DPMI-hosted compiler, so you can run it
under Windows from a DOS window and access up to 4GB of memory. It requires
a 386 machine with at least 4MB of extended memory and Qualitas's 386MAX,
Version 6.01 (included in the package), to run from the DOS prompt.

Although it's largely an AT&T C++ 2.1-compliant compiler, C++ 7 offers
limited support for AT&T C++ 3.0 templates. While other vendors, such as
Borland, implement templates in the compiler, C++ 7 provides TEMPLDEF, a
command line utility that can generate data types in a C++ source file.

C++ 7 also contains a Windows application framework, the Microsoft Foundation
Classes (MFC), with full support for Windows objects such as windows,
dialogs, messages, and controls. Graphics device interface (GDI) objects are
also supported, along with object linking and embedding (OLE) and the
multiple document interface (MDI). There are also general-purpose classes
for managing strings, files, and exceptions for use in DOS programs. The 60
MFC classes are small and fast and consume only 39K of RAM when compiled for
the small memory model.

Unlike Borland's Object Windows Library (OWL) or InMark's ZApp, MFC is less
object-oriented and more Windows-oriented. Rather than present a new set of
functions to learn, MFC is little more than a thin wrapper over the Windows
application programming interface (API). Consequently, it's not for Windows
novices: Experienced Windows developers will probably love MFC, but
beginners might want to check out the competition.

Features that ease application development include a new overlay manager,
auto-inlining, and p-code. Auto-inlining lets you generate in-line code in
place of small functions, including class member functions that contain
WHILE, SWITCH, or FOR statements--something that Borland's compiler won't do.
P-code ("packed-code") replaces groups of machine code instructions in your
programs. It's easy enough to use, but for the advantages it offers in size
reduction, there are penalties in performance.

Both the Programmer's Workbench (PWB) and Code-View (CV) have gotten
face-lifts. They now offer fully CUA-compatible interfaces with movable,
overlapping windows. While the PWB is not yet Windows-hosted, it features a
new C++ class browser that displays class hierarchies, data members, and
member functions in a tree format. CV 4.0 fully supports C++ and also offers
class browsing features during debugging. A remote feature lets you debug a
program running on another system and transfer the target executable.

COMPILING SPEEDS

What about performance? We tested C++ 7 against its predecessor for
compiling C and against Borland C++ for compiling C++. The results were
disappointing. For compiling C, C++ 7 an average of 51 percent slower than C
6.0a--69 percent slower on fast compiles and 33 percent slower on
optimization compiles. And since the performance of the resulting
executables was practically identical, there are no performance benefits
gained from compiling your C 6 code with C++ 7.

For compiling C++, C++ 7 was an average 34 percent slower than Borland C++
3.0-7 percent faster on fast compiles but 64 percent slower on optimization
compiles. Surprisingly, Microsoft's executables performed identically to
Borland's with two exceptions: C++ 7 was 40 percent faster at integer
handling, while Borland's C++ was twice as fast at floating-point. If you're
looking for faster compiles and executables, you're not going to get them
from this version of Microsoft C++.

If you're a Windows developer, you won't be disappointed with the MFC and SDK
in C++ 7. Without a Windows-hosted development environment or integrated
template support, it's hard to get too excited about this product, but
Microsoft C/C++ 7 is finally catching up to the quality of other C++
development environments for Windows.


***** Computer Select, November 1992 : Doc #26802 *****

Journal: Corporate Computing June-July 1992 v1 n1 p285(3)
* Full Text COPYRIGHT Ziff-Davis Publishing Co. 1992.
-----------------------------------------------------------------------------
Title: Gearing up for the object-oriented express. (includes related
article on the Prospectus of object-oriented programming)
(Technology Outlook)
Author: Cummings, Steve.

Abstract: Object-oriented programming (OOP) helps enhance individual
programmers' productivity, facilitates group development projects
and streamlines program maintenance. Objects are self-sufficient
software modules that perform a given group of chores on demand.
Programmers can easily build a comprehensive working application
by linking a number of objects. Since objects in OOP reflect
real-world entities, they can more closely reflect the way an
organization conducts business than would programs based on
abstract data types. OOP is ideal for large-scale team
developments because the objects always function the same way,
regardless of the applications in which they have been used.
-----------------------------------------------------------------------------
Descriptors..
Topic: Modular Programming
Object-Oriented Programming
Realism
Performance Improvement
Efficiency
Design
Trends
Program Development Techniques
Reusable Code
Industry Analysis.
Feature: illustration
table
graph.

Record#: 12 231 628.
-----------------------------------------------------------------------------
Full Text:

The old saw about the whole being greater than the sum of its parts
epitomizes object-oriented programming (OOP) systems.

The basics are familiar. Relying on modular software units that can easily
be connected, reused, and enhanced, the object-oriented approach boosts the
productivity of individual programmers, simplifies team development efforts,
and streamlines maintenance down the line. Because object-oriented programs
are inherently better organized and more stable, OOP permits larger, more
complex applications than are practical with traditional procedural
programming methods. And with the proliferation of object-oriented software
environments, object-based design makes it possible to integrate applications
on a system-wide level.

Because objects model real-world entities, such as purchase orders and
customers, a fully developed object-oriented system can more closely reflect
the way a company does business than programs based on abstract data types.
And because objects can be reused, the same objects that the IS developer
uses to create a mission-critical transaction-processing application, such as
order entry, can be modified to create user applications, such as a decision
support or executive information system.

The facility with which objects can communicate in a distributed environment,
in conjunction with OOP's ability to accelerate multiplatform development,
make it ideal for building client-server applications. But when an object
can be anything from a single spreadsheet to an entire manufacturing process,
designing applications that take advantage of the object-oriented approach
can leave an IS manager, and a programmer, breathless.

In practical terms, deciding when to make the shift to OOP can be the
toughest decision an IS manager has to make. For one thing, thinking about
objects, classes, polymorphism, and inheritance rather than DO and WHILE
loops runs counter to most programmers' training.

Another concern: At present, object-oriented development tools are still in
short supply for many of the hardware/operating system platforms in wide use
at the corporate

level. For these reasons and others like them, immediately opting for an OOP
strategy might prove premature.

What Makes OOP Run?

Objects are self-contained software modules that perform a given set of tasks
on command. By connecting a number of these objects, a software engineer can
create a complete, working application almost as easily as assembling a
stereo system by plugging together a receiver, tape deck, and CD player.

The difficulty arises in creating an object that works properly and is robust
enough to be used in a variety of applications. However, once a given object
exists in finished, working form, other programmers need know nothing about
how it accomplishes its task. Instead, it's enough to send the object the
right commands, or messages.

This makes the object-oriented approach ideal for the large-scale, team
development cycle typical in the corporate setting. When, like stereo
components, an object can be moved as a complete unit to a new program, the
object is, in the lingo of OOP, encapsulated. A quintessential black box,
the object always does its job the same way, independently of the application
in which it's used.

Object-oriented languages make it easy to modify some of the capabilities of
existing objects, or to graft on entirely new talents, while retaining their
original functions. The ability of new child objects to retain traits of
their parents is referred to as inheritance.

Perhaps most important, objects are defined both by the data and by the
methods that act on the data--in other words, by what function the object is
to perform. This feature is critical in allowing managers to define objects
in terms of real-world attributes. A customer object, for example, can be
defined by what it must do to calculate an account balance and what it should
do with it once it does.

Objects that are highly modular, extensible, and modifiable can create
systems that adjust rapidly to changing conditions--a key consideration for
corporations that must adapt to market shifts. If the source code has to be
modified every time workflow is altered, the results could be disastrous.
With OOP, drastic code rewrites aren't necessary every time new functions are
incorporated into the process. Simply adding a new object should do the
trick.

Suited to Real-World Workflow

Because of their inherent adaptability, object technologies are eminently
suited to the relatively unstructured ways in which most office work is
organized. SunSoft's ToolTalk and DEC's Application Control Architecture
(ACA) Services, for instance, use object technology to provide
program-to-program communication on networks for the creation of compound
documents. Object technologies are also making inroads into database systems
in which complex data types, such as those typically found in CAD/CAM, are
difficult to handle through relational systems.

Smalltalk was the first object-oriented program and remains the darling of
object-oriented purists. In the real world, though, object orientation comes
in the form of C++, a modified version of ordinary C. Partly because of its
ancestry, C++ lacks some of the refinements of a language built from scratch
with object orientation in mind. But the syntax is similar enough to
compress the learning curve. What's more, existing C source code can often
be used within C++ applications, although some modifications may be required.
Nevertheless, calls from C++ can be made to previously compiled modules
written in any procedural language.

Paramount in any decision to move toward object technology is the hardware
plan. Corporations that have decided to retain a traditional computing
strategy centered around minicomputers or mainframes may not find the case
for object-oriented development very compelling for the time being.
Graphical user interfaces (GUIs), with all their programming complexities,
aren't currently an issue on mainframes. And when the central minicomputer
or mainframe runs all the programs, neither is cross-platform support. C++
is not inherently graphical, and it offers few advantages over normal
procedural languages when doing initial development. The payoff comes when
programs have to be maintained, expanded, or ported to other platforms.

The expanding universe of GUIs on small computers, however, encourages the
move to OOP for these machines. While the programming requirements for most
GUIs don't meet the strict definition for object orientation, many aspects of
the object-oriented paradigm are applicable. This is especially true of the
user interface itself, with all of its familiar objects--windows, dialog
boxes, menus, icons, and so on. Object-oriented languages are a natural for
customizing these essential interface elements. The object-oriented
development tools now available for smaller computers are certainly superior
in number and in quality to OOP tools for big computers. C++ compilers from
Borland, Symantec, and now Microsoft are available for PCs. Many third-party
vendors already sell a gamut of extensive object libraries for PC- and
workstation-based implementations of C++.

Still, faster and larger computers haven't been neglected in the rush to OOP.
Vendors such as Oregon Software and ImageSoft market C++ for Sun
workstations, Unix boxes of every stripe, and DEC, Hewlett-Packard, and IBM
minis. C++ for IBM mainframes is promised in the near future.

Of course, with the continuing dramatic increases in workstation performance,
many companies have chosen to modify or even to eliminate the role of larger
computers. An earlier transition to OOP may be more inviting when the
mainframe or mini can act behind the scenes as a potent server--with user
applications running on client workstations. Any move to client-server
systems should entail serious consideration of an OOP strategy, where the
advantage of separating user interface elements from server-based core
applications is obvious, especially in a multiplatform environment.

Cross-Platform Development

The increased importance of cross-platform development in a networked setting
also provides a strong impetus for moving toward OOP. When an application
outgrows the machine it's running on--an almost inevitable outcome--being
able to port functionality or entire programs quickly and easily from one
environment to the next takes on a high priority.

In the past, reasonable portability could be ensured by adopting a single
language on all hardware platforms. But with the proliferation of
graphics-intensive operating environments, a huge amount of code must be
devoted to each environment's unique software techniques for creating
windows, displaying dialogs, and drawing icons. If the development team is
forced to abide by each platform's idiosyncratic rules for controlling such
elements, major sections of each program would have to be rewritten and fully
tested for every environment.

Object-oriented tool kits such as CommonView, Zinc, and Zapp have emerged to
free the developer from the burden of writing separate code for different
platforms. These products allow the programmer to write applications
independently of a particular machine or operating environment.

Once compiled with the proper libraries, a program will run identically on
any of several disparate platforms. True, such tool kits don't have to be
fully object-oriented themselves to provide cross-platform support--witness
the success of XVT and WNDX for ordinary C. Still, much like the GUIs they
support, these latter packages have the critical object-oriented
characteristics of modular, message-processing functions. In object-like
software environments, object-oriented APIs work better than those that
aren't object-oriented.

Besides wider availability and greater compatibility with existing C
programs, C++ has another compelling advantage over other object-oriented
languages: a C programmer can learn to use C++ relatively quickly. And while
the demand for skilled C programmers still outstrips supply, the typical
corporation already boasts a small cadre of them and can expect to recruit
more without too much trouble. No similar pool of quick converts exists for
the other object-oriented languages.

Of course, even if the current staff is willing and able to learn a radically
different programming style, productivity will suffer during the transition.
An extended period of low output may not be acceptable in the face of a
pressing demand for new applications. On the other hand, budgetary
constraints may make it impractical to hire additional programmers already
facile with C++ or at least C. Again, it's not an issue of if but when.

Software Project Considerations

The final major branch in the object-oriented decision tree concerns the
nature of the software project or projects at hand. One obvious
consideration is how much of the project's functionality can be supplied with
existing, off-the-shelf object libraries, perhaps with minor modifications.
The fewer the objects that must be written from scratch, the faster the
development cycle.

The size and expected life span of the project are also big factors. For
small projects, such as file conversions, no one can argue with
quick-and-dirty procedurally based programs that get the job done. If the
goal is to make minor enhancements to an existing, functioning large
application, such as a corporate sales database, the time and effort required
to convert the program into C++ often won't be worth the benefit gained.
Instead, the program should simply be modified and extended in the original
language.

Because large object-oriented programs are so much easier to build and
maintain, time lost in preparation may well be made up as the project
progresses. In any case, the payback will certainly come when the
application undergoes the inevitable rounds of modification.

While the object-oriented paradigm represents a radical shift in programming
technique, it makes sense to think about an operation from a high-level
systems perspective. Object technologies make thinking in such flexible
terms possible. More important than the technical pros and cons of
object-oriented programming techniques is the capacity OOP gives managers to
view their operation as a system of interacting, modular components that
reflect the real-world dynamics of their business.

Steve Cummings has authored or contributed to seven books, including The
Little Laptop Book (Peachpit Press) and Mastering Windows (Sybex).

Objects Ahead

1 year: Most corporations actively investigating object-oriented technology;
many working on strategic pilot applications.

2 years: Many large-scale object-oriented applications in use; significant
trend to platform-independent object-oriented tool kits.

5 years: Platform-independent object-oriented development established as
preferred strategy for most corporate development teams.

Where to find

WNDX

The WNDX Corporation 1240 Kensington Rd., NW, Suite 403 Calgary, Alberta,
Canada T2N 3P7 (403) 244-0995 Fax (403) 244-1039

CommonView

ImageSoft 2 Haven Ave. Port Washington, NY 11050 (800) 245-8840 (516)
767-2233 Fax (516) 767-9067

XVT

XVT Software 4900 Pearl East Circle Boulder, CO 80308 (303) 443-4223 Fax
(303) 443-0969

Zapp

InMark Development Corporation 2065 Landings Dr. Mountain View, CA (800)
346-6275 (415) 691-9000 Fax (415) 691-9099

Zinc Interface Library

Zinc Software 405 South 100 East, 2nd Floor Pleasant Grove, UT 84062 (800)
638-8665 (801) 785-8900 Fax (801) 785-8996




***** Computer Select, November 1992 : Doc #29467 *****

Journal: PC Week May 25 1992 v9 n21 p85(2)
* Full Text COPYRIGHT Ziff-Davis Publishing Co. 1992.
-----------------------------------------------------------------------------
Title: Seattle company banks on trio of libraries. (Skalar Instruments)
(Case Study) (Buyers Guide)

Abstract: Skalar Instruments uses Inmark Development Corp's zApp and Rogue
Wave Software Inc's Matrix.h++, Math.h++ and Linpack.h++ program
development software packages to develop software for medical and
scientific instrument manufacturers. Although Skalar used Liant
Software Inc's C++/Views for a time, the Smalltalk characteristics
and overly common naming conventions made it undesirable. zApp
gives Skalar's products a good Microsoft Windows graphical user
interface (GUI) look and feel but still allows for class libraries
from other vendors to be used as well. Skalar's plan is to
combine Inmark and Rogue Wave's libraries in future developments.
Math.h++, Matrix.h++ and Linpack.h++ work well for developing
matrix operations, but their 16-bit mode requires recompiling the
libraries for a 32-bit mode. The documentation does not help this
process. Although applications developed with ready-made code may
run more slowly than those developed from scratch, the programs
developed are ultimately better designed.
-----------------------------------------------------------------------------
Descriptors..
Company: Skalar Instruments (Purchasing)
Inmark Development Corp. (Products)
Rogue Wave Software Inc. (Products).
Product: zApp for DOS (Program development software) (Usage)
Matrix.h++ (Program development software) (Usage)
Math.h++ 4.0 (Program development software) (Usage)
Linpack.h++ (Program development software) (Usage).
Topic: Program Libraries
Program development software
C Programming Language
Matrices.
Feature: illustration
photograph
table.

Record#: 12 268 559.
-----------------------------------------------------------------------------
Full Text:

Dan Brown, who turned to C++ in the hope that it would make Windows
programming easier, discovered C++ alone wasn't the answer. C++ with the
help of class libraries was.

Brown, owner of Skalar Instruments of Seattle, uses Inmark Development
Corp.'s zApp and Rogue Wave Inc.'s Matrix.h++, Math.h++ and Linpack.h++ to
develop software for companies that make medical and scientific instruments.
He said the libraries have made all the difference in what his developers can
accomplish.

"I wouldn't do it any other way," Brown said. "The class libraries, if
they're good, are just lifesavers. You can [develop] products you couldn't
do otherwise."

Initially, Brown tried Liant Software Corp.'s C++/Views, but the product's
Smalltalk origins showed up in the applications.

"It was really based on the Smalltalk paradigm in terms of what the
application looked like," Brown said. "The applications did not really look
like Windows applications. That is, the dialog boxes popped up in different
locations than they would in standard Windows applications."

Version 1.1 of C++/Views also had very common naming conventions that Brown
felt might create conflicts if he used class libraries from other vendors, he
said.

"The class names were common words such as `memory,' and this meant that if
we used another class library where somebody happened to have used the same
name, we'd have conflicts," Brown said.

Inmark's zApp addressed both problems.

"We were very concerned about having the program look like a real Windows
application, which zApp gave us, and it was built so you could use other
[vendors'] class libraries at the same time," Brown said.

While he has not yet started developing with libraries from multiple vendors,
Brown said he plans to combine zApp and the Rogue Wave libraries in future
applications.

Brown has used Math.h++, Matrix.h++ and Linpack.h++ in developing matrix
operations for some of Skalar's software. He said that while they are
relatively easy to use, the libraries posed a problem because they are in
16-bit mode. Since Brown programs in 32-bit mode, he took an undocumented,
but successful, route in getting around the obstacle.

"We got the source code and recompiled [the libraries] for 32-bit using
[Symantec Corp.'s] Zortech C++ compiler, and they work fine," Brown said,
though he added he would prefer that Rogue Wave supply 32-bit versions.
"It's a relatively serious deficiency -- for us, at least -- that they are
not supporting and optimizing the 32-bit mode."

In addition, developers need to know matrix arithmetic to use the Rogue Wave
libraries, Brown said.

"The [documentation] doesn't teach you anything about that. If there's
something in the manual that says, `This class does Hermitian matrices,' you
have to know what a Hermitian matrix is and why you'd want to use it. So
it's not for anybody who doesn't know that or doesn't have a good book."

Developers often pay a performance price for using code they haven't written.
According to Brown, zApp produces negligible increases in the size and speed
of the application. And while the Rogue Wave libraries may be slower than if
the classes were developed in-house, Brown said the time saved by not having
to write matrix algorithms makes the trade-off well worth it. Ultimately,
the libraries let him complete a more well-designed program more quickly than
he would have without them.

And at Skalar, fewer hands can do more work. "That's the biggest thing we
see for us: A small number of developers can get things done that you just
couldn't otherwise attack," Brown said. -- C.A.D.


***** Computer Select, November 1992 : Doc #29468 *****

Journal: PC Week May 25 1992 v9 n21 p85(2)
* Full Text COPYRIGHT Ziff-Davis Publishing Co. 1992.
-----------------------------------------------------------------------------
Title: Developers' needs put new demands on library vendors. (C++
programming language) (Buyers' Guide)(Market Analysis)
Author: Duffy, Caroline A.

Abstract: The market for C++ class libraries is growing as developers
performing object-oriented programming use them for their debugged
and predefined routines that speed implementation. However, the
challenge remains for vendors to standardize library
implementation and provide cross-platform portability so that the
true goals of object-oriented programming are achieved: modularity
and interoperability. Class libraries obviate the need to deal
with specific platform issues and allow developers to create
applications for many environments. Code can be shared across
Microsoft Windows graphical user interface (GUI) and IBM OS/2
operating system platforms with Borland International Inc's
ObjectWindows Libraries Presentation Manager, and Windows NT
operating system support is in development, but only Borland
compilers can be used. Liant Software Corp's C++/Views program
development software gives Windows, OS/2 Presentation Manager,
Unix X Windows and Motif support and works with several compilers.
Microsoft Corp, conversely, is staying proprietary with its
Windows-only paradigm, believing Windows is the best applications
programming interface for C++, although the applications developed
are portable only to Windows. Until a standard C++ library
exists, definitive ways of judging a product will be elusive.
-----------------------------------------------------------------------------
Descriptors..
Topic: C programming language
Program Libraries
Program development software
Code Generation
Standardization
Applications Programming
Application Programming Interface.

Record#: 12 268 787.
-----------------------------------------------------------------------------
Full Text:

Developers using C++ for object-oriented programming have helped to encourage
a growing market for C++ class libraries. For vendors, this poses the
challenge of cross-platform code portability and points to the need for a
standard library implementation.

Developers can go nowhere in object-oriented programming without classes.
They can write their own, but third-party class libraries provide the
shortest route to getting on the object-oriented road. So as more developers
turn to C++, they also turn to third-party class libraries, said Peter
Kastner, senior analyst at Aberdeen Group, a market-research firm in Boston.

"C++ without class libraries is like baseball in the rain -- it just doesn't
work very well," said Kastner. "The class libraries can bring to a C++
programmer a great deal of predefined routines that presumably have all been
debugged and thus enable the programmer to rapidly begin to implement" an
application.

Relieving a Burden

Besides, said Charles Dickerson of Borland International Inc., developers
don't want to write code that they don't have to write. "[They] are saying,
`Wait a minute, I can just use the third-party vendors' class library instead
of having to do all this myself.'

"So the class libraries are very important for building applications for
today's markets," said Dickerson, C++ product manager for Borland's languages
business unit.

Ideally, class libraries take some pain out of programming by shielding
developers from platform-specific development issues. Because With many
developers now programming for more than one environment, this has become
particularly important, some vendors said.

"With the operating-system war heating up, as we get further into the future,
we're moving farther and farther away from this notion of one monolithic
operating system that everybody uses," said Dickerson. "So it's really in
the best interest of the developer to be on more than one platform."

Toward that end, he said, users of Borland's ObjectWindows Libraries (OWL)
will be able to share code across the Windows and OS/2 platforms once the
company releases the Presentation Manager version. Support for Windows NT is
also on the horizon, he added.

But Borland's OWL can be used only with Borland compilers. Other companies
have gone further.

For example, C++/Views from Liant Software Corp. supports Windows, OS/2
Presentation Manager and Unix X Windows and Motif. It also works with a
number of compilers. So does Inmark Development Corp.'s zApp, which offers
Windows and DOS versions, with X Windows and OS/2 versions due to be shipped
by the end of the year. And the market continues to expand.

"It's growing at a furious pace, and we have an increasing number of people
entering the market," said Stephen Kuhn, Liant's director of marketing for
workstation products.

But not everybody is answering the call for portability. Microsoft Corp. has
embraced a Windows-only paradigm with its C/C++ 7.0. Microsoft's Foundation
Classes (MFC), included in C/C++ 7.0, support developing only Windows
applications.

"Our philosophy and our approach right now is that MFC is the C++ application
programming interface [API] for Windows," said Jeff Harbers, Application
FrameworX group manager at the Redmond, Wash., software giant. "There's a C
API for the Software Development Kit. MFC replaces that as the C++ API."

According to Harbers, this approach will allow experienced Windows
programmers to move incrementally into object-oriented programming for
Windows. By improving on the SDK while maintaining the naming conventions
and enabling old Windows code to coexist with new code, MFC will afford
developers an easy transition to C++, he said.

"There are a tremendous amount of developers who understand [Windows], who've
learned the programming. What our job was with our first class libraries was
to make sure that we took Windows and had C++ support for it," Harbers said.
"So we're supporting all of the [developers'] existing knowledge."

But portability will be limited to the Windows world itself: Developers can
recompile 16-bit Windows applications developed with the MFC to 32-bit
Windows NT applications once the NT development system becomes available,
Harbers added.

Lacking a Standard

Also on vendors' minds is the establishment of a standard. Currently, no
standard for C++ libraries exists, and no formal effort is under way to
establish one, according to analysts and vendors. Most point to the
still-evolving C++ language as a key reason.

"[C++] is still a dynamic language," said Borland's Dickerson. "It's still
changing, and the language does not include any specifications for class
libraries. So there are really no ground rules to go by as far as how to
implement a class library."

According to market researcher Kastner, the lack of standards gives
developers reason for caution. "There are no standards, and there's no real
way to judge how good the product is that you're buying," he said.

Complications might arise if developers choose to mix and match classes from
different vendors. While unique naming constructs in each of the libraries
solve part of the problem, different technologies in class libraries could
conflict, according to Liant's Kuhn. For example, heap allocations --the
free memory available to load and run programs -- could differ in different
vendors' libraries.

Still, it's not an immediate problem, said Kuhn, who expects establishment of
a standard is more than two years down the road.

"There isn't so much conflict between the different products that the
developers are left in the cold," Kuhn said.



***** Computer Select, November 1992 : Doc #36271 *****

Journal: PC Week April 27 1992 v9 n17 p66(1)
* Full Text COPYRIGHT Ziff-Davis Publishing Co. 1992.
-----------------------------------------------------------------------------
Title: Inmark unwraps DOS-based C++ libraries: zApp allows design of DOS
applications with Windows look and feel. (Inmark Development Corp.
introduces zApp for DOS) (Product Announcement)
Author: Cunningham, Cara A.

Abstract: Inmark Development Corp announces zApp for DOS, a DOS version of
its collection of C++ libraries for creating applications with
Microsoft Windows-like interfaces. The product provides a
framework for building character-based programs that mimic
Windows' menus, dialogs and controls; it is bundled with zApp for
Windows, and the two are source-code compatible for easy
application porting. Inmark says it plans to extend the
portability to other platforms, including OS/2 2.0. Some beta
testers say they already plan to use the two versions of zApp to
build programs that are compatible with both DOS and Windows.
zApp contains more than 120 C++ classes for building Common User
Access-compliant DOS applications. It is available directly from
Inmark for $495.
-----------------------------------------------------------------------------
Descriptors..
Company: Inmark Development Corp. (Product introduction).
Product: zApp for DOS (Program development software) (Product
introduction).
Topic: Program development software
Program Libraries
Product Introduction.

Record#: 12 188 117.
-----------------------------------------------------------------------------
Full Text:

Inmark Development Corp. this month shipped a DOS version of its application
framework for building character-based programs that have a Windows look and
feel.

The product, called zApp for DOS, is a collection of C++ libraries for
creating applications with interfaces that mimic Windows-style menus, dialogs
and controls, said Mark Anders, executive vice president with Inmark in
Mountain View, Calif.

The DOS product is bundled with zApp for Windows and shares source-code
compatibility with the Windows version, so developers can write an
application to one environment and recompile it to run in the other, said
Anders.

Resources such as dialog boxes that are used in building a Windows
application can also be used with zApp for DOS, Anders added, making it
easier to transfer applications between the two platforms.

The portability between the Windows and DOS versions of zApp will be extended
to other platforms, according to Anders. Inmark plans to release an OS/2.20
version of zApp this summer and an OSF/Motif version by the end of the year,
he said. All four versions of zApp will share source-code compatibility.

Some of the technical features built into zApp for DOS include the ability to
quickly create data-entry boxes and dialog boxes, along with built-in support
for Multiple Document Interface in DOS text mode.

The package also allows developers to build applications that run tasks in
the background while a foreground task is idle.

"When we designed zApp, we looked at all the different GUI platforms and made
sure that the concepts could be mapped in a portable way," Anders said.

One beta tester of zApp for Windows said he plans to use the DOS version to
create one application for both platforms.

"Being able to build one application that has two versions will increase the
potential user market because it will cover both grounds," said Norm
Tiedemann, an independent consultant in Nashua, N.H.

The product contains more than 120 C++ classes for building Common User
Access-compliant DOS applications, said Anders. Source code is included in
zApp for DOS so the framework can be extended, he said. Compilers supported
by both the Windows and DOS versions of zApp include Borlan International
Inc.'s C++ 3.0 and Symantec Corp.'s Zortech C++ 3.0. Version 1.1 of zApp,
which Inmark shipped last week, includes support for Windows' common dialogs
and Microsoft Corp.'s C/C++ 7.0.

Priced at $495, zApp is available directly from the company and through
direct-market distributors.

Inmark, a privately owned company, was founded in 1984 and employs 20 people.
The company can be reached at (800) 346-6275.


***** Computer Select, November 1992 : Doc #47869 *****

Journal: Computer Language March 1992 v9 n3 p5(2)
* Full Text COPYRIGHT Miller Freeman Publications 1992.
-----------------------------------------------------------------------------
Title: Vital forces. (software product development ) (Editorial)
Author: O'Brien, Larry.
-----------------------------------------------------------------------------
Descriptors..
Topic: Software Design
Product Development
Computer Software Industry
Business Planning
Version and Release Control
Prototype.

Record#: 12 013 277.
-----------------------------------------------------------------------------
Full Text:

I've noticed that I use the word "vital" a lot when talking about software
development. A good version-control system is vital to the serious
programmer; listening to users is vital to design; solid documentation is
vital to any project, and so forth. About the only adjective I use more is
way," as in "This product is way buggy," or "You know, the Microsoft-IBM
split has turned out to be way good for the development community." While the
ways disappear early in the editing process, the vitals generally stay in.
Vital, "of or characteristic of life," is a word that deserves to be closely
associated with software development.

For one thing, the word vital reflects back on the "People, people, people,"
mantra I think is so important to developing quality products. It has to be
kept in mind that your software will only be used if it makes people's life
better. It has to relieve them of some burden or tell them something they
find interesting, and it must demand less of them than any alternative.

Too often, companies forget the latter imperative and wonder why they're
going broke. I bought a CD-ROM drive for my home computer, and I can assure
you that no matter how fantastic the combination of access software and data
gets, I will never depend on that drive for reference. Why? Because the time
it takes to switch CDs is so much longer than the time it takes to find the
proper book.

Even if the Cd's access time were instantaneous (and it's not even close),
switching CDs takes more effort than switching books. Packing more books per
CD is not a solution either; within arms' reach I have two dictionaries, the
Turbo Debugger reference, the must-have new book PC Interrupts by Ralf Brown
and Jim Kyle (which includes everything from the familiar Int 21h Function
4Ch for exiting a DOS program with return code to the perhaps slightly
esoteric Int 16h Function F3h, which sets the CPU speed limit on Compaq 80286
machines), Compuserve From A To Z by Charles Bowen, the zApp Programmer's
Reference for Inmark's new application framework, a library reference for a
new C++ compiler, three local phonebooks, and a weekly computer magazine that
gives me street prices for any hardware I can imagine.

All vital references to the work at hand, but none so dominates my needs that
it's worth devoting the requisite resources to access via CD (CD-ROM player,
extension card, device driver, and the less-than-instantaneous searching
process). Until CD-ROM demands less than a book or gives something
unavailable in printed media, it will remain no more than a novelty and a
mass-storage facility. It's just not vital.

On the other hand, my word processing program is vital. If you know how to
type, it's far easier and faster than writing longhand (something pen-based
computing advocates should keep in mind). Keyboarding is also better than
typing for most things, since typos are so easily corrected, and
cut-and-paste is a metaphorical process, not one involving scissors and glue.
But what really makes my particular word processor (Word for Windows v. 2.0)
vital to me became clear the other day when I crashed my system.

I lost about three hours of work and began the requisite cursing. I hadn't
saved the documents even once and knew they were not large enough to swap to
disk, so I didn't bother digging through TMP or .$$$ files for the remains.
When next I started Winword, the cursor turned into an hourglass, the
hard-disk thrashed for a good while until, miraculously, my two unsaved
documents reappeared. Not an apostrophe was missing. Apparently, the
autosave feature works.

I felt grateful to the program, just as if it were alive. If a Recover file
feature had been buried somewhere in the menu structure, I wouldn't have even
tried to use it. After all, I knew the file hadn't been formally saved. The
design team's decision to have the program remember that its last run ended
in a crash made the program act in a way that was a little more lifelike.

But the real reason that vital" is such an important word for development is
that software evolves over time. It changes in form and function but retains
vestiges of its previous form. Functions originally conceived to do one
thing bend and distort into entirely different processes.

Variables propagate and bear little resemblance to their symbolic names-woe
unto the programmer who believes that a variable called temp is safe to
alter. Stephen Jay Gould's popular books hammer on the concept that
evolution is a one-track process. Form emerges to fulfill a function but the
form doesn't just spring, fully formed, out of nothingness. The same dynamic
shapes the software development process.

We've all been guilty of inserting just a bit" of functionality someplace it
doesn't belong because the overhead of a function call seemed excessive.
We've all also gaped in horror at functions as streamlined as a cluster of
grapes and wondered what sort of insanity could have caused us to create such
monstrosities.

The evolutionary process in programs is nowhere as evident as it is in the
large business applications that are the theme of this month's issue. Joe
Karbowski's "E is for Enterprise" tells how to use the process to your
advantage, getting the evolutionary ball rolling with low-risk, high-payback
prototypes. Dave Cohen, who wrote the embedded C appendix in the ANS1 SQL
standard, explains the nature and performance trade-offs of embedded SQL in
"Realizing the Potential of SQL." James Weller explains how to extract
seasonal data from historic records, with sample code in Clipper.

There's a BASIC flavor to our reviews this month, as we take a look at
Realizer, a BASIC for Windows, and QuickNet, a library that allows access to
the NetWare network API. We also have, of course, our evolutionarily
advanced columnists. It's a way vital issue.

Larry O'Brien, Editor