On page 12, the authors state that "Microsoft has a high level of user-level lock-in; there are strong disincentives to switching operating systems." Yet, where is it NOT the case that customer's are "locked-in" to a particular platform? Can a user's collection of Linux applications be migrated to the Mac if they choose? Can Mac applications be run on Solaris, or for that matter, Windows? Can applications written against an Oracle database be ported automatically to SQL Server?
Likewise, how does the presence of an integrated IE constitute user-level lock-in? Is it a grievous sin for Microsoft to offer developers the OPTION of reusing an integrated HTML renderer? Microsoft's "crime" in this case was that they were sufficiently forward-thinking as to offer their HTML rendering engine as a set of reusable components years before its competitors got around to it. It should surprise no one that developers found IE appealing. Similarly, it is only a problem for Microsoft to make IE available to end users as a default option if you buy into the notion that government must bully consumers into usage modes it considers more favourable.
Along those lines, consider the basis upon which they conclude Microsoft is guilty of "tight integration" of components: "The "tight integration" is this: inter-module interfaces so complex, undocumented , and inaccessible as to (1) permit Microsoft to change them at will, and thus to (2) preclude others from using them such as to compete" (page 13).
I'm only left to conclude that the authors have NEVER programmed for a Microsoft operating system. Microsoft is and always has been very developer-friendly, and goes to great lengths to provide its developers with loads of easy to use documentation. This is a fact noted by developers who have made the transition to Windows from other platforms.
Furthermore, where are the examples of Microsoft changing APIs at will in order to befuddle the competition? That would be surprising, given that Microsoft often tends to create its applications as a set of reusable components so that its own developers might reuse them. In other words, changing an API would harm Microsoft's own developers as much as it harms external developers.
Besides these facts, few companies go to the same lengths as Microsoft to maintain backwards compatibility with old interfaces. Windows 9x code was only recently replaced with Windows XP, and even then, most applications written for Windows 9x operating systems run on Windows XP. Compare this to Apple, who has drastically changed its APIs several times over the past decade. This fact should be an "in" to insightful competitors, given that there is nothing stopping them from cloning the IE automation interfaces (as an example), thus making their browser interchangeable with use of IE.
Lastly, on what basis do they conclude that Microsoft makes its interfaces "complex...and inaccessible?" Microsoft for years has used COM as its standard reusability API, a binary interface standard on Windows which enables multiple languages to reuse the same block of code (now superseded by .NET). COM was well understood, at least if you were a Windows developer, and hardly the "inaccessible API" that the CyberInsecurity authors imply is the norm on Windows.
This is the second of three parts. Read Part I CCIA Microsoft report -- the core issues. Part III will appear on Friday.
