Legal News on PressPass

1. My name is Christopher Jones. I am currently Vice President of the Windows Client Team of the Platforms Group at Microsoft Corporation.

2. I graduated from Stanford University in 1991 with a bachelor’s degree in mathematical and computational sciences. I worked as a summer intern at Microsoft while in college, and I began working full time at Microsoft in the fall of 1991.

3. In my first full-time position at Microsoft, I worked as a program manager on a product called Microsoft Publisher, which is a desktop publishing application that runs on Windows. As program manager for Microsoft Publisher, I was responsible for (i) evaluating the marketplace for the product, (ii) determining what features would be included in the product, (iii) preparing the technical specifications for the product’s features, and (iv) project management through the design, development, testing and debugging stages of the product.

4. In late 1994, I moved to a new position and began working as a technical assistant for Paul Maritz, a Microsoft senior executive who at that time was in charge of coordinating Microsoft’s technical three-year plan. In this position, I helped Mr. Maritz work with different groups at Microsoft to determine their views about the direction Microsoft should take in the upcoming three-year period.

5. I became the Group Program Manager for Internet Explorer in the middle of 1995, and I was then promoted to General Manager for Internet Explorer in late 1997. In those positions, I worked on the teams that developed and released the components of Windows called Internet Explorer 3, 4 and 5, which were released in the fall of 1996, the fall of 1997 and the spring of 1999, respectively.

6. In the spring of 1999, I became project manager for a project at Microsoft code named “Neptune.” Neptune was an effort to take the software code for the Windows 2000 operating system—which was targeted primarily at business users—and modify it to create an operating system suitable for use in home environments. The Neptune project ultimately led to the development of the Windows XP operating system, which was released in October 2001. I was the project manager for Neptune until late 1999, at which point Microsoft reorganized its management structure and I was promoted and began working in my current position as Vice President of the Windows Client Team. In that position, I continued to supervise the work that culminated in the release of Windows XP.

7. In my current position at Microsoft, I am principally responsible for (i) defining and driving new releases of Windows client operating systems (as opposed to server operating systems) and (ii) managing the various technology teams within my organization that contribute to the development of Windows operating systems (both client and server) as a whole. My testimony is based on my experience working at Microsoft for over ten years and my position as the Microsoft executive responsible for product development for the Windows client operating system family.

8. I believe that the success of Windows as a platform results from Microsoft’s vigorous efforts to achieve four goals:

· Develop platform software that provides Windows users with a simple and intuitive means of accessing the features and functionality of their computer;

· Design the Windows operating system so that it runs efficiently and exposes a stable and consistent platform that may be called upon by other parts of the operating system and by third-party software products;

· Work directly with a wide range of independent software vendors (“ISVs”) to enable them to create for consumers compelling software products that run on top of Windows; and

· Work directly with a wide variety of other vendors—independent hardware manufacturers, computer manufacturers, internet service providers, and many others—to enable them to create compelling products for consumers who purchase or use personal computers running Windows.

9. I have reviewed the remedies proposal made by the non-settling States in this case (“States’ Remedy Proposal”), and I believe that it would interfere with Microsoft’s efforts to achieve all of the above goals, causing harm not only to Microsoft but also to the consumers who use Windows and the many other hardware and software companies that develop products and services that work with Windows. I discuss below the ways in which the States’ Remedy Proposal will cause such harm.

10. I have also reviewed the proposed consent decree (“Proposed Consent Decree”) reached between Microsoft and the United States and the nine States that agreed to settle this case. Microsoft has already begun to comply with the Proposed Consent Decree, and I have received training about Microsoft’s obligations under that decree. As I discuss in more detail below, complying with the Proposed Consent Decree has required—and will continue to require—Microsoft to alter its business in a number of important ways. Nevertheless, I believe that Microsoft will be able to comply with the Proposed Consent Decree while still meeting the goals noted above—providing consumers, ISVs and other businesses with a vibrant Windows operating system that provides a stable and consistent platform for the development of complementary products.

11. In this Part of my testimony, I will provide a brief explanation of how Windows XP relates to prior versions of Windows offered by Microsoft. I will then explain some of the work Microsoft has done to make Windows XP more intuitive and easier to use than prior versions of Windows. Finally, I will set forth what I believe to be the negative effects that the States’ Remedy Proposal will have on Microsoft’s ability to provide consumers with a simple, consistent and easy-to-navigate interface to their personal computers.

12. Windows XP is the current version of Microsoft’s desktop (or client) operating systems. In fact, Microsoft currently offers Windows XP in two forms—Windows XP Home Edition and Windows XP Professional. Windows XP Professional is largely the same as Windows XP Home Edition, but it contains some additional features (such as remote desktop, support for multiple processors, business networking support and file encryption) that certain business users and other “power users” may want to have in their operating system. For the sake of simplicity, I will sometimes refer to both Windows XP Home Edition and Windows XP Professional collectively as Windows XP.

13. Windows XP is the successor operating system to Windows 2000 Professional. By “successor,” I do not just mean that Windows XP was released after Windows 2000 Professional. I also mean that Windows XP and Windows 2000 Professional are related to each other in the sense that Microsoft did not create Windows XP from scratch, but rather took the software code for Windows 2000 Professional and modified it to improve its performance and to add a number of significant features and thereby create a new operating system.

14. Conversely, although Microsoft released Windows XP after several other operating systems that are familiar to many consumers—Windows 95, Windows 98 and Windows Millennium Edition (“Windows ME”)—I would not refer to Windows XP as a true “successor” to these other operating systems. This is because Microsoft did not develop Windows XP by making modifications to the software code for Windows 95, Windows 98 or Windows ME. To illustrate this point graphically, the chart below shows the relationship between the various major versions of Windows desktop operating systems that have been released by Microsoft since 1993.

15. As the chart above demonstrates, prior to the release of Windows XP, there were two “lines” of Windows desktop operating systems—one based on the Windows 95 software code and one based on the Windows NT software code. These two lines of operating systems developed concurrently, but were based on different underlying software code. The two lines coexisted with one another up through the release of Windows ME and Windows 2000 Professional.

16. As noted above, I began working on a project called “Neptune” in the spring of 1999 to take the software code for Windows 2000 Professional and develop a Windows operating system that would replace the Windows 95, Windows 98 and Windows ME line of operating systems with a new operating system for home consumers.

17. The Neptune team worked throughout 1999 on this project. When Windows 2000 shipped, the Neptune team was combined with the Windows 2000 team, and together the teams worked through 2000 and most of 2001 to develop what was ultimately released as Windows XP. The project entailed a major software engineering effort. Although much of that engineering effort related to the addition of new features and functionality, a large portion of it was necessitated by the fact that Microsoft designs new Windows operating systems to be backwardly compatible (as much as possible) with software products, hardware products and other solutions designed to run on older Windows operating systems. Maintaining backward compatibility is always a challenge when releasing a new Windows operating system given the thousands of existing Windows applications and compatible devices. This challenge was made even more difficult in the case of Windows XP, because the operating system was being built from the Windows 2000 Professional code base, rather than the Windows ME code base. Microsoft therefore carried out extensive, costly and time-consuming compatibility tests to ensure that the thousands of software applications designed to run on Windows 95, Windows 98 and Windows ME would continue to function on Windows XP.

18. With Windows XP, Microsoft has now released operating systems for both home and business users built on the same underlying software code. Home users now benefit from the increased reliability and stability previously provided by Windows 2000 Professional, while high-end business users benefit from the intuitive and friendly user interface that historically made consumer versions of Windows operating systems so popular. Moving Microsoft’s consumer- and business-focused desktop operating systems to a common software code base also enhances the consistency and stability of Windows overall, because Microsoft will no longer have to divide its efforts to develop two parallel lines of desktop operating systems.

19. Microsoft is currently working on a family of server operating systems that will share the same underlying software code base as Windows XP. Those server operating systems are currently referred to as “Windows .NET Server” and were formerly code named “Whistler.” Microsoft widely released a Beta version of Windows .NET Server in November 2001 and currently anticipates commercially releasing the first Windows .NET Server operating system sometime later this year.

20. In my experience at Microsoft overseeing the development of operating systems for personal computers, I have learned that despite Microsoft’s best efforts to make them user-friendly, many consumers still find personal computers difficult to use. Novice users, in particular, often have difficulty with basic concepts such as starting applications, storing and locating files, and navigating through Web pages on the Internet. The easier and more intuitive Windows is for users, the more people will want to use the operating system and applications that run on it. Conversely, making it more difficult to configure and use Windows would lead to consumer dissatisfaction and lower demand for Windows, for personal computers generally and for related hardware and software products.

21. To improve the user experience, Microsoft strives to make each version of Windows easier to use than its predecessors. Microsoft accomplishes this goal by maintaining consistency between successive versions of Windows, while continuing to add new features and functionality that Microsoft believes will provide Windows users with greater value. It is by design, an evolutionary rather than a revolutionary process. Microsoft also conducts extensive usability testing and beta testing to receive feedback from customers and companies that use Windows or build Windows compatible solutions.

