MODULAR WINDOWS AND THE CONSUMER ENVIRONMENT: A RESPONSE

Phil Barrett and Byron Bishop are development managers in Microsoft’s Multimedia and Consumer System’s Group. This is their response to Dougherty’s commentary on Modular Windows.

We would like to thank Digital Media for a chance to reply to Brian Dougherty’s sincere but misguided assessment of Modular Windows. We are very heartened by the market’s initial reaction to Modular Windows and the following will hopefully explain some of the reasons for the market’s positive reaction.

The first misconception presented is that Modular Windows is an operating system for so-called PDAs. In fact, Modular Windows 1.0 is an operating system for consumer devices that use televisions as a display. The features included in Modular Windows 1.0 were carefully chosen to meet the needs of audio-visual applications such as interactive books — a very different type of application than that usually ascribed to PDAs.

Next, Mr. Dougherty decries Modular Windows for its Microsoft Windows heritage. We, of course, believe that this is a key strength. Modular Windows is based on Windows 3.1 and as such, inherits most of what continues to make it great for developers. There are hundreds of third-party development tools and libraries. A quick glance through one of the catalogs that specialize in software development tools will verify this. There are at least 100,000 developers who are already familiar with the Windows APIs. There are numerous authoring tools for Windows that allow people who are not hard-core assembly language or C programmers to design and implement applications. Examples are Microsoft Viewer, Microsoft Visual Basic, Aimtech’s Icon Author, Asymetrix’s ToolBook and Owl International’s Guide. There are also thousands of high-quality applications written to this API. Again, a quick glance through a catalog will show this, too.

This extensive infrastructure for Windows-based development systems, development and authoring tools, and market knowledge gives both existing and emerging digital content creators a running start compared to brand new, untested operating environments with limited tool support.

Equally important, for those applications where appropriate, a single title can be produced for play back on multiple devices — for example, a Modular Windows system and a Multimedia PC (MPC). There is a powerful incentive to author titles this way because it allows an ISV to enter a new market for a small incremental cost. Tools exist to make it easy for a software developer to optimize an application for both the MPC (with a large secondary store) and Modular Windows (with its hand controller for input and TV for output).

With regard to Modular Windows, the existing product and future implementations are an OEM product line and thus will be customized by hardware developers. The key is that each product based on Modular Windows is optimized to the constraints and the opportunities of the platform.

As a simple example, Modular Windows for a hardware platform with no audio capability would not be burdened with unnecessary audio application programming interfaces (API).

We agree with Mr. Dougherty that smaller code, less memory, higher performance and longer battery life will be critical for success in these new consumer markets. The current version of Modular Windows takes less than 1 MB of ROM for a complete CD-ROM player product and executes directly from ROM. This includes all the necessary support for the CD-ROM, audio and video. Moreover, Modular Windows 1.0 uses less than 256K of RAM, which means that on a 1-MB system the vast majority of system memory is dedicated to the application.

Modular Windows 1.0 is not just a cut down version of Microsoft Windows. We have added a number of features in Modular Windows 1.0 that make it an appropriate base for television-connected, CD-ROM-based consumer products. We have added a hand controller API that makes it easy to use a variety of remote controls often found in these consumer products. We added an API to allow the user to navigate on the screen with directional buttons in addition to the traditional “random roam” mouse-style navigation.

We added user interface elements that are more appropriate for TV connected devices. A television is quite different from a computer monitor. It has lower resolution. It is viewed at a distance typically greater than six feet while a computer monitor is usually viewed from much closer. Color intensity needs to be handled differently. We adapted the Modular Windows UI controls to work well in this environment.

Mr. Dougherty says that the only feature in Modular Windows 1.0

that VIS developers use is memory management. He is just plain misinformed. Among the Modular Windows’ features commonly used by VIS applications are its graphics primitives (GDI), Television User Interface, streaming audio services, MIDI synthesis capabilities, file I/O, and software motion video (Video for Windows) playback. We know of no other consumer operating system that provides this broad a range of capabilities, much less fits them into 1 MB of ROM.

Because Modular Windows builds on the PC heritage, it makes life very easy for the hardware manufacturer. CD-ROM extensions are a good example. An OEM does not need to write any code to integrate a CD drive. Another example is a flash memory file system; an OEM need not write any code to utilize flash memory in its system.

