The desktop metaphor and the mouse present attractive concepts, but Apple’s
Lisa or IBM’s PC XT running Visi On exceeds the budget of the average
personal computer user. Both of these systems require a hard disk and great
quantities of RAM (random-access read/write memory). Although the mouse
itself is a small part of the expense, it is a symbol of this approach to
software, and some computer users have been heard to mutter, “What price mice?”

Photo 1

Photo 2

Photo 3

Photo 4

Photo 5

Photo 6

Photo 7

Photo 8

Photo 9

Photo 10

Photo 11

Photo 12

Photo 13

Another factor keeping down the mouse population has been the shortage of things
for them to point at (or the shortage of applications software). Until there is
a large installed base of Lisa and Visi On systems, many software authors will
forgo the expense of developing applications programs for these systems. Prospective
buyers of personal computers, on the other hand, are unlikely to buy a Lisa or
Visi On until more software is available. Apple’s own software for Lisa
is magnificent, but other applications programs are only now emerging.
Visicorp is making a major effort to induce programmers to write more for Visi
On, but the requirement of a Unix development system is an obstacle to the
smaller software houses and independent designers. The expense underlying the Unix
development system is the hardware required to run it – once again, lots
of memory and a hard disk.

This keeps most of us staring at the MS-DOS or CP/M command line and hoping that
a sudden fall in the prices of RAM and hard disks will open the way to metaphors
and mice. With the introduction of Microsoft Windows, however, the company
that brought us MS-DOS promises a mouse-and-window show running off two 320K-byte
floppy disks and 192K bytes of RAM. (More RAM is required, of course, with each
additional application.) To make Microsoft Windows even more attractive to personal
computer users, Microsoft promises to price Windows “as an operating-system
component” – that is, inexpensively.