22. To make Windows easy to use, Microsoft endeavors to maintain consistency in the look and feel of the operating system, so that users who have learned to use Windows on one computer will be able to apply what they have learned if they use Windows on a different computer at a later point in time. Thus, a consumer with a copy of Windows XP on her home computer will find it relatively easy to use a computer at work or at a friend’s house that is also running Windows XP.

23. Microsoft tries to ensure consistency in two principal ways. First, Microsoft requires that computer manufacturers (commonly referred to as “Original Equipment Manufacturers” or “OEMs”) who install Windows on personal computers leave certain core features of the user interface intact, so that those core features will be present across all brands of computers on which a given Windows operating system is installed. Second, Microsoft retains certain core features of the user interface as successive versions of Windows are released, so that users will be able to locate and use those features regardless of whether they are using Windows 95, Windows 98, Windows ME or Windows XP.

24. Let me illustrate my point by example. In Windows 95, Microsoft added a feature called the “Start” menu to the Windows user interface. The Start menu is displayed when a user clicks on the “Start” button, which appears in the lower-left corner of the screen after a user turns on a computer running Windows and the operating system has completed its start-up sequence and displayed the Windows desktop. The screen shot below shows the Start button as it appeared on the standard Windows desktop of Windows 95.

25. By clicking on the Start button and accessing the Start menu, users can launch applications, search for files, configure various Windows options and even shut down their computer.

26. Before the introduction of the Start menu with Windows 95, Windows users typically launched applications by clicking on icons that appeared on the Windows user interface. Even today with Windows XP, users can still launch applications and access other features of the operating system by clicking on icons that they place on the Windows desktop. Desktop icons can sometimes provide an easy way for users to open applications—particularly when the computer is first turned on. But desktop icons are not an ideal means for accessing multiple applications and files simultaneously—something that Windows users increasingly do. This is because once a user opens one application, the Windows desktop is normally covered by the application itself, so icons on the desktop are not immediately visible to the user. Some users get confused about how to get back to their desktop to launch another application once they have the first application covering the entire screen.

27. The Start menu provides users with a simpler and ultimately more intuitive means of accessing applications and other information on their computers—they click “Start” to start doing whatever they need to do. The Start menu is also more readily accessible than desktop icons, because the Start button is normally visible at all times, regardless of whether or not a user has one or more applications running. It provides users with a single place to go to accomplish important tasks, and such simplicity is powerful especially for relatively unsophisticated users.

28. To encourage Windows users to become accustomed to launching applications and opening files by using the Start menu, Microsoft has consistently maintained the Start menu as Windows has evolved since 1995. The images below show the standard Windows desktop for Windows 98, Windows ME and Windows XP. In each image, the Start button appears in the lower-left corner of the screen.

29. Because of the consistency that Microsoft has maintained between successive versions of Windows, a user who learned to use the Windows 95 Start menu seven years ago would likely be able to sit down to a computer running Windows XP today and begin using the operating system with little difficulty. Although Microsoft believes that it has improved the Windows user interface dramatically over those seven years, the Start menu paradigm has remained central to the design.

30. In addition to the Start menu, Microsoft has maintained other features of the Windows user interface over time to provide users with a consistent experience that makes it easier for them to use computers running Windows. These features include (i) the “Taskbar” (from which users can quickly switch between the programs running on their system) and (ii) the “Recycle Bin” icon (into which users can drag files that they want to delete from their computer).

31. The consistent layout and operation of the Windows user interface also provides benefits to people who are blind or visually impaired. Microsoft expends significant effort in making Windows operating systems accessible to persons with physical disabilities, including people who are blind or visually impaired. This effort includes the creation of Audio Help for Windows XP, which enables users to obtain help from the operating system by listening, rather than by reading. In addition, Windows XP contains both Windows Magnifier, which permits users to enlarge text or pictures displayed on the screen to make them easier to see, as well as Windows Narrator, a text to speech capability that will read information to users whose vision is impaired.

32. With Windows XP, Microsoft implemented a variety of new features to make the user interface simpler and more adaptive to what the user is doing with operating systems. I will discuss two of these new features—the “Desktop Cleanup Wizard” and the “Most Frequently Used” section in the Windows Start menu.

a. Desktop Cleanup Wizard

33. As noted above, users sometimes invoke operating system features, launch applications and open files by clicking on icons on the Windows desktop. Sometimes the icon is placed on the desktop by Microsoft—such as the “My Computer” icon. In other instances, an icon may be added to the Windows desktop by an OEM.

34. Microsoft has learned over the years that Windows users sometimes rely on both the Start menu and on desktop icons to access applications and files. But many desktop icons are never used or go unused for months at a time, resulting in needless “clutter.” In these instances, Microsoft believes that the user interface can be simplified by removing unused or infrequently used icons from the Windows desktop. In Windows XP, Microsoft added a feature called the “Desktop Cleanup Wizard” to accomplish this task.

35. The Desktop Cleanup Wizard keeps track of which desktop icons are used and which are not. It will check with a Windows user 14 days after the user first begins using Windows XP to see whether the user would like to “cleanup” her desktop by moving icons that have not been used during the preceding 14-day period to the “Unused Desktop Shortcuts” folder. After the first 14 days, the Desktop Cleanup Wizard checks with a Windows user every 60 days. The Desktop Cleanup Wizard does not delete icons from the operating system and does not move unused icons automatically. Rather, it asks permission from the user before it moves icons from the Windows desktop into the Unused Desktop Shortcuts folder. Indeed, as demonstrated in the screen shot below, the Desktop Cleanup Wizard identifies for the user the individual desktop icons that have not been used recently. As the screen shot also demonstrates, the Desktop Cleanup Wizard applies to both components of Windows like Internet Explorer and Outlook Express as well as to third-party applications like Adobe Acrobat.

36. The user can then choose which of these icons she would like to keep on the desktop and which she would like to move to the Unused Desktop Shortcuts folder. As shown below, the Desktop Cleanup Wizard then confirms with the user which icons will be removed from the desktop and placed in the Unused Desktop Shortcuts folder.

37. After the Desktop Cleanup Wizard finishes, it places an “Unused Desktop Shortcuts” folder on the desktop, as shown in the screen shot below.

38. Because the Desktop Cleanup Wizard does not actually delete the icons, users can drag and drop the icons from Desktop Cleanup Wizard folder back to the Windows desktop at any time.

b. Most Frequently Used Section of Start Menu

39. As noted above, Microsoft retained the Start menu in Windows XP from earlier versions of Windows because Microsoft continues to believe that the Start menu provides Windows users with an intuitive method for initiating whatever they want to do with their computer. Microsoft improved the Start menu in Windows XP by adding a Most Frequently Used section. As its name implies, the Most Frequently Used section of the Start menu displays the programs that the user actually uses the most. The Most Frequently Used section automatically modifies its contents as the user modifies her usage of programs over time. The screen shot below provides an example of what the Windows XP Start menu (including the Most Frequently Used section) could look like after a user had used Windows XP for a period of time.

40. The Most Frequently Used section consists of the six icons in the lower-left corner of the Start menu. In the above example, RealOne Player, Adobe Photoshop 6.0, Adobe Illustrator 9.0, Winamp, WinZip 8.0 and Palm Desktop are the six most frequently used programs. Windows XP tracks how often all programs are used and constantly updates the list so that the six programs that appear in the Most Frequently Used section are those that are actually most frequently used.

41. Users can, at any time, choose the programs they want to use for Web browsing and email. They can also “pin” programs above the line on the left side of the Start menu, or delete any program from the Most Frequently Used section. In versions of Windows XP preinstalled on new personal computers by OEMs, the OEM can choose which programs are preset for Web browsing and email. Microsoft pre-populates three of the six slots in the Most Frequently Used section of the Start menu and the OEM can pre-populate the other three slots if it chooses to do so. In addition, the OEM can add a link below the “Run” command on the lower right corner of the Start Menu that launches a program or web site of the OEMs choosing. The algorithm by which more frequently used software programs displace the ones that appear initially in the Most Frequently Used section of the Start menu works the same way with respect to Microsoft and non-Microsoft software programs. As a result, once a consumer begins using a new personal computer running Windows XP, over time the software programs that appear in the Most Frequently Used section will become the ones that the consumer uses most frequently, regardless of whether the software programs are supplied by Microsoft or the OEM.

42. As noted above, I have reviewed both the States’ Remedy Proposal and the Proposed Consent Decree. Both proposals contain provisions that would affect the Windows user interface. However, while the Proposed Consent Decree places restrictions on Microsoft’s ability to configure the Windows user interface, it does so in way that permits Microsoft to continue to provide users with a consistent and easy-to-use operating system. In contrast, the States’ Remedy Proposal would substantially undermine Microsoft’s ability to ensure that Windows users receive an operating system that is consistent with predecessor versions of Windows and that contains the ease-of-use enhancements that Microsoft has added to Windows XP to make personal computers more appealing to consumers.