Modular Windows for future platforms will share the same mix of targeting the right features for the platform and the right levels of compatibility. For example, we agree wholeheartedly that a consumer device for receiving electronic information will be less enjoyable than print if it does not have the same production values. However, the strength of the Modular Windows strategy allows us to consider the platform’s ROM budget, screen size and resolution when making design decisions; whether to include TrueType, lots of fonts, and downloadable fonts; or TrueType and two fonts; or just three raster fonts.

Let’s now consider Mr. Dougherty’s repeated arguments that Windows must be inefficient because Microsoft Word for Windows requires 15 MB of disk space. Breaking this number down is quite instructive. Word’s executable itself is 1.2 MB. This represents a tremendous amount of functionality: tables, stylesheets, multilingual support, sophisticated search and replace, macros, outlining, mail-merge, and so on. The list is huge. The remaining 13.8 MB includes content intensive information: extensive help files, tutorials, dictionary, thesaurus, format translation libraries for importing third-party documents, charting and drawing tools, and so on. That Microsoft Word for Windows can deliver such a range of functionality to its users is in no way an argument against Modular Windows’ suitability for consumer systems. What Mr. Dougherty seems to be identifying is a well-understood trend in the PC industry toward feature-rich applications in order to compete for the consumer’s dollars.

Mr. Dougherty is incorrect in his assumption that Object-Oriented (OO) systems automatically produce smaller applications. It is true that when an application’s functionality is well matched with the functionality of the underlying system objects, the application will be “small” when compared to the same application on a system where the match is not as strong. An equivalent word processor on any OS would be as large as Word for Windows except to the degree the size of the OS was substantially increased to include objects provided in Word for Windows; for example, a thesaurus.

The claim that Modular Windows is not object oriented and thus every mouse click must be handled by the application is equally misleading. The various control classes are objects provided to aid the application developer in this very task. Windows may lack some of the buzzwords of OO systems, but not the benefits. For example, Windows programmers regularly subclass controls to modify the default behavior of the control. In addition, OO programming is more than just a technique; compilers, debuggers and class libraries are needed to complete the picture. There are a number of C++ compilers available from the major programming tool vendors for Microsoft Windows and these come with debugger and class libraries.

Every designer of a system that must meet resource constraints is faced with the same issue: How much and what functionality to put in the OS and what freedom to leave for application developers. The appropriateness of an OS for a given platform must be judged on this issue. The argument over which system is more truly object oriented is irrelevant.

Next, let us address some of the other issues raised in Mr. Dougherty’s article.

Mr. Dougherty claims that separate code is required for the printer and the screen. This is a gross exaggeration. The font model is common to both screen and printer output. The basic API works for both cases. Exceptions are largely due to differences arising from the physical realities of the printing device. For example, a full-page image may not fit in memory and thus ‘banding’ is required to allow an image to be prepared. It is also instructive to examine the graphics component of the Win32 API that Microsoft is moving to. It contains many improvements that software developers have asked for. This is an example of our commitment to improving the computing environment for software developers. Many of these enhancements will be available in a future version of Modular Windows.

Mr. Dougherty suggests that Modular Windows’ multitasking model is somehow a problem. We disagree — for a device such as a VIS player in which only one application is active at a time, nonpreemptive multitasking works great and gives the developer control over the machine. In addition, were one to examine the Win32 API and stated future directions of Microsoft, one would see that preemption

is a feature in future versions of Microsoft Windows and thus, Modular Windows.

Mr. Dougherty implies that Modular Windows is incapable of clean multimedia. This claim really baffles us. Microsoft Video for Windows, which is included in Modular Windows 1.0, has been released to kudos from both developers and analysts. For example, Byte magazine conferred upon VfW their award for best multimedia Software at Comdex in November, 1992.

One of the points Mr. Dougherty and we appear to agree on is that the success of a platform is due to the strength and quality of the commitment of software developers to that platform. Any microprocessor-based product category that succeeds will do so because of the applications that software and content developers produce for it. Every design decision in Modular Windows was made to help developers succeed in this new market.

Modular Windows isn’t perfect — we’ve got a lot of work ahead of us to make it even better. However, the feedback we’ve gotten from developers in general has been almost uniformly positive (except, we must admit, from developers of competing operating systems). We believe Modular Windows 1.0 is a very strong foundation for the interactive media industry to build on.

Phil Barrett, Byron Bishop