A mouse with modest requirements

Reprinted from Byte, issue 12/1983, pp. 48-54.

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.

Running Microsoft Windows

Photos 1-13 show a sequence of operations in Microsoft Windows. The photos on pages 52-53 show a variety of machines whose manufacturers have adopted Microsoft Windows as an applications environment.

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.

Photo 13 shows the graph displayed in accordance with the instructions entered – with a 4 by 4 pixel-pen size and a gray shading. The graphics capabilities of Microsoft Windows owe much to the device-independent graphics system described by John Butler in the text box “Device-Independent Graphics Output for Microsoft Windows” on page 49.

Conclusions

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.

by Phil Lemmons

Phil Lemmons, BYTE’s West Coast Bureau Chief, can be reached at McGraw-Hill, 425 Battery St., San Francisco, CA 94111.

Sidebars:

	“Device-Independent Graphics Output for Microsoft Windows”
	“Some machines that run Microsoft Windows”

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.

Phil Lemmons