43. Section III.C.1 of the Proposed Consent Decree requires Microsoft to give OEMs the general ability to install and display icons, shortcuts and menu entries for Non-Microsoft Middleware on the Windows desktop or in the Start menu. For example, looking at the screen shot of the Start menu below, Section III.C of the Proposed Consent Decree would require Microsoft to allow an OEM to set Netscape Navigator as the icon for Internet and E-mail, and pre-populate all six of the items in the Most Frequently Used section of the Start menu.

44. The exception to Section III.C’s general rule is that Microsoft can restrict OEMs from placing icons, shortcuts and menu entries on a list of products when the list has been designed to show products that provide particular types of functionality. For example, in the screen shot above, there is an entry for “Printers and Faxes” on the right-hand side. If a user clicks on that entry, she will open up a list of the printers and faxes that can be accessed from her computer. The following screen shot shows the list that appears when the user clicks on that entry.

45. Section III.C would allow Microsoft to prevent an OEM from placing an icon for AOL’s Instant Messenger software on the above list of printers and faxes, because AOL’s Instant Messenger does not provide printing or faxing functionality. The restriction in Section III.C makes sense, because it would be confusing to users if they found icons for instant messaging software in the “Printers and Faxes” list accessible from the Start menu.

46. Additionally, Section III.C.2 of the Proposed Consent Decree requires Microsoft to permit OEMs to promote Non-Microsoft Middleware by placing icons of any size or shape on the Windows desktop, so long as the icons to not impair the functionality of the user interface. Allowing OEMs to place oversized desktop icons anywhere they want on the Windows desktop could obscure important aspects of the user interface. For example, an OEM could place an oversized icon for RealNetworks’ multimedia playback software on the Windows desktop such that it covered the Start button or obscured the Recycle Bin. Obscuring these elements of the user interface would make Windows more difficult for consumers to use, and the inability to find familiar features of the operating system that consumers have come to expect would be frustrating.

47. The States’ Remedy Proposal does not contain similar provisions that would protect the integrity of the Windows user interface. Rather, Section 2.c of the States’ Remedy Proposal would permit OEMs to place icons of any size or shape anywhere on the Windows desktop or Start menu that they might wish, without regard to how the placement of such icons might affect the user interface or the functionality that Microsoft has developed to make Windows an intuitive and easy-to-use operating system.[1] For example, an OEM could cover the Start menu with an icon and thus disrupt a key feature of the user interface that Microsoft has consistently offered as part of Windows since 1995. In fact, Jonathan Schwartz of Sun Microsystems testified expressly that OEMs should be permitted to place icons on top of the Start button. Customers who purchased this version of Windows would not have an experience consistent with their expectations for a Windows system. In addition to creating customer confusion and frustration, through the use of an alternate user interface—which could be branded as the “AOL PC” or “IBM Windows”—Microsoft’s competitors could appropriate Microsoft’s research and development efforts relating to layers of the operating system running beneath the user interface and market Microsoft’s creation as their own. Windows is an extremely valuable brand, and the Windows user interface is the most readily-accessible aspect of operating systems that Microsoft spends billions of dollars per year to develop. I do not understand why OEMs and Third-Party Licensees should be able to make drastic alterations to the Windows user interface, yet continue to tell consumers that their product is “Windows.”

48. Section III.C.3 of the Proposed Consent Decree requires Microsoft generally to permit OEMs to launch Non-Microsoft Middleware automatically at the conclusion of the initial boot sequence or upon a connection to or disconnection from the Internet if a Microsoft Middleware Product that provides similar functionality would otherwise be launched automatically at that time. For example, if the Windows Messenger instant messaging software launches automatically when a user connects to the Internet, this provision would enable an OEM to configure the computer so that AOL’s Instant Messenger software automatically launched at that time. Section III.C.3 permits Microsoft to require, however, that such automatically launched Non-Microsoft Middleware either display no user interface or display a user interface of similar size and shape to the user interface displayed by the equivalent Microsoft Middleware Product. Section III.C.3 would also permit Microsoft to prevent an OEM from (i) automatically launching a user interface that completely takes over the Windows desktop and prevents the user from ever seeing the Windows user interface or (ii) automatically launching other applications that hamper system performance.

49. The States’ Remedy Proposal contains no requirement that OEMs allow the Windows user interface to display at all at the conclusion of the initial boot sequence or upon a connection or disconnection from the Internet. Indeed, Sections 2.c.iii and 2.c.iv of the States’ Remedy Proposal would allow an OEM or “Third-Party Licensee” to automatically launch any non-Microsoft software product from within Windows without regard to whether such software completely covered over the Windows Start menu, the Recycle Bin or any other part of the Windows user interface. In fact, those provisions would permit OEMs to use Windows XP as a so-called “boot loader” that launched Linux or some other operating system. That would be extremely confusing to users who expected to see the Windows desktop at the conclusion of the initial boot sequence and found themselves in an unfamiliar operating system instead.

50. Even if third-party software programs do not completely obscure the Windows user interface, automatically launching them during or at the conclusion of the initial boot sequence extends the time it takes users to get a new personal computer up and running. For example, Internet access offers presented by OEMs during the initial boot sequence extend the time that it take users to complete the boot-up process and arrive at the Windows desktop. For novice users, it is important to make what is known as the “out of box” experience as fast and painless as possible. Long diversions during the initial boot sequence extend and complicate the process of getting a new personal computer up and running. Many consumers who purchase a new personal computer have an existing Internet access service, so it is important that these users be able to quickly opt out of any Internet access offer during the out of box experience. Moreover, if such Internet access offers are not properly designed, they can confuse and frustrate users, interfere with the initial boot sequence or, even worse, destabilize the personal computer. This is not merely a hypothetical possibility. Some OEMs have created Internet access offers in the initial boot sequence that are very difficult for consumers to escape from if they change their mind. Moreover, because consumers normally assume that Microsoft is responsible for what appears during the initial boot sequence, improperly designed Internet access offers can decrease customer satisfaction with Windows and harm Microsoft’s reputation as a supplier of high quality software products.

51. Automatically-launched software programs also consume system resources and thus make new personal computers run more slowly out of the box—an occurrence that is frustrating to users. OEMs can pre-install a wide variety of software on new computers, and place links to that software on the desktop, the Start menu or other locations. To expedite the initial boot sequence and ensure that Windows functions well upon completion of the initial boot sequence, Microsoft requires that only software required for anti-virus and hardware support be running on a new personal computer at the end of the initial boot sequence. Such requirements—which are not intended to interfere with the promotion or distribution of Non-Microsoft Middleware Products—would not be allowed under the States’ Remedy Proposal.

52. Finally, automatically launching software programs upon an initial connection to the Internet could interfere with users’ ability to get connected to the Internet, which is an important task for users and one that Microsoft wants to make as fast and easy as possible. The Proposed Consent Decree recognizes that OEMs should be permitted to launch such software programs if Microsoft does so—including non-Microsoft Middleware Products—but it does not give OEMs unbridled discretion to launch whatever software products they want every time a user connects to the Internet.

53. Having set forth what I believe to be the harmful effects of the States’ Remedy Proposal on the functionality of the Windows user interface—which is what users actually see on their computer screens—I would now like to look at parts of the operating system that users normally do not see. There are thousands of components of Windows XP that enable the operating system to perform efficiently and expose functionality that can be called upon by other (visible and invisible) parts of the operating system as well as by a wide range of third-party software products.

54. Microsoft has designed its Windows operating systems—including Windows XP—as “componentized” software products. It is important, however, to understand exactly what “componentized” means in the context of Windows XP. The Windows operating system is not a collection of independently functioning pieces of software code that can be viewed as isolated islands of functionality, as Professor Appel has suggested. Rather, the Windows operating system consists of large numbers of specialized blocks of software code that rely on each other to perform the tasks that the operating system was designed to accomplish. In order to avoid duplicating the same functionality in every block of software code, the operating system components call upon one another to perform particular tasks. This eliminates redundancy and improves performance, and it also creates huge numbers of cross-dependencies among blocks of software code. Given those cross-dependencies, it is not possible to pull an arbitrary block of software code out of the Windows operating system and expect the rest of the program to continue to function as before. It won’t.

55. Let me illustrate the concept of componentization by starting with a real world example. Assume for a moment that I want to operate a small fast-food restaurant with three employees and that running the restaurant essentially entails three basic functions—taking orders from customers, cooking the food, and restocking the refrigerator. I could train all three employees to do all three functions as needed to run the restaurant. Or I could assign each employee a particular function that they could become very good at performing, and as a group they would run the restaurant. Assigning particular employees to particular functions is a form of componentization, which in the real world is often referred to as a “division of labor.” The division of labor in the restaurant example reduces the amount of training that each employee must receive and allows employees to develop specialized skills. At the same time, such specialization requires that all three employees show up for work each day and that they be able to rely on each other to run the restaurant.

