To the Limits, and Beyond

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.

Robert Hess
Microsoft Corporation

December 13, 1999


What's in the System?
How Can You Improve?
The Fire Test

Advancements in computer systems are coming about at a dizzying speed. Improvements are being made in almost every facet, almost faster than many of us can keep track. In order for these systems to constantly improve to meet our insatiable appetite for more raw power at our fingertips, it is important that the designers of these systems are able to push their designs to the limits.

A computer system is just that, a system that comprises many different parts coming together to provide a unified solution. It might be as simple as a little "calculator" application, or it could be a complex workflow system designed to integrate the document management of a business with offices spread around the globe.

What's in the System

As I see it, the facets of these systems can be broken down into the following core categories.

  • System Hardware: The computer itself. Processor, memory, I/O bus, storage, display, and so forth—the core hardware components that are found in virtually any computer.
  • Operating System: The underlying backbone on which applications are run. This could be as straightforward as code that reads in a binary application image from disk, stores it in system memory, starts execution, and gets out of the way. Or it could be a feature-rich application environment, such as the Windows operating system, which is continually upgraded to add more capabilities and enhanced features to the applications it supports.
  • Programming Language/Compiler: For the most part, without a programming language in which to develop an application and a compiler/interpreter of some sort to convert this set of instructions into an executable form, computers would be pretty worthless. You can choose from many different forms of programming languages and development environments, each of which attempts to address similar issues in a manner that uniquely applies to its targeted user base.
  • Peripherals: The ability to enhance the functionality of a computer by adding printers, modems, scanners—and other devices that may not have even existed when the computer itself was designed—is paramount to the computer's success. Every once in a while, a computer might come out with little, if any, expansion capabilities. On virtually all of these systems, one of the first "enhancements" added includes some provision for adding peripherals.
  • Applications: Finally, we get down to the actual applications themselves. Without an application that actually provides some form of specialized functionality for the user, a computer would be little more than a slightly animated box sitting on your desk.

I suppose if I wanted to nitpick further about describing a computer system, I might include such things as networks, disk drives, data paths, and so on—but hey, I've got to get to the point of this article some time.

How Can You Improve?

It is human nature to want things to be constantly improved. Bigger. Better. Faster. The continual advancements turn products that were once considered cutting-edge into obsolete castoffs. The designers of products need to push themselves to address new and bigger problems even before users know these problems exist. But how do you approach this drive for increased productivity? How do you stress your design skills and philosophies to their limits to determine how they can be improved?

I've got a theory.

As I look back on my own experiences with computers and application programming, I think about where I learned the most about writing highly effective applications. What I did to really uncover all of the capabilities of a programming language. How I took the computer hardware to its limits and tried to get it to produce even more.


Some of my earliest programming was toward writing games in BASIC and FORTRAN. I found this far more instructive and challenging than developing cost-analysis solutions, investment-rate-of-return calculators, or other sorts of programs that are often included in "Programming 101" courses. The goal of most standard applications is to go from point A to point B, and then you're finished. Once you get to point B in a game, you realize that you are simply in a better position to see what can be added to the program to reach C, and D, and ...

Many of the rich, complex games we have today are an outgrowth of people working on some very early games, such as "Adventure," and trying to add just a little more to make the game engrossing. Constantly pushing the available capabilities of the computer systems to their limits. Squeezing out some functionality that might otherwise have been thought impossible. I remember playing "Castle Wolfenstein" on my Apple II, and hearing voice synthesis coming out of the very rudimentary speaker systems they had—truly amazing. "Ultima," "Flight Simulator," "Doom"—and many other games that attempt to break us free of the expected confines of a computer—are always skirting the limits that try to contain them.

The Fire Test

Even when considering what might normally be identified as a "business usage" system, game development can be seen as a fire test of its ability to provide the best possible platform for non-game usages as well. At a large computer conference, far more years ago than I want to admit, I saw what we then referred to as a "mini computer"—but which today would more than fill my office. On one of its displays, it was running a vector graphics "Lunar Lander" program. I asked one of the technicians what this was all about, and he replied that they were basically displaying it just to attract attention, but it was also in fact one of their key field test programs. Any time they went out to a customer's site to do system maintenance and repair, they wouldn't consider the site running until after they had run through a few games of "Lunar Lander." In addition to being a fun way to close off the visit, it also represented a pretty intensive exercise of virtually all of the key systems. Many times, systems that appeared to be functioning properly would crash during a game of "Lunar Lander." On further investigation, the technician would be able to find some device or component that was functioning at only marginal levels.

For the most part, I think the advancements that such imaginative game programming has heralded have all but gone unnoticed by the designers of "real" applications. It is my belief that the best way to determine the limits of a programming language, operating system, or hardware configuration is to attempt to program the best game you can on it. You'll not only be exploring the limits of the computer system, but you'll be examining your own limits as well.

Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own.