So lets consider this "mshtml.dll" which is part of IE 4.0, and which they then 'integrated' into the operating system. I claim that if Microsoft wanted to give that functionality to Mr. Devlin's help system, they could include mshtml.dll with their OS, whether or not they include "IE 4.0." In some sense, mshtml.dll by itself is a new 'product.' But certainly the existance of mshtml.dll on the hard drive does not have to be tied to the existance of the IE 4.0 icon on the desktop. Mr. Devlin's help system does not move the users mouse over the IE 4.0 icon and click on it-- it uses a different interface to the underlying code.
Again, with ample apologies to the more technically savvy, let me see if I can address this and, in the process, clarify my ideas.
First of all, Devlin was not talking about the user interface. I agree with you that, from the end user's point of view, the user interface(s) for Windows 98, the "integrated product" provide functionality which is equivalent to combining IE 4 with Windows 95. That is the devastating point of Boies' eliciting of the infamous 19 admissions from Allchin. Because the whole of Windows 98 is not greater than the sum of the parts of IE 4 + Windows 95, Windows 98 does not, in that respect at least, satisfy the Court of Appeals' test.
But Devlin is talking about the APIs that are "opened up" to developers on IE and Windows 95 vs. the APIs opened up on Windows 98. I assume the two sets of APIs are identical, at least when IE 4 retail version is combined with Win 95. However, there is one advantage that the combined version of the two products does not offer that the whole of Windows 98 does. There is a guarantee that all users of Windows 98 will will have all of the APIs present in both IE and Windows 95, while there is no such guarantee for users of the Win 95/IE combo, since the whole point of keeping the products separate is to give consumers the choice not to use IE 4 and, by necessity, its APIs. From the developer's point of view, the whole is greater than the sum of the parts, and the complete set of APIs is a unified whole, and hence integrated, even if, physically or technically, they are not intertwined but are kept entirely separate from one another. (As an analogy on this point, think of a kitchen plate broken into two parts.)
As Devlin explained, having access to those IE APIs saves him money, savings he can pass on to purchasers of his products. Those are a plausible technical benefit of the Win 98 integrated product which is not available if users are allowed to combine IE4 and Win 95 on their own. Giving users the choice not to include the IE APIs in their OS/browser combo defeats these savings for Devlin and his customers, for the reasons I outlined.
Now, you will say, "Why not just include the IE APIs or DLLs in the OS, so all Windows users will have them even if they cannot use IE?
My response is this: If the APIs in IE are not needed to operate Windows, then they bear no logical relation to Windows and should not be a part of the Windows OS. They are a part of IE and should be included with the IE software. Correct me if I am wrong, but I thought one of the points of Farber's testimony was that a given OS or application should contain only those DLLs and APIs needed to actually run that piece of software.
It does not matter where you physically put the DLLs; if Windows does not use or need them, they are not part of Windows.
Once you establish this proposition, it follows that, for developers to be able to rely on the fact that all users will have the full set of APIs on their machines, you must tie IE to Windows at the design level. Again, it does not matter whether, physically or technically the products are intertwined or the code comingled; the point is that the two of them together are a whole that must be unified if developers are to be able to take advantage of it.
The reverse is also true: if Windows does use a given API, it has a logical relation to, and should be part of, Windows even if other programs, including IE, also use the same API. Thus, if Microsoft puts a DLL or API needed by Windows to run some function of Windows into IE instead, that would be a violation of the Appeals opinion, since to do so would be to deliberately rig Windows to crash if IE is deleted.
One thought that occurred to me was: what about APIs and DLLs that are needed by, and therefore bear a logical relation to, niether Windows nor IE? I suspect the majority of the 10,000 or so Windows APIs that Allchin mentioned in his cross with Boies probably fall into this category.
If my recollection and understanding of Farber are correct, I believe he would say these APIs belong in neither Windows nor IE. They should be a part of the one or more applications that actually use them and not a part of anything else. I guess Microsoft's response would be that it can put them wherever it wants; under my theory, I think this would be correct as long as IE contains at least one API or DLL open to developers that is needed to operate IE but not needed to operate Windows. Obviously, if the two products are separated, the APIs irrelevant to both should go into Windows.
I have probably screwed this up somehow, especially in my usage of jargonistic technical terms like "API" and "DLL," and I apologise to the technically knowledgeable, to whom errors I am not even aware of probably stick out like sore thumbs.
Anyway, if this makes sense to you, tell me what you think about it as a theory of "integration." |