56. Microsoft’s Windows operating systems are componentized in a similar manner. Microsoft creates specialized blocks of software code to perform particular functions within the operating system—such as allocating memory, maintaining the file system, displaying information on the computer screen and playing sounds. These specialized blocks of software code call upon each other when the operating system is asked to perform a complex task. When a word processing program wants to open a copy of a letter that the user saved in draft form a week earlier, hundreds of these blocks of software code are invoked. Microsoft also organizes the blocks of software code in Windows so that those supplying related functionality are located in the same file. This improves the performance of the operating system, because related pieces of software code can be loaded into the computer’s memory at the same time. The suggestion by Professor Appel that Microsoft places unrelated blocks of software code in the same files to make them difficult to remove is completely false. There are valid engineering reasons for the placement of blocks of software code into particular files in Windows, and it has nothing to do with efforts to make the operating system difficult to disassemble. It is difficult to remove random blocks of software code from Windows, but that is the inevitable result of cross-dependencies among components of the operating system.

57. Componentizing an operating system improves performance in at least two ways. First, no single block of software code is responsible for supplying all of the functionality of the operating system. Instead, each block of software code can be tailored to perform its particular function efficiently—and only its function efficiently—so that only the code required to perform the function is loaded. Second, having different blocks of software code provide functionality to one another reduces redundancy and improves performance. For example, having the same block of software code repeatedly perform a given function consumes fewer system resources than having multiple blocks of software code perform the same function. If every block of software code in an operating system had to be designed as a self-contained unit, the operating system would grow very large and run very slowly. For example, Professor Appel’s suggestion that Microsoft could include several HTML rendering engines in Windows XP makes no sense to me at all. Having one such HTML rendering engine that all parts of the operating system—as well as applications running on top of the operating system—can call upon is the best solution from a variety of standpoints. There is less software code to design, develop and test, fewer system resources are consumed, there is no risk of HTML rendering engines developing inconsistencies over time, and it is easier to fix bugs and security problems because the relevant software code appears at one place in the operating system instead of five or ten.

58. As part of its efforts to develop and maintain Windows as a componentized operating system, Microsoft sometimes designs blocks of software code in conformity with what is called the Component Object Model (“COM”) specification. The COM specification is a formalized method for designating what functions a particular block of software code performs and how those functions can be called by other blocks of software code through specified interfaces. A COM “object” can be called upon by other blocks of software code that want to make use of its functionality. COM objects can themselves rely upon other COM objects as well as other blocks of software code that do not comply with the COM specification. As a result, COM objects can, and almost always do, have numerous cross-dependencies with other blocks of software code. To the extent such cross-dependencies exist, the removal of particular COM objects from a Windows operating system will cause other parts of the operating system to malfunction.

59. In general terms, the division of labor that exists in a componentized operating system means that Windows as a whole needs to be able to rely on any one of its components at any given moment. Such reliance is not possible if these pieces of the operating system are not present. Nor is it possible for the operating system to rely on particular blocks of software code if those blocks of software code are designed to be optionally removable by OEMs or other third parties. For example, Microsoft cannot design the Windows HTML-based Help system to rely on the HTML rendering engine in Internet Explorer unless Microsoft knows that the HTML rendering engine is going to be present in every copy of Windows. Professor Appel’s suggestion that Microsoft should rely on whatever Web browsing software an OEM might include in Windows XP is impractical. First of all, no other web browsing functionality on the market provides all of the functionality that the Windows Help system obtains from Internet Explorer. Moreover, Microsoft could not design the Windows Help system to rely on any one of the five or more different kinds of Web browsing software in existence because they all work differently and none of them exposes its HTML rendering functionality in exactly the same way. Finally, Microsoft could not do the sort of testing it must do to ensure that Windows is stable and reliable if it could not guarantee the operation of an important component like the HTML rendering engine. Contrary to Professor Appel’s apparent belief, Windows is not a series of Lego blocks that can be pulled apart and put back together in any combination. Instead, Windows is a highly complex and sophisticated software product with a wide array of cross-dependencies among blocks of software code, many of which are very difficult to predict, even from an examination of the source code of the operating system.

60. In this part of my testimony, I explain why it would be extraordinarily difficult—if not impossible—for Microsoft to comply with Section 1 of the States’ Remedy Proposal. I also explain how Microsoft, ISVs and consumers would be adversely affected by the requirement that Microsoft create versions of Windows that could be torn apart by OEMs and Third-Party Licensees.

61. Microsoft’s Windows operating systems were designed, developed and tested as unitary products. The various components of Windows were never conceived of as being separate from Windows 95, Windows ME, Windows 2000 or Windows XP—they function as a group and call upon each other depending on what the operating system needs to accomplish at a given moment in time. This is true, notwithstanding the fact that Microsoft sometimes distributes components of the operating system free of charge to the installed base of Windows users. For example, I know from my experience working on Internet Explorer 3, 4 and 5 that those components—when installed on older versions of Windows—replaced various files in the Windows operating system with new files to bring them up to a higher level of functionality. One of the benefits of a componentized operating system is that old components can be replaced with new components, but the replacement components have all of the cross-dependencies on other blocks of software code in the operating system that their predecessors had, and when replaced require systematic testing of the operating system to ensure that it continues to function correctly.

62. Because of the componentized architecture of Windows, it is not possible to remove arbitrary blocks of software code from a Windows operating system while ensuring that the balance of the operating system continues to work without degradation. If software code is removed from Windows, then it is obvious that the functionality supplied by that software code will disappear as well. Furthermore, if a given component of the operating system is removed, other portions of the operating system can no longer rely on the missing component, so their functionality may be impaired or destroyed as well. And there are tens of thousands of third-party products—both hardware and software—that rely on various components of Windows that would cease to function if those components were removed.

63. The componentized architecture of Windows renders provisions of the States’ Remedy Proposal extraordinarily broad. For example, Section 12 of the States’ Remedy Proposal would require Microsoft to grant a royalty-free license to Internet Explorer and to all of the Windows APIs “used or called” upon by Internet Explorer. But the Internet Explorer components of Windows operating systems make calls to numerous other blocks of software code in the operating system in providing Web browsing functionality. All of those other blocks of software code would thus fall within the open source licensing requirement of Section 12. Indeed, in the broadest sense (and I note that Section 21.c of the States’ Remedy Proposal requires that it be construed broadly), even the kernel of Windows operating systems would fall within Section 12’s open source license requirement, because all parts of the operating system use the kernel.

64. Section 12 does not define with any precision which blocks of software code in Windows 95, Windows ME, Windows 2000 and Windows XP would be subject to the requirement that Microsoft license its source code free of charge to competitors. This provision would thus require Microsoft to give to competitors like AOL and Sun Microsystems large chunks of the operating system, as well as any new features of Windows operating systems that relate broadly to Web browsing. Such a wholesale transfer of some of Microsoft’s most valuable intellectual property to companies like AOL and Sun Microsystems would enable those competitors to copy Microsoft’s innovations without having to make similar research and development investments. This provision would also discourage Microsoft from making any improvements to the Web browsing components of Windows, because Microsoft would have to give those improvements away to competitors for free.

65. Section 1 would require Microsoft to redesign Windows 95, Windows ME, Windows 2000 and Windows XP Home Edition and Windows XP Professional—five different operating systems—as completely “modular” products from which large numbers of components could be removed without causing the operating systems to malfunction—something the States’ Remedy Proposal refers to as an “unbound” version of Windows. Based on my experience as the Microsoft executive responsible for the development of Microsoft’s Windows client operating systems, the “unbound” versions of Windows contemplated by the States’ Remedy Proposal would bear no relation whatsoever to the versions of Windows that Microsoft markets today. This is because the definition of “Middleware Product” in the States’ Remedy Proposal requires that virtually any block of software code that exposes one or more application programming interfaces (“APIs”) to software developers be made optionally removable from Windows 95, Windows ME, Windows 2000 and two different versions of Windows XP.

66. To ensure that Windows continued to function “without degradation” after one or more blocks of software code had been removed by an OEM or Third-Party Licensee, Microsoft would have to redesign Windows to make each such block of software code independent from the rest of the operating system—that is, the operating system would have to make no calls to the optionally-removable blocks of software code. To do otherwise would invite disaster, because Microsoft would run the risk that other parts of the operating system would rely on blocks of software code no longer present. Let me give an example.