The economics of Microsoft Windows will also appeal to programmers. Programmers don’t
need to buy special hardware or to learn Unix in order to develop software that
runs under Microsoft Windows – they can use their own IBM Personal Computers.
Moreover, programmers can take advantage of the ability to customize windows so
that each software house retains its own distinct look within the Microsoft environment.
The same enlightened attitude enabled Microsoft to resist the temptation to
reserve Windows as an environment for its own applications programs. Microsoft
is making Windows available to a number of applications software houses, including
some major competitors. Microsoft Windows is an installable device driver under
MS-DOS 2.0 using ordinary MS-DOS files. Complete compatibility with MS-DOS means
that Windows will at least let you run any application that runs under MS-DOS.
In the worst case, Windows will turn the full display (over to an MS-DOS
application and return you to your place in Windows. “Language bindings”
will enable programmers to write software for
Microsoft Windows in any Microsoft programming language.

During normal use, Microsoft Windows displays one or more windows, each with
a different application. You can move the cursor from one window to another. You
can move windows, change their size, scroll, get help appropriate to the context
in which you are working, and transfer data among windows. Windows determines the
highest level of data transfer mutually acceptable to the two applications,
with plain ASCII (American National Standard Code for Information Interchange)
as the last resort.

The “session-control layer” becomes the equivalent of the empty desktop
where you can manipulate files. The available commands appear near the bottom
of the screen. Normally, Microsoft Windows will restore the desktop to the
state at the time of its last use. In photo 1, we start from scratch.

To see the available applications programs, you either use the mouse to position
the cursor on the command “Run” or type the letter “R.”
Windows lists all the applications programs as commands, and you point at the
desired program and click the mouse to run it. You could also type the appropriate
letter instead.

In photo 2, BASIC 86 is running in a large window extending the full width of
the desktop. Because BASIC 86 does all its input/output through MS-DOS, it can run
in a Window. Microsoft calls such software “cooperative.” The bottom
of the screen shows the commands available in the session-control layer. You
can use the session-control layer to run another program in parallel with BASIC 86.

The first step toward running a program is shown in photo 3, where the cursor points
at “Run.” Microsoft Windows will now display a list of the programs available.

Photo 4 shows the next application selected. In this case, the program that’s
run is “uncooperative” – that is,
it doesn’t do everything through MS-DOS system calls, sometimes going
beyond the operating system to write directly to hardware addresses such as those
of screen memory. Microsoft Windows can’t run such a program in a window and
must give it the entire screen. That is why photo 4 does not show the session-control
layer beneath the display of “Piano.”

Photo 5 shows the transition from the uncooperative program to a “smart”
one that can live happily in a smaller window and share the screen with other programs
that take full advantage of Microsoft Windows.

The smart program is Microsoft Word. Photo 6 shows two applications – Word
in the upper window and Multiplan in the lower; both these programs were written
to take advantage of Microsoft Windows. Because the cursor is pointing at one
of the cells in the Multiplan spreadsheet, the command bar at the bottom of
the screen shows Multiplan’s commands. You can move either window by
grabbing its title bar with the mouse. You could “grow” either window
by grabbing the “grow box.” Although these photos show the title bar
at the top of the window and the grow box at the lower right, software developers
can put them elsewhere if desired.

(In fact, Microsoft’s own standard window has changed since these photos were
taken. The latest version provides a question mark on the right part of the title
bar. Selecting the question mark brings help information. If you put the cursor on
the title itself, it is replaced by little pictures that represent what you can
do with the window. The new version also includes a status line at the top of
the screen and an area for icons at the bottom.)

In photo 7, Multiplan’s window has been enlarged to show more cells and more
data, and Microsoft Word’s window has been reduced as necessary.

Photo 8 shows both the Multiplan window and the Microsoft Word window reduced.
(Since photo 8 was taken, Microsoft Windows has been adapted to use an automatic
resizing process called “tiling.” Rather than letting windows overlap
or leaving part of the desktop empty, Microsoft Windows always gives all the space
on the screen to the applications that are running.)

Photo 9 shows a charting program occupying a large window at the right-hand side
of the screen. With the cursor in that large window, the command bar at the
bottom of the screen lists charting commands. Note
that when the window containing the charting program is expanded by moving
the title bar and grabbing the grow box, the line graph has been automatically
rescaled (see photo 10). Microsoft Windows can rescale graphics if desired.

Photo 11 shows a sample “pop up” menu for the charting program. Pointing
at the PEN command on the command bar at the bottom of the screen has
brought the display of the menu of pen sizes and patterns. You select sizes
and patterns by using the mouse to point at one of the boxes shown in each
list, then pointing at the “OK” box (see photo 12). As with other
aspects of the Microsoft Windows displays, programmers can redesign menus to
their own taste.

Microsoft Windows seems to offer remarkable openness, reconfigurability, and
transportability as well as modest hardware requirements and pricing. As a
result, the desktop metaphor and mouse, intended to bring computing power
to nontechnical people, are finally going to reach the hands of many such
people. Barring a surprise product introduction from another company, Microsoft
Windows will be the first large-scale test of the desktop metaphor in
the hands of its intended users.

It is natural to wonder whether Microsoft Windows’ ability to run in limited
memory and off floppy disks will result in noticeable delays during execution.
Even Lisa with its megabyte of memory and 68000 microprocessor frequently asks
the user to wait. Is the ease of use worth the waiting? Will Microsoft Windows
somehow ingeniously avoid the problem of delays? The answers to these
questions will shape the future of mass-market software.

The open approach and the presentation of Microsoft Windows as an extension of
MS-DOS 2.0 will help attract the horde of programmers necessary to
assure acceptable execution speeds on the IBM PC. Just as enough programmers
working long enough on enough different approaches have made the Apple II
perform feats that once seemed incredible, enough programmers working long
enough on different approaches will make applications run fast under Microsoft
Windows on ordinary hardware. Even if this judgment proves mistaken, Microsoft’s
policy of openness and low pricing will have made possible a major
experiment in mass-market software. For many software authors as well as
users, this will be the first chance to test an approach to the user
interface that has hovered just beyond reach for several years.

Phil Lemmons’ comments on the Microsoft Windows demo described in the article

July 2004

One of the tough issues for journalists in covering something like a new user interface,
for which few if any applications exist, is that there’s a limited degree to which
you can verify the truth of what you think you see. You can’t examine source code.
You could be fooled by software that cleverly paints screens to look as though something
is working behind the scenes when it really isn’t.

In essence, you have to form an opinion about whether anyone would try to take you in.
Your presumption is that technical luminaries from Xerox PARC, whom Microsoft hired,
wouldn’t risk their reputations by pulling such a stunt. Your presumption is
that managers would see the downside of pretending to have something and then being godawfully
late in delivering it, frustrating customers and everyone else. Few people in those early
days realized the extent to which Microsoft would use pre-announcement tactics to undermine
competitors.

I think I wrote about Windows shortly before I found out that Microsoft was forcing
Apple to kill Macintosh BASIC, a superior product to Microsoft BASIC, by threatening
to withhold Microsoft applications from the Mac, which was about to be announced
and desperately needed applications. But even if I’d known that and become
more skeptical about Microsoft’s motives at an earlier time, I still think I
would have had a very hard time believing there wasn’t real code behind the early
version of Windows. Microsoft stood to gain from the sale of its applications on
the Mac, and the experience of writing applications for the Mac had to help with
learning how to create applications for Microsoft Windows. Apple had no applications to
put on IBM PCs and no plans for software on IBM PCs. Would Microsoft really conduct an
outright fraud to try to undermine the announcement of the Macintosh? Or to counter
Visi On, which would run on very few existing machines?

My own opinion is that Microsoft repeatedly underestimated the difficulty of doing
what it promised to do. Things worked, I think, but not well enough, and not
within the promised amount of memory. Microsoft hadn’t yet worked out an efficient
way of dividing development between the Windows system developers and the Microsoft
application developers, whose decisions affected each other, forcing revisions. That
problem was harder than anticipated and Microsoft found GUI software harder than
anticipated, despite hiring some excellent people from PARC. I doubt these people
realized how hard it would be to do a GUI atop DOS.

Charles Simonyi had come to Microsoft from XEROX PARC in 1981. Scott MacGregor arrived
from PARC in 1982. Simonyi was a leading developer of Word, and was from the start
intending it to run in a graphical user interface. I think he was also very involved
in MultiPlan and was certainly a proponent of a Microsoft GUI as soon as possible.
I’m sure Simonyi and MacGregor worked very closely together, and I doubt
many people but them could tell you what code resided where.

My memory after all this time is very vague as to exactly what happened when, how
much software was functional by when, etc. What is clear from the article and consistent
with my unreliable recollections is that the only programs working with Windows at that
point were Microsoft’s own, the aforementioned Word and MultiPlan. In retrospect,
although I don’t know, it’s conceivable that those applications worked
because of how Simonyi structured them, preparing for the day when Microsoft would
have a full windowing environment.

Also, since this version of Windows used keyboard commands as well as a mouse, I’m
not sure where MacGregor’s involvement stood at that time. He might have
still been there though upset, or he might have been gone. I later learned that
MacGregor was against rearchitecting Windows to use those keyboard commands; what I
heard from sources in Microsoft was that MacGregor had done Windows without such
support and hated going back to add it. This was one of the frustrations that led
MacGregor to leave Microsoft, as I understand it, but I don’t recall when he left.
There was no public announcement I can remember.

In summary, several possibilities seem plausible now: 1) MultiPlan and Word worked
with Windows because of how they had been written, and MultiPlan and Word were actually
doing some of the work that looked like Windows; 2) Windows was functional and
progressing when I saw the software, but release of the documented development software
was delayed because of having to throw in things like keyboard commands, or the
departure or frustration of key people; 3) I could have been fooled. Windows was mostly
not working, but Microsoft rushed things to give a different appearance, pre-empting
the Mac announcement that was soon to follow, and the fact that Word and MultiPlan moved
in and out of Windows and seemed to work in them made me believe Windows was
more functional than it really was.

To reiterate, my own opinion is that the development was legitimate but harder to
complete than anticipated.