67. The file in later versions of Windows 95 and in Windows ME, Windows 2000 and Windows XP called MSHTML.DLL provides much of the functionality referred to by the trade name “Internet Explorer.” This file is included in Internet Explorer 6.0, and so it would appear that by definition it is included in the States’ Remedy Proposal’s definition of “Browser.” Internet browsers are included in the definition of “Microsoft Middleware Product” in the States’ Remedy Proposal, and Section 1 requires Microsoft to create versions of Windows from which the software code for Microsoft Middleware Products may be removed.

68. Removing MSHTML.DLL from Windows operating systems would break many important features of those operating systems, such as Windows Help, Windows Update and parts of the Windows Explorer. To prevent this from happening, Microsoft would have to redesign Windows to eliminate any calls that other parts of the operating system made to MSHTML.DLL. Contrary to what Professor Appel suggested, even for this single component, this would not be a simple task. It would require us to go back and redesign the parts of the operating system that rely on MSHTML.DLL, either by removing the capability, or by creating special versions of MSHTML.DLL for each part of the operating system. This in turn would cause a complete retesting of those parts of the operating system, and well as additional performance work, and would take months to accomplish. The resulting products—when and if they were ever commercially released—would be less appealing to consumers and ISVs than existing Windows operating systems. In addition, this work would consume a large portion of the resources of the Windows testing team.

69. Redesigning Windows 95, Windows ME, Windows 2000 and Windows XP to make them completely “modular” operating systems would pose enormous engineering challenges. In effect, the States’ Remedy Proposal would require Microsoft to redesign Windows and create a series of wholly independent modules of software code that could function in isolation from each other. There are simply too many cross-dependencies, and seeking to eliminate those cross-dependencies would be very difficult given the sharing of functionality that pervades the entire operating system. Even if the many cross-dependencies could be eliminated, the resulting array of monolithic blocks of code would require Windows to include redundant code on a large scale and would result in huge increases in size and dramatic decreases in performance of the operating system. In addition, because it is not clear from the States’ Remedy Proposal which parts of the operating system could be defined as “middleware,” there is no guarantee that any redesign would ever meet the requirements.

70. Based on my experience at Microsoft, I do not believe that creating “unbound” versions of Windows as defined by the States’ Remedy Proposal could be achieved even if Microsoft devoted all of its engineering resources to the task. At a minimum, the task would take years. Moreover, requiring Microsoft to devote its engineering resources to redesigning its existing products would divert the resources Microsoft needs to build new versions of Windows operating systems that take advantage of technological advances and meet new consumer demand. Improvements in hardware and software put Microsoft under constant pressure to create new versions of Windows, as does the need to support new computing paradigms like XML Web services. And competitors like Apple, IBM and Sun Microsystems are constantly working to make their operating systems better, forcing Microsoft to do the same if it intends to remain competitive.

71. Even if “unbound” versions of Windows could be created, I believe the dissemination of these decomponentized operating systems into the marketplace would be detrimental to Microsoft, to ISVs and ultimately to consumers.

72. Under the States’ Remedy Proposal, virtually any licensee of 10,000 or more copies of Windows 95, Windows 98, Windows ME, Windows 2000 or Windows XP would have extremely broad rights to modify the operating system however they liked. Such modifications obviously could include the deletion of blocks of software code from the operating systems made possible by Microsoft’s compliance with Section 1. But under Section 2.c, OEMs and Third-Party Licensees could make additional modifications to Windows not contemplated by Microsoft. As I explained previously, these modifications could include changes that would disrupt the functionality of the Windows user interface or even replace it with another interface.

73. Notwithstanding the array of changes to Windows permitted under Sections 1 and 2.c, nothing in the States’ Remedy Proposal would prevent OEMs and Third-Party Licensees from marketing their modified versions using the “Windows” trademark and logos. A consumer would have no idea whether a new personal computer with Windows pre-installed had any of the features Microsoft advertised as present in the operating system. And a consumer would not know whether applications designed for use with Windows would actually run on the copy of Windows running on her new personal computer. Such a result would diminish the value of Windows as a brand. In addition, giving OEMs and Third-Party Licensees (including Microsoft’s direct competitors) the right to make substantial modifications to Windows 95, Windows 98, Windows ME, Windows 2000 or Windows XP would greatly diminish the value of those operating systems to Microsoft, despite the fact that Microsoft has invested billions of dollars to develop and market them. Like other suppliers of products, Microsoft is keenly interested in getting those products into the hands of consumers without having them modified in channels of distribution. Unlike competitors such as Apple, IBM and Sun Microsystems, Microsoft does not manufacture the hardware on which its operating systems run. Thus, Microsoft licenses Windows to OEMs, who in turn distribute Windows to consumers, and Microsoft does not want OEMs to degrade the operating system before consumers get a chance to try it. Of course, the non-settling States would make matters worse by giving Microsoft’s competitors the right to work with OEMs in modifying Windows without Microsoft’s permission, essentially destroying Microsoft’s ability to ensure the integrity of its most valuable products.

74. All of the adverse effects flowing from the fragmentation of Windows operating systems identified in connection with Section 1 would be made worse under Section 2.c because the modifications made to Windows operating systems by OEMs and Third-Party Licensees would be entirely beyond Microsoft’s control. For example, Professor Appel suggested that an OEM or Third-Party Licensee could remove blocks of software code from Windows using a mechanism other than the one Microsoft would be forced to create under Section 1. Permitting third parties to remove arbitrarily software code from Windows with no understanding of the consequences of their actions is certain to lead to serious problems.

75. The States’ Remedy Proposal would also increase Microsoft’s support costs and make providing such support more difficult. This is because Windows would no longer be a well-defined operating system, and Microsoft would have no idea what particular software configuration a user might have on his or her computer. Certainly, OEMs bear some of the cost of supporting users who run into difficulty using their computers, but Microsoft also must support users who believe that they have purchased a Microsoft product and believe that Microsoft should take responsibility for helping them. Moreover, Section 3.a of the States’ Remedy Proposal places an affirmative obligation on Microsoft to provide “support both directly and indirectly” for all versions of Windows that are less than five years old.

76. There is no definition in the non-settling States’ proposed remedy of what it means to “directly and indirectly support” outmoded versions of Windows operating systems. That phrase could be read to mean that Microsoft is obligated to add new features to outmoded operating systems to keep them current with new operating system releases. If that is the nature of the support obligation under Section 3, it would impose huge engineering costs on Microsoft and might well be impossible to comply with if an outmoded operating system were incapable of supporting a new feature.

77. Supporting many different versions of Windows would be effectively impossible because, if those Windows operating systems were no longer well-defined, there would be no way to determine what was causing a particular malfunction. The interaction among Windows and all of the thousands of hardware and software products designed for use with Windows is already very complex, and that complexity would become unmanageable if Windows itself was no longer stable and consistent but instead became a moving target. Product support is a major expense in Microsoft’s operating systems business, and the cost of providing support would rise dramatically if there were hundreds of different configurations of Windows in existence, each with different components missing. Professor Appel’s suggestion that Microsoft could simply refuse to support customers once it determined that an OEM or Third-Party Licensee had made changes to Windows that caused the problem betrays his lack of experience with consumer software products. How would customers know which version of Windows would be supported and which would not? Refusing to help customers with a product as closely associated with Microsoft as Windows is not an option.

78. Requiring Microsoft to create “unbound” versions of Windows 95, Windows ME, Windows 2000 and Windows XP would make those operating systems simultaneously less reliable and more difficult to support. Let me explain how.

79. There is a well-known phenomenon called “DLL Hell” in the software industry that resulted from the replacement of Windows components by various applications. To prevent this from happening, Microsoft added system file protection to prevent critical components from being replaced. This makes Windows XP much more reliable than its predecessors because Microsoft can ensure that replacement components are not causing the operating system to malfunction. Such efforts to improve reliability would be negated under Sections 1 and 2.c, because OEMs and Third-Party Licensees could replace all sorts of Windows components.

80. The fragmentation of Windows that would result from Section 1 of the non-settling States’ Proposed Remedy would undermine Microsoft’s efforts to provide critical updates to customers to address issues of security, reliability and compatibility after the product shipped. First, the existence of multiple versions of Windows will dramatically increase the complexity of identifying the source of any problems that arise and substantially delay delivery of the necessary patches to fix those problems. Second, the removal of blocks of software code by OEMs and Third-Party Licensees will, by itself, impair the security, reliability and compatibility of the operating system.

81. It simply will not be possible for Microsoft to be confident that each configuration of the “unbound” version, when combined with various third-party “middleware” will be as secure, reliable and compatible as a unified Windows operating system, which is subjected to millions of hours of testing before each major release. Microsoft cannot anticipate all of the ways in which OEMs and Third-Party Licensees will alter Windows, and Microsoft certainly cannot test to ensure that any conceivable permutation of its operating system would provide the same quality experience.

82. The fragmentation of Windows will make the process of correcting any vulnerabilities that inevitably arise much more difficult and less effective. Today, if a vulnerability is discovered in Windows, Microsoft responds to it by issuing a patch as quickly as possible. Microsoft develops such patches on an as-needed basis to combat specific threats to the security of its products, as well as to fix critical issues in reliability and compatibility. Patches are made available on the Internet and by other means so users can correct an identified vulnerability quickly. Microsoft, of course, hopes not to need such patches, but all complex software products have some bugs, and some of those bugs affect security.

83. The fragmentation of Windows that would result from Section 1 would greatly complicate Microsoft’s ability to issue security patches in a timely manner. With great effort, a patch for a single Windows operating system might be issued within a day. With multiple configurations of that operating system to take account of, it might take a week or even two weeks (or more) to issue a patch for the same security vulnerability. This delay will harm consumers, who are at risk until the security vulnerability is resolved. To address problems, some patches need to update multiple components at once. If the OEM or Third-Party Licensee has replaced or removed one of these components, applying the patch would not work, and in the worst case may destabilize the operating system.

84. Additionally, certain features of Windows defined as “Microsoft Middleware Products” in the non-settling States’ Proposed Remedy, perform important security functions. The removal of these components will degrade the security of Windows unless they are replaced with third-party products that provide exactly the same functionality and security, which is extremely unlikely. For example, Internet Explorer contains a variety of security mechanisms used to protect Windows from malicious software code downloaded from the Web. And the Internet Explorer team is responsible for responding to vulnerabilities promptly. Given the large number of Windows users connected to the Internet and the number of security vulnerabilities that occur through Internet connections, the replacement of Internet Explorer with less secure Web browsing software could lead to serious problems for consumers.

85. The above effects would increase the total cost of ownership for Windows operating systems, would make Windows operating systems more subject to crashes, and would make the operating system and the personal computer less predictable and less secure. Of course, that is precisely what Microsoft’s customers do not want. And interfering with Microsoft’s efforts to reduce total cost of ownership and increase reliability would effectively turn the clock back seven years to 1995 when Microsoft undertook major efforts in both areas—efforts that are finally bearing fruit in Windows 2000 and Windows XP.

86. Additionally, key features of Windows 98, Windows ME, Windows 2000 and Windows XP—such as the Windows Explorer, the Windows Help system and Windows Update—rely on the Internet Explorer components of the operating system and would not work if those components were removed. Windows Explorer allows users to access files stored on their computer, on external drives, network drives or the Internet. Windows Help assists users when they have questions or problems while using Windows. Windows Update allows users to obtain free updates to their Windows operating system directly from Microsoft. All three of these features rely on the Active X controls and other features supported by Internet Explorer that are not present in other Web browsing software. Neither Netscape Navigator, nor other Web browsing software provides native support for Active X, although they could if they chose to expend the necessary time and effort to do so. As a result, these programs are incapable of providing the functionality required by Windows Explorer, Windows Help and Windows Update.

87. Other features of Windows XP like Remote Assistance use the Windows Messenger components of the operating system and would not work as well if those components were removed. Remote Assistance provides a way for one Windows user to provide assistance to another Windows user by remotely “taking over” the other user’s computer to demonstrate how to perform a task. For example, if a friend of mine and I were both using Windows XP, and he ran into trouble while using his word processing program, I could help him from across the country. By using Remote Assistance, I could temporarily operate his computer using my keyboard and my mouse, and I could see what he was seeing on his screen as well. Using either voice or text messaging integrated into Remote Assistance, I could then explain to him how to correct whatever problem he had encountered.

88. In addition to the effects that the States’ Remedy Proposal would have on Microsoft, it would have serious adverse effects on ISVs by destabilizing Windows as a software development platform. ISVs could no longer have confidence that the functionality relied on by their applications would be present on a given Windows operating system.

89. As noted previously, Sections 1 and 2.c of the States’ Remedy Proposal would enable OEMs and Third-Party Licensees to optionally remove many blocks of software code from Windows. But removing blocks of software code that expose APIs used by software developers will break large numbers of existing applications that rely on those APIs.

90. For example, the Internet Explorer components of Windows operating systems expose their functionality to software developers through hundreds of published APIs, such as those exposed by the file called MSHTML.DLL. Hundreds of applications—including Intuit’s Quicken popular personal finance software and AOL’s online service client access software—rely on the APIs exposed by Internet Explorer. Quicken relies on the Internet Explorer components of Windows to display HTML-based user interfaces and retrieve up-to-the-minute financial information from the Internet. AOL’s client software also relies on Internet Explorer to render HTML and to download information from the Internet using built-in support for standard protocols like FTP and HTTP. Quicken and other applications that rely on Internet Explorer would malfunction if OEMs or Third-Party Licensees removed Internet Explorer completely from Windows or if they sought to replace it with other Web browsing software that did not expose the same functionality through the same APIs.

91. By giving OEMs and Third-Party Licensees the ability to remove from Windows blocks of software code that expose APIs, the States’ Remedy Proposal would create uncertainty for ISVs, who need to know when developing their products precisely what functionality is supplied by the platform they are targeting. ISVs that create products relying on APIs exposed by components of Windows encompassed by the definition of “Microsoft Middleware Product” in the States’ Remedy Proposal could not be confident that those APIs would be present on any given machine. ISVs are unwilling to write software products that call upon particular Windows APIs if they have no assurance that the blocks of software code that support those APIs will be present in Windows. The uncertainty created by the States’ Remedy Proposal would therefore discourage ISVs from creating applications to take advantage of the full functionality that Microsoft has already built into the current versions of Windows. In addition, the States’ Remedy Proposal would dramatically increase the cost of delivering and testing Windows applications, because they would have to test their application with the different “unbound” versions of Windows provided by OEMs and Third-Party Licensees.

92. Although the States’ Remedy Proposal permits OEMs and Third-Party Licensees to remove functionality from Windows, it imposes no obligation on them to replace what they remove with third-party software that purports to provide comparable functionality. Moreover, third-party products are not capable of supplying exactly the same functionality as that supplied by Windows components. For example, Netscape Navigator has never exposed a broad range of Web browsing functionality to other ISVs through published APIs in the same manner as Internet Explorer. As a result, applications like Quicken that display HTML-based user interfaces and retrieve information from the Internet cannot obtain those same services from Netscape Navigator. Thus, while Netscape Navigator supplies functionality that is in some measure competitive with functionality supplied by the Internet Explorer components of Windows, that does not mean Netscape Navigator can be used in place of the those Internet Explorer components in Windows.

93. As noted previously, I have learned during my time working in the software industry that many consumers find personal computers difficult to use. The States’ Remedy Proposal will only exacerbate that problem by making it impossible to know what functionality is provided by any given configuration of Windows.

94. If there were multiple versions of Windows 95, Windows ME, Windows 2000 and Windows XP, consumers would not know what features and functionality were contained in those different versions. The operating system as designed, developed and tested by Microsoft would no longer provide a dependable benchmark, because Windows could be altered in significant ways by OEMs and Third-Party Licensees. Importantly, the States’ Remedy Proposal imposes no obligation on OEMs or Third-Party Licensees to disclose to consumers which “Microsoft Middleware Products” have been removed from a particular configuration of Windows. OEMs and Third-Party Licensees could thus delete critical functionality like My Computer, the Control Panel or Windows Update that enable consumers to use and to maintain their personal computers. This is something that consumers do not even have to consider at present, because Windows is supplied on a consistent basis by a wide array of OEMs.

95. Second, even if consumers were able to determine which portions of Windows were being pre-installed by a particular OEM, they would not know what Windows applications would run on that particular computer. Consumers would be confused and frustrated if products marketed as Windows operating systems were incapable of running Windows applications because blocks of software code relied on by those applications had been removed. Such consumer dissatisfaction would be a direct result of the fragmentation of the Windows platform and would cause sales of new personal computers to decline.

96. Finally, even if an OEM left certain types of functionality in Windows, a user might not ever find out that it was there. Section 10 of the States’ Remedy Proposal would prohibit Microsoft from informing consumers of capabilities present in Windows but hidden from view by an OEM or Third-Party Licensee’s decision to select “non-Microsoft Middleware” as the “Default Middleware.” For example, if an OEM selected Netscape Navigator as “Default Middleware” for its brand of personal computers but left Internet Explorer in the operating system, Microsoft would not be able to prompt the user even once to see if she wanted to use the Web browsing software designed for use with Windows. Consumers that preferred Internet Explorer to Netscape Navigator would not even know that they had the option of using Internet Explorer. And if the user subsequently installed a new version of Internet Explorer on her computer (presumably indicating an interest in using it), Internet Explorer could only give the user one chance to select Internet Explorer as the default. I have difficulty understanding what consumer benefit flows from making it difficult for consumers to find and use features of Windows that Microsoft has invested large sums of money to make as functional and attractive to consumers as we can make them.

97. Currently, there are tens of thousands of Windows applications that call upon a broad range of functionality in Windows operating systems that is exposed to third parties through published APIs. This stock of Windows applications would not exist if Microsoft did not provide ISVs with the information they need to develop Windows applications. Microsoft is well aware that Windows could not succeed in the marketplace if there was not a broad array of interesting and useful applications available for use with Windows. The more compelling Windows applications there are, the more consumers will want to use those applications and thus Windows operating systems. It is therefore in Microsoft’s commercial interests as a platform vendor to enable software developers in general to create products that work well with Windows operating systems. That is true even in the case of software developers like IBM or Oracle who are direct competitors with Microsoft in various lines of business.

98. In developing successive versions of Windows, Microsoft has invested large amounts of time and money to create a set of APIs that expose functionality for software developers to use in creating Windows applications. Microsoft’s efforts to create better ways of providing functionality to ISVs—like support for multimedia technology or better support for new devices like digital cameras—are a form of competition among operating system vendors, all of whom are vying for the attention of software developers. If Microsoft cannot continue to provide software developers with an evolving platform that meets their needs, Windows will soon be eclipsed by other platforms that provide software developers with up-to-date support for the latest hardware and software technologies. In this part of my testimony, I will first explain what Microsoft does to encourage ISVs to write Windows applications. I will then describe the effects that the States’ Remedy Proposal would have on Microsoft’s ability to work with ISVs to create great products that work well with Windows.

99. In discussing the componentized architecture of Windows above, I explained that componentization increases efficiency by enabling different blocks of software code in the operating system to rely on each other to perform a task. In evangelizing new Windows operating system services to software developers, Microsoft makes similar arguments to ISVs to encourage them to rely on functionality exposed by Windows through published APIs. By calling on APIs exposed by Windows, ISVs can avoid having to build from scratch functionality already incorporated in Windows. Instead, they can focus on providing added value to their customers in areas that are important competitive differentiators in their particular type of application. For example, a vendor of word processing software can focus on improving its spell checking functionality rather than focusing on low-level plumbing like how documents are read from and written to the hard disk.

100. Here is another example. Most applications (and operating systems) today include some sort of “Help” system that provides on-screen instructions to consumers about how to use the product. Recognizing that a help system was something that most ISVs would want to include in Windows applications, Microsoft developed a set of Windows APIs that simplify the process of creating such a help system. These APIs enable ISVs to create the help topics, organize them into an index and display them to users in a straightforward way. By making it easier for ISVs to create help systems for their applications, Microsoft enables the ISVs to devote their time and attention to creating unique features for their applications that will make them more interesting and valuable for consumers. Windows users also benefit when ISVs use the Windows APIs to create help systems, because such help systems have a consistent look and feel that users can learn once with one application and then apply to other applications as well. Consumers also benefit because they have less redundant code installed on their personal computers. All of the help systems in different applications are all sharing the same basic functionality supplied by the operating system.

101. Microsoft has a variety of programs designed to provide ISVs with the information they need to develop fully-functional Windows applications. These programs include the Microsoft Developer Network, TechNet and Professional Developer Conferences. Through these and other similar programs, Microsoft provides very large amounts of information to enable ISVs to create Windows applications. For example, the CDs provided on a quarterly basis to MSDN subscribers contain vast amounts of information, including documentation of APIs, sample code to assist ISVs in writing applications and beta test versions of new Microsoft products. For example, the online library of MSDN documentation available on Microsoft’s Web site contains 600,000 files containing 5.66 gigabytes of information. That is roughly equivalent to 1.88 million 8 ½ x 11 pages of text. That is equivalent to a library of 4,700 books of 400 pages each, and this takes no account of the thousands of source code samples that Microsoft also makes available to software developers to assist them in creating first-class Windows applications. This information is designed to enable software developers to call upon the functionality exposed by Windows—as evidenced by the thousands of applications that run on Windows.

102. Information concerning how to call upon the functionality exposed by Windows APIs is publicly available. As a result, although Microsoft makes an effort to keep track of ISVs that are creating products for use with Windows operating systems, doing so is an impossible task. Any ISV with an Internet connection and a Web browser can access the Microsoft Developer Network Web site at http://msdn.microsoft.com. From this web site, any ISV can access literally thousands of pages of documentation concerning Microsoft products and technologies, including extensive technical information about Windows APIs. Because Microsoft makes so much information about Windows APIs available to ISVs, Microsoft has only incomplete information about the number and identity of ISVs and the nature of the Windows applications they create. For example, thousands of software developers work for corporations, government agencies and other institutions and write customized Windows applications for the sole use of such entities. Because these Windows applications are not licensed to anyone else, it is difficult to obtain information about such applications, although they are critical to the operations of many businesses.

103. Microsoft provides information about how to build Windows applications to many companies that develop and market products or services that compete with Microsoft products or services. For example, both Netscape Navigator and Apple’s QuickTime software run very well on Windows ME, Windows 2000 and Windows XP, a sign that Netscape (now owned by AOL) and Apple have access to the APIs and related technical information they need to make their products compatible with Windows.

104. As noted above, Netscape Navigator does not provide native support for Active X controls, but it was Netscape’s choice not to support Active X. The specifications needed to build Active X controls are available to all ISVs through the Microsoft Developer Network, and thousands of ISVs have created Active X controls for use with Windows operating systems. Moreover, the information needed to create software capable of hosting Active X controls is also readily available, as demonstrated by the fact that the Mozilla open source project has created a plug-in that runs Active X controls in Navigator 6.2. There are also implementations of Active X available for use with non-Microsoft operating systems. Netscape could have included support for Active X controls in Navigator had it wanted to do so, and could still do so today.

105. In addition to the API disclosures and other work that Microsoft historically has done to assist ISVs in creating Windows applications, Microsoft has agreed under the Proposed Consent Decree to make additional disclosures about Windows APIs and communication protocols that will benefit ISVs.

106. In particular, Section III.D of the Proposed Consent Decree requires Microsoft to make available to ISVs the APIs that are “used by Microsoft Middleware to interoperate with a Windows Operating System Product.” What this means is that Microsoft has to identify the relationship between what the Proposed Consent Decree defines as Microsoft Middleware and Windows Operating System products, and then publish the APIs used by such Microsoft Middleware to call other components of Windows. Because a large portion of the work required to comply with Section III.D is taking place in my group, I have personal knowledge about the steps Microsoft is taking to comply with the Proposed Consent Decree’s disclosure requirements.

107. The process of identifying which Windows APIs are relied on by “Microsoft Middleware” is difficult and time-consuming. This is because—as I explained earlier—the componentized structure of Windows means that different components of the operating system make numerous calls to other parts of the operating system. In most cases, those components are already calling published Windows APIs, but there are a few instances we have found where that is not the case. We are devoting considerable effort to ensuring that all of the interfaces called by the components of Windows identified as “Microsoft Middleware” in the Proposed Consent Decree are disclosed.

108. Internal interfaces are designed to be called only by other trusted Microsoft components whose behavior is known and predictable. Moreover, because such internal interfaces are designed to be called only by other trusted components of the operating system, they typically have no input checking or error handling capability, and thus are not equipped to deal with being fed incorrect information. Once Microsoft publishes an API for use by ISVs, it no longer controls the circumstances under which the API may be called. The API must be designed to handle erroneous information that might be supplied by external software code and to compensate for such errors without causing the operating system itself to malfunction. It also takes time to document previously internal interfaces to explain to ISVs how the new APIs are to be called. Microsoft tries to make its API documentation as clear and complete as possible. After all, there is no point in exposing functionality through APIs if ISVs cannot figure out how to use those APIs.

109. Microsoft currently has hundreds of people working to comply with Section III.D of the Proposed Consent Decree, and I expect that their initial compliance work will last through the summer of 2002. Given the time that it takes Microsoft to identify, test and document the new APIs that it has committed to disclose under Section III.D, the provision requires that such disclosure occur either with the release of Service Pack 1 for Windows XP or 12 months from the date the Proposed Consent Decree was submitted to the Court. When Microsoft develops new versions of “Microsoft Middleware,” the disclosure of any new APIs relied upon by that new software will need to occur no later than the last major beta test release of the new software. This schedule for the disclosure of new Windows APIs should be sufficiently in advance of the commercial release of “Microsoft Middleware” to enable ISVs to make use of those APIs.

110. Although most of my testimony concerns Sections 1 and 2 of the States’ Remedy Proposal, several other provisions of the States’ Remedy Proposal relate to subjects about which I have knowledge. These subjects are discussed below.

111. The inability of some third-party software products to run on improved versions of Windows operating systems is the inevitable result of architectural changes made to Windows operating systems to improve their performance or make them more stable and reliable. For example, many device drivers designed for use with Windows 9.x operating systems (such as Windows ME) are incompatible with Windows NT operating systems (such as Windows XP).

112. Because the addition of software code to a Windows operating system consumes additional hardware resources—memory, in particular—non-Microsoft “Middleware” running on a given personal computer may also run more slowly than it did with a previous Windows operating system. Under Section 5, that could be viewed as “degrading the performance” of the non-Microsoft “Middleware.” Section 5 provides no objective criteria for determining whether there is “good cause” for such performance degradation.

113. In most cases, Microsoft has no knowledge of how software products created by third-party developers work or which APIs in Windows operating systems those software products are calling. Thus, Microsoft has no basis for determining how changes it makes in future versions of Windows operating systems may affect all of the many thousands of Windows applications. That is why Microsoft must engage in such extensive beta testing of new Windows operating systems before they are commercially released.

114. Section 6 of the States’ Remedy Proposal would interfere with Microsoft’s ability to implement new services in Windows operating systems. Such services often require the non-exclusive use of certain Microsoft technologies. For example, Kodak appears in the Photo Publishing Wizard in Windows XP, which requires that Kodak utilize certain Microsoft technologies on a non-exclusive basis. That does not, however, prevent Kodak from working with Microsoft’s competitors. In fact, I understand that Kodak has an agreement with AOL pursuant to which Kodak is the exclusive provider of photo publishing services in AOL’s “You’ve Got Pictures” feature.

115. Development tools are specific to particular platforms and are often designed to target the unique features of their target platform. As a result, it generally is not possible to use all the capabilities of development tools designed to create Windows applications in the creation of UNIX or Linux applications. That is not a problem because other platforms have their own development tools. For example, IBM’s VisualAge and Sun Microsystems’ Forte are suites of tools for use in developing applications for non-Microsoft operating systems. While Microsoft believes it has done an excellent job developing tools that make it fast and easy to create Windows applications, Microsoft’s investment in these tools has done nothing to prevent the development and marketing of alternative development tools by other companies.

116. To the best of my knowledge, Microsoft does not have agreements with third parties that require them to degrade the performance of their software products or services on non-Microsoft platforms. Such agreements would be contrary to Microsoft’s basic approach to the software business. While we are very competitive and work very hard to create products that will be the best in the marketplace, I know of no situation in which Microsoft has attempted to make a competitor’s product malfunction to gain some sort of unfair competitive advantage.

117. Section 6 of the States’ Remedy Proposal could be read to prohibit agreements designed to encourage software developers to design their products for use with Windows operating systems solely on the basis that such applications will not run on competing platforms that expose entirely different APIs. That makes no sense. As a leading platform vendor, a large part of Microsoft’s marketing efforts involve efforts to persuade software developers that Windows provides the most functional and complete set of services to applications. Such efforts often involve unfavorable comparisons to competing platforms, but that is the nature of marketing.

118. Section 6 would also prevent Microsoft from requiring ISPs and ICPs that are provided with placement in Windows operating systems (e.g., in the Windows referral server associated with the Internet Connection Wizard) from utilizing Microsoft technologies that are necessary for the feature at issue to function properly. For example, it would be pointless to include an ISP in the Windows referral server if it were impossible for consumers to access servers maintained by that ISP in order to subscribe to its Internet access service. It is important to keep in mind, however, that such requirements do not prevent ISPs from supporting non-Microsoft technologies in other aspects of their business. In other words, there is no exclusivity involved.

119. It is time-consuming and difficult to modify Windows 2000 Professional, Windows XP Home Edition and Windows XP Professional to provide the mechanisms for enabling and removing end user access and altering “default configurations” of “Microsoft Middleware Products” and “Non-Microsoft Middleware Products” as required by Section III.H of the Proposed Consent Decree. Microsoft is currently working on creating the new add/remove capability that will give consumers a ready means to choose among Microsoft Middleware Products and non-Microsoft Middleware Products, as those terms are defined in the Proposed Consent Decree, but that work is not completed.

120. Once Microsoft has created the mechanisms for enabling and removing end user access and altering “default configurations” required by Section III.H of the Proposed Consent Decree, any third-party product of the same general type as a “Non-Microsoft Middleware Product” can take advantage of those mechanisms, without regard to the number of copies of that product distributed in the previous year. Thus, James Barksdale’s contention that only Web browsing software that had been distributed to a million consumers would qualify is wrong. The mechanism will be documented and broadly available for software developers to register their “non-Microsoft Middleware Products.”

121. After the software code needed to implement the changes in Windows 2000 Professional, Windows XP Home Edition and Windows XP Professional required by Section III.H of the Proposed Consent Decree has been written, it will be necessary for Microsoft to test those operating systems. Microsoft must ensure that the operating systems continue to function as intended in a wide variety of computing scenarios. This testing is complicated by the thousands of hardware and software products with which Windows operating systems are used by consumers.

122. The concept of “default middleware” in Section 2.c of the States’ Remedy Proposal is predicated on the mistaken notion that Window ME, Windows 2000 and Windows XP are designed so that every block of software code classified as “Middleware” by the non-settling States’ can be replaced by third-party software that will be automatically invoked in particular scenarios. First, as I have mentioned before, the definition of “Middleware” in the States’ Remedy Proposal is very broad and not well defined, so it is unclear what is covered and not covered. Second, the definition of “Middleware” will change over time. And third, even in the case where “Middleware” was a well defined list of components, Windows operating systems are not designed that way, and it would require an enormous engineering effort—by no means assured of success given the varying designs of third-party products—to try to redesign Windows ME, Windows 2000 and Windows XP in that fashion.

123. There is no “default” concept for most blocks of software code in Windows ME, Windows 2000 and Windows XP. To the contrary, each operating system was designed, developed and tested as an integrated whole. In designing Windows operating systems, Microsoft assumes that all blocks of software code that provide functionality to other parts of the operating system (as well as to software products running on top of the operating system) will be present in the product. For example, there is no “default” HTML rendering engine or “default” support for communications protocols like FTP and HTTP in Windows operating systems.

124. As noted in connection with Section 2.c, the concept of “Default Middleware” in Section 10 of the States’ Remedy Proposal is inconsistent with the design of Windows ME, Windows 2000 and Windows XP. Windows operating systems are not designed to permit third-party products to override the functionality provided by each and every block of software code that would be classified as “Microsoft Middleware.” While it might seem a straightforward task to create an operating system like an à la carte restaurant menu, attempting to do that would be extremely difficult. The reason why has everything to do with the componentization and cross-dependencies that I discussed in connection with Section 1 of the States’ Remedy Proposal. Even if two blocks of software code purport to support the same external interfaces, that assertion does not make them functional equivalents of one another. Things are much more complex than that. The internal implementation of those external interfaces matters a lot. For example, although two HTML rendering engines may both claim to support the same external interfaces, they may be dramatically different in their ability to render real HTML documents, many of which are written in idiosyncratic ways that do not comport with W3C standards. Section 10 of the States’ Remedy Proposal does not take account of such issues.

125. Section 10 does not define the extent to which Windows operating systems would have to rely on “Default Middleware” to provide functionality required by those Windows operating systems. There are many features of Windows operating systems supported by their Internet Explorer components—e.g., the HTML-based user interface of Windows 98—that could not be supported by non-Microsoft Web browsing software. Attempting to use Netscape Navigator instead of Internet Explorer in those circumstances would degrade the functionality of Windows.

126. In sum, redesigning Windows 95, Windows ME, Windows 2000 and Windows XP to permit third-party software products to replace blocks of software code in those operating system as the “Default Middleware” would pose a huge engineering challenge. Assuming that it could be accomplished, which I think is very doubtful, such a complete “modularization” of existing Windows operating systems would require all of the Windows development resources for years, halting work on new products and services.

127. It is not possible to conduct joint development of software products if there is no opportunity to protect intellectual property contributed to such joint development efforts from being misappropriated by third-parties. For example, when Microsoft works closely with OEMs to develop technologies like Universal Plug and Play (a Windows technology that automatically recognizes and supports hardware devices plugged into a PC), all of the participants are keen to ensure that they retain the right to protect their intellectual property. The same is true of microprocessor manufacturers like Intel and AMD, as well as suppliers of peripheral hardware like Hewlett-Packard and LexMark.

128. Joint development agreements in the software industry (like such agreements in many other industries) typically provide that the parties to the agreement will not develop, promote or distribute products that compete with the products being jointly developed and/or marketed. Such provisions give the participants some assurance that their contributions to the joint venture will not be used against them. Such provisions also give the participants some comfort that the other participants are committed to the object of the joint venture and will do the work necessary to achieve the goals of the joint venture. These common and beneficial business relationships are permitted by Section III.F of the Proposed Consent Decree, but prohibited by Section 11 of the States’ Remedy Proposal.

[1] Section 2.c makes reference to a “smart folder,” something not defined in the States’ Remedy Proposal. To my knowledge, there is no accepted meaning of that term either within Microsoft or in the software industry as a whole. The two examples provided in Section 2.c (“My Music” and “My Photos”) are particular features of Windows XP that were designed to support different computing scenarios. But I do not understand how to generalize from those two examples into some general concept of “smart folders.”