decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Comes 2399 (Novell, bugs in Windows 95) | 117 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Comes 2399 (Novell, bugs in Windows 95)
Authored by: Anonymous on Thursday, May 09 2013 @ 11:22 AM EDT

Comes v. Microsoft

August 31, 1995

Mr. Bob Kruger<br />
Strategic Relations<br />
Microsoft Corporation<br />
One Microsoft Way<br />
Redmond, WA 98052-6399

Dear Bob:

In response to Novell's correspondence on August 21st, attached you will find a
list of outstanding
bugs in Windows95 that impact many of our products. The list, while not
exhaustive, contains a
description of each bug and in some cases the consequence of the bug event.
Further details
regarding each bug will have to be addressed by our respective QA engineering
staffs . I hope that we
can continue to work together to resolve these and any future problems that
might occur. We hope
that you will be able to facilitate the resolution of these bugs and the
solutions find their way into the
very next version of Windows95.<br />
If you have any questions please feel free to contact me.


Dave Miller

[ Reply to This | Parent | # ]

Comes 2399A (Bug Description in Windows95)
Authored by: Anonymous on Thursday, May 09 2013 @ 11:35 AM EDT

Plaintiff's Exhibit<br />
2399_A<br />
Comes v. Microsoft

August 31, 1995<br />
Bug Description in Windows95<br />

<table border="1">
<tr><th align="left">Description</th></tr>
<tr><td>WIN95: Hanging when putting 66-char paths in loc of files
<tr><td>WIN95: Prompted for network ID whenever shared code loads.
When the code detects that the OS is
Win95, it should "trust" the Windows APIs to provide the correct user
<tr><td>WIN95: Macro Recording "wart" covers buttons in
dialog title bar</td></tr>
<tr><td>WIN95: App's window title has display problems (changing
from left to center justification, not repainting
some text); long prompts can overwrite Minimize button (also Maximize/Restore,
Help, and Close buttons);
PF must use SystemParametersInfo() to get caption size, font, etc. (MS needs to
tell us which font we
should use to paint the caption, also metrics like size and position of buttons,
position and sizingo info, etc.
We need to get useful 16-bit app info from SystemParametersInfo() with
<tr><td>WIN95: Tutorial's "Show Me" buttons cause endless
loops (coaches too)</td></tr>
<tr><td>WIN95: DBM Popup buttons shouldn't have top and bottom
borders redrawn when running on Win95</td></tr>
<tr><td>WIN95: Once DAD hides (using Auto-Hide) it never reappears
(unless user closes DAD using Ctrl+Alt+Del
or restarts Win95)</td></tr>
<tr><td>WIN95: fix event loop problem with Win95 and
<tr><td>WIN95: fix overwriting icons in title bar under
<tr><td>WIN95: Network button is gray (File | Print | Select |
<tr><td>Calling Groupwise features via the File menu in our
applications can put GW (shared code) in an unstable
state which will cause shared code applications to stop functioning, and may
require the restart of win 95.</td></tr>
<tr><td>When running an application from the network, selecting the
"logon as new user" from the shut down dialog
will produce errors that shouldn't occur and take much longer than
<tr><td>Clicking on container frame will delete contents of WPDraw
and shrink it. DUP: Startup WPWin.
Graphics | Draw.Click on Box Tool on ToolPalette. Draw some boxes. Now single
click on the
container frame. The frame will shrink. When you resize it the contents of the
object will be gone.</td></tr>
<tr><td>Hard hang if attempt to access a path > 114 chars. Should
return an error message as in Win31.
Steps to Duplicate:
<ol><li>Create paths as described in report 14,052
<li>Run WPWin</li>
<li>From a blank WP Document screen play wsc14094.wcm.<br />
This macro enters path > 114 in the File Name edit field. You are hung at
this point with an hour glass
displayed. You should receive an error message.<br />
Comments: Path > 114 also causes hard hang if a QuickList item already
existed for the user and they
double click it. If you attempt to add this path to your QuickList you also
<tr><td>When this task (ICMRGLST.WCM) is finished and WordPerfect
and InfoCentral have been shut down,
the pointer of the mouse disappears over all PerfectOffice programs. The mouse
pointer is visible when
it is over WIN95 dialogs, but if you move it over DAD it disappears. The
balloons on DAD still show up. If
at this point I bring up WP, as soon as I move the pointer over WP it disappears
just like with DAD. I
have to shut down WIN95 to make it work again. To dupe: Launch the task, click
Next all the way
through until it is finished (using the default options). On some machines, this
couldn't be duped until you
open PRWin, then try to close it.</td></tr>
<tr><td>Unable to drag and drop files from QuickFiles to a WIN95
group box. To Dupe: Start DAD, click on the
QuickFiles icon, highlight a .EXE file and try dragging it to a group box or the
<tr><td>Pasting a QPW notebook (or graph) into PRWin as a bitmap
causes the object to be completely filled
with black. To dupe, launch QPW and PRWin, in QPW
retrieve ROE6050.WB2, select cells A1..C8, Edit | Copy, in PRWin choose Edit |
Paste Special | Bitmap |
OK, notice that the pasted bitmap is completely filled with
<tr><td>Minimizing a Tool then Document places the Program in an
instable state: STD - click on Tools, Speller,
No, Minimize Speller, Minimize Document1, Try to Close the Minimized document or
WPWIN, you
should not be able to close the program for some time.</td></tr>
<tr><td>The CLIPBRD.WCM macro cannot find
<tr><td>No Speller Icon on Taskbar or Desktop: STD - Run Macro,
Select No, then Minimize Speller. At this
point, I cannot maximize my speller again.</td></tr>
<tr><td>No Thesaurus Icon on Taskbar or Desktop: STD - Run Macro,
Minimize Thesaurus. At this point, I
cannot maximize my speller again.</td></tr>
<tr><td>Text colors print black instead of shades of gray on the HP
LaserJet 4 printer. STD: Select the HP
LaserJet 4 Windows printer driver. Play BUG74393.WCM (it will create and print a
simple document)
and notice that the gray and cyan text printed black. This is not a problem when
running under Windows
<tr><td>Bullet Characters look bad in the Bullet &amp; Numbers
dialog. STD: Insert | Bullets &amp; Numbers. The script
provided demonstrates this.</td></tr>
<tr><td>The Messaging API service providers that used to work in the
M7 time frame (January beta) no longer
seem to work. Can we get documentation on the changes that have been made to the
SPIs (especially
transport and address book) since M7.</td></tr>
<tr><td>We do not have the information we need to make our Point and
Print implementations compatible with
Microsoft's. We need Point and Print specifications to ensure
<tr><td>The dialog displayed by SHBrowseForFolder will not show any
printer objects which are not in UNC
name format, or are not subordinate to a Computer object. The result is that our
customers can not
select NDS queues when attempting to set up printers using the
"Printers" applet in the "My Computer"
folder. Can we get SHBrowseForFolder to use the same methods, so that our queues
will appear?</td></tr>
<tr><td>Problem with the header files and libraries for implementing
a Windows 95 Password Provider. Microsoft
told us that the APIs were removed and new ones placed in and promised
documentation on the new
ones. We have yet to receive that documentation.</td></tr>
<tr><td>The PPPMAC.VxD that is needed to support RAS client is not
shipped with Windows 95.</td></tr>

[ Reply to This | Parent | # ]

Comes 1810 (capone and Chicago)
Authored by: Anonymous on Thursday, May 09 2013 @ 04:29 PM EDT

Comes v. Microsoft

From doughe Sat Sep 25 21:53:56 1993<br />
X-MSMail-Message-ID: 30CEBA9A<br />
X-MSMail-Conversation-ID: 7B2B1EBD<br />
X-MSMail-Parent-message-ID: 7B2B1EBD<br />
X-MSMail-WiseRemark: Microsoft Mail -- 3.0.729<br />
From: Doug Henrich &lt;;<br />
To: jonl<br />
Date: Sat, 25 Sep 93 21:51:08 PDT<br />
Subject: FW: capone and Chicago

----------<br />
From: Doug Henrich<br />
To: Brad Silverberg; Dennis Adler; David Cole<br />
Cc: Doug Henrich<br />
Subject: FW: capone and Chicago<br />
Date: Saturday, September 25, 1993 3:49PM

I am not sure what your thinhing is about publishing the the
interfaces/APIs that Capone uses, but I know Lotus will make a big deal
of this. (Manzi has already mentioned it to Billg). And I am afraid
that the press will have another field day with this.<br />
----------<br />
From: H.K. Ken Ong<br />
To: Tom Evslin<br />
Cc: Doug Henrich; John Ludwig; John Purrier; Jonathan Lazarus; Paul
Maritz; Steven Sinofsky<br />
Subject: RE: capone and Chicago<br />
Date: Friday, September 24, 1993 12:44PM

Message-Id: &lt;9309241946.AA19857@itgmsm&gt;
X-Mailer: Microsoft Mail V3.0

We're on the same wavelength: "by the book" meant we continue to make
we let Chicago know we're using which calls. It's up to Chico to decide
whether they publish the calls.

----------<br />
<div style="border-left: solid 1px black; padding-left: 0.5em">
From: tomev<br />
To: kenong<br />
Cc: doughe; johnlu; johnpur; jonl; paulma; stevesi<br />
Subject: RE: capone and Chicago<br />
Date: Friday, September 24, 1993 12:14PM

What do you mean "play by the book"? The APIs may, in your judgement,
fit for public consumption. However, there is no current plan to make
public. It is, and should be, the decision of the Chicago team on whether
they make these public. WGD's obligation is to not use any interfaces
Chicago isn't aware that we're using and I believe we're doing that.<br
----------<br />
From: kenong<br />
To: doughe; johnlu; jonl; paulma; tomev<br />
Cc: johnpur; stevesi<br />
Subject: RE: capone and Chicago<br />
Date: Friday, September 24, 1993 11:48AM

Today, we're not using any Chicago API's which aren't fit for public
consumption. It's just a question of whether Chicago chooses to publish
those calls. We agree that we shouldn't break this unless we have to.

How about this: The directive to the Capone &amp; Chicago teams should be
continue to play by the book. If this becomes too onerous, we (Capone
will let TomEv know before invalidating this assumption. Until then, you
can assume we're kosher (but you shouldn't assume that we'll be able to
kosher forever).

----------<br />
<div style="border-left: solid 1px black; padding-left: 0.5em">
From: Doug Henrich<br />
To: johnlu; jonl; paulma; tomev<br />
Cc: kenong; stevesi<br />
Subject: RE: capone and Chicago<br />
Date: Friday, September 24, 1993 l0:45AM

I think this is problematic from a PR and ISV issue. We have always
told the development and press community that capone would be included
with future version of windows, but we would use mapi and be
replaceable. We have tried to be hard core about this explaining that
it does not make sense to build competing mail products, but of course
every existing mail vendor will, and will try to differentiate
themselves from our offering.

Several big and small email vendors will be upset, and this will play
out as an unfair advangate issue with the press. I think we want to
avoid this.<br />
----------<br />
From: Tom Evslin<br />
To: John Ludwig; Doug Henrich; Jonathan Lazarus; Paul Maritz<br />
Cc: H.K. Ken Ong; Steven Sinofsky<br />
Subject: capone and Chicago<br />
Date: Thursday, September 23, 1993 6:46PM

Message:Id: &lt;;<br />
X-Mailer: Microsoft Mail V3.0

Discussed this with BillG today. Since capone is quite literally part
Chicago, like any other system component, it can use internal interfaces
communicate with other system components. In accord with good
practice, explicit dependencies on interfaces which may change in the
should be kept to a minimum.

[ Reply to This | Parent | # ]

Comes 1819 (shells and oem's)
Authored by: Anonymous on Thursday, May 09 2013 @ 04:41 PM EDT

Comes v. Microsoft

From: Steve Madigan<br />
To: bradsi<br />
Subject: RE: shells and oem's<br />
Date: Friday, October 01, 1993 2:22PM

please don't react to bill's reaction to the novice mode...give him
some time, nothing new has ever "done much for him" - the
important thing is what it does for the oem audience and their

we may want to start showing some novice mode stuff on a very
restricted nda basis to get reactions and hold the fort<br />
----------<br />
From: Brad Silverberg<br />
To: David Cole; Dennis Adler; Joe Belfiore; Steve Madigan<br />
Subject: FW: shells and oem's<br />
Date: Friday, October 01, 1993 7:50AM

fyi<br />
----------<br />
From: Bill Gates<br />
To: bradsi<br />
Subject: RE: shells and oem's<br />
Date: Thursday, September 30, 1993 7:58PM

I totally agree with you on this.

However the way they did Novice mode didnt do much for me -
particularly dropping the window management ICONs.

We need something in this area.

We may have to start restricting people from screwing around with
shells - certainly this Xsoft thing is a bad situation. Novice shells
are messy - serious shells are a disaster.<br />
----------<br />
From: Brad Silverberg<br />
To: Bill Gates<br />
Subject: shells and oem's<br />
Date: Thursday, September 30, 1993 8:16AM

One reason for our desire to produce a nice "novice" shell is the
interest by a number of oem's to deliver replacement shells for Windows.
They are interested in this for two basic reasons: a desire to improve
the usability of Windows plus opportunity for differentiation.

We learned about 6 weeks ago that Compaq has two shell efforts. One is to
deliver a low-end, Navigator-like shell, for their consumer machines. This
should be shipping soon. In addition, they have been working with XSoft for
almost a year to develop a "mainstream" Windows shell which they plan
ship on all their machines. They just told us about this about 6 weeks ago.
They are planning to ship this for both Win 3.1 and then for Chicago. I
raised strong objections, especially for Chicago, and this is a current
topic of controversy between us now. Note that XSoft is part of this CIL
group -- a consortium of our competitors (IBM, Novell, etc) trying to define
obiect standards and UI's for gui OS's, including Windows. (I'll forward
the press release.) Compaq is here today and tomorrow, and this is one of
the topics of conversation.

In addition to Compaq, AST is continuing to invest in Tandy's WinMate, and
wants to do a Chicago version. P-B wants to do a Chicago version of the
Navigator. Dell supposedly just hired 6 software developers to work on a
Chicago shell for them...

We really want oem's to stick with the Chicago UI. It's one thing to
enhance it; it's another to replace it. The UI is our face to the world,
our identity. I want the range of needs from oem's, including novice needs,
to be satisfied with our shell so they don't feel they have to go elsewhere.

What these companies don't realize yet, perhaps, is that because the Chicago
UI is nicely integrated, with no more separate, standalone "managers"
(fileman, progman, printman, control panel, etc), the shell is no longer
just a shallow surface and thus to do a replacement shell is a highly
non-trivial task. The winnet drivers, in addition, no longer contain their
own ui (ie, they are not standalone either anymore), but rather make calls
on the shell to get seamless integration.

[ Reply to This | Parent | # ]

Comes 1830 (Xsoft)
Authored by: Anonymous on Thursday, May 09 2013 @ 05:15 PM EDT

Comes v. Microsoft

<b>From:</b> Brad Silverberg<br />
<b>To:</b> davidcol; dennisad; joeb; stevem<br />
<b>Subject:</b> FW: Xsoft<br />
<b>Date:</b> Thursday, October 07, 1993 1:06PM

&lt;smile&gt;<br />
----------<br />
From: Glenn Thompson (SYS)<br />
To: bradsi<br />
Subject: Xsoft<br />
Date: Thursday, October 07, 1993 11:37AM

Lori says you put Xsoft on the no get list. I need to know why because
they are asking. Are they a sub of someone or ... ??? Thanks,<br />
------- GlennT

----------<br />
From: Lori Young<br />
To: Anne-Marie Arnold; Glenn Thompson (SYS)<br />
Subject: RE: Help! Who can tell me where our Chicago beta kits are?<br
Date: Wednesday, October 06, 1993 11:42AM

Actually, Bradsi asked me last week to put XSoft on the No Pre-Release
List. Not sure why, but he did....<br />
----------<br />
From: Glenn Thompson (SYS)<br />
To: Anne-Marie Arnold; Lori Young<br />
Subject: FW: Help! Who can tell me where our Chicago beta kits are?<br
Date: Wednesday, October 06, 1993 11:19AM

I looked in the shiplist but he isn't there. Any ideas ??? Sounds
like he got a beta number though he could be bs'ing us.<br />
------- GlennT

----------<br />
From: &lt;netmail!Fred;<br />
To: Glenn Thompson (SYS)<br />
Subject: Help! Who can tell me where our Chicago beta kits are?<br />
Date: Monday, October 04, 1993 1:35PM

Dear Glenn:

Per our e-mail correspondence in late July and early August, I and my
Robert Kincaid sent in our names and address to the Chicago beta program. We
received the application diskettes, and retumed them September 15.

We have not yet received the beta kits, and I am concerned that perhaps our
applications were mishandled. Can you or someone else please follow up with
the appropriate parties and let us know when we will be receiving our beta
copies? We are looking forward to the opportunity to test Chicago.

The "company id number" given to me by the beta program is 129891.
Kincaid's is 129892.

Thanks for your help.


<b>From:</b> Brad Silverberg<br />
<b>To:</b> Glenn Thompson (SYS)<br />
<b>Subject:</b> RE: Xsoft<br />
<b>Date:</b> Thursday, October 07, 1993 1:06PM

yes, they are on the no prerelease list. i can discuss verbally.<br />

<em>[Ed: Repeat of Glenn Thompson's, Lori Young's and Fred Ingham's
messages omitted.]</em>

[ Reply to This | Parent | # ]

Transcripts in previous articles
Authored by: Anonymous on Thursday, May 09 2013 @ 05:25 PM EDT
Linking back to previous ones:

[ Reply to This | Parent | # ]

Comes 2428 (Follow-up questions for Novell NT Requester)
Authored by: Anonymous on Thursday, May 09 2013 @ 05:37 PM EDT

Comes v. Microsoft

<b>To:</b> Dave Miller<br />
<b>From:</b> Ben Hendrick<br />
<b>CC:</b><br />
<b>Subject:</b> Follow-up questions for Novell NT Requester. -Reply
-Forwarded<br />
<b>Date:</b> Thursday, November 9, 1995 11:43 AM


Here are the details you requested from me in our discussion yesterday. The
line is Microsoft is not providing us with the information we need for features
to include
with our clients on Win95 and Win NT.<br />
Essentially, we have two options. Reverse engineer Microsofts shipping stuff
till we get
the information we need for our clients (Which takes months that slips the
schedule and
requireslots of people we dont have) or concede ODI, IPX, TCPIP, and other LAN
Drivers and Protocols that we were leaders at and just build NCP requesters that
into NDIS and NWLINK.

However, we will still be dependent on Microsoft getting us the info and
interfaces for
these NCP requesters. This is the current dilemma facing the Client group.
Either way,
Microsoft needs to share this information with us in a timely manner in order
for us to
deliver clients that will expose our current and future NetWare offerings.


[ Reply to This | Parent | # ]

Comes 2991B (Office rendering)
Authored by: Anonymous on Thursday, May 09 2013 @ 06:19 PM EDT

Plaintiffs' Exhibit 2991_B<br />
Comes v. Microsoft

<b>From:</b> Eric Rudder<br />
<b>Sent:</b> Monday, December 07, 1998 8:04 AM<br />
<b>To:</b> Bill Gates<br />
<b>Subject:</b> RE: Office rendering

my point abt DAV has always been that we messed up in not making DAV do all the
things that we want in PROTOCOL+.
you can always defend it along lines of reasoning, but we didn't do a general
job in ways that we should have.
the standards thing is another issue, but for me, it's not really the primary

-----Original Message-----<br />
<b>From:</b> Bill Gates<br />
<b>Sent:</b> Monday, December 07, 1998 8:02 AM<br />
<b>To:</b> Eric Rudder<br />
<b>Subject:</b> FW: Office rendering

-----Original Message-----<br />
<b>From:</b> Bob Muglia (Exchange)<br />
<b>Sent:</b> Monday, December 07, 1998 7:20 AM <br />
<b>To:</b> Bill Gates<br />
<b>Subject:</b> RE: Office rendering

I think the concerns about DAV are a red herring.
First, in order to support the Internet, we needed to expose the full richness
of Exchange on a stateless protocol.
MAPI is based on synchronous RPC and this protocol is inappropriate on
unreliable networks. 99% of Outlook hangs
are caused because Outlook is blocked waiting for an RPC response which will
never come because a packet was
dropped. While we could change timeouts, etc., a stateful, synchronous protocol
will never be appropriate for the
Once you accept the need for a stateless protocol, HTTP is the obvious choice.
It allows unification of messaging and
database applications onto a common protocol. It goes through firewalls and of
course is ubiquitously supported in the
network infrastructure.
The DAV verbs provide a small set of file system capacities on top of HTTP -
directory enumeration, basic query, and
snapshot/putback of files. DAV is very minimal and with the exception of basic
versioning, represents a subset of the
technology we supported in SMB in 1988. By itself, it certainly can't come
close to replacing the MAPI protocol.
Instead, we leverage the small subset of DAV capabilities and add many
proprietary extensions - advanced query,
cursoring, replication, link fixup, advanced versioning, checkin/out.
The advantage of using the DAV subset is that it allows our client apps and
tools to interoperably support other
platforms while still providing considerable advantage to the user when used
with our servers. For example, Front
Page will move to supporting DAV+MS Extensions as their primary protocol in
their next release. This means that
Front Page will be able to support Unix servers in a basic way (less functional
then today's FP extensions) without any
code running on the server. On the other hand, they will provide huge
advantages when running against
Platinum/PKM (link fixup, versioning, property promotion and indexing, workflow
process, document vocabulary,
checkin/out, etc.) DAV will make it easy for Unix-based ISPs to offer minimal
support for FrontPage and at the same
time, the MS proprietary extensions will provide huge benefit to moving to an NT
On a more fundamental level, I believe that our core assets and intellectual
property reside primarily in the
IMPLEMENTATIONS of our apps/services, not in proprietary APIs and protocols.
It is certainly true that we need APIs/protocols which are technically
appropriate to provide the full richness of
capability. We also need complete freedom to innovate.
But I believe that the long-term strength of the assets we develop are based on
the depth of the underlying semantics
of our implementation. When an ISV builds a an app on one of our services,
their dependency on MS is completely
proportional to their reliance on the semantics of our service. The API (or
protocol) is just a reflection of these
underlying semantics. Yes the API needs to be good, yes it needs to be unique.
But whether it is rooted in a standard
or not is secondary.
A good example of this is HTML. The investment we've put into HTML has created
very unique semantics. We are
now to the point where an ISV who uses the XML/XSL capabilities in IE 5 have a
deep reliance on MS. Clearly, at
least one ISV (Office) is deeply taking advantage of these capabilities. Now
obviously, many ISVs still use HTML 3.2
because of its ubiquity, but this is not because HTML is rooted in a standard -
they just want the reach.
There are lots of good examples where a proprietary API didn't provide any
long-term advantage. Netscape's object
model and scripting language were proprietary. However, because their
investment in Nav 2's object model and
livescript was a handful a person-years, it was relatively straight-fonward for
us to independently engineer this and
create a compatible implementation in IE 3. In this case, there was
insufficient time for Netscape to develop the
complex semantics needed in their implementation to create a long-term asset.
Likewise, Novell's IPX and NCP are fully proprietary. NCP isn't even published.
Yet here again, we were able to
create an independent implementation. Why? Using a sniffer is not difficult so
creating the documentation was a
doable job. And the underlying semantics of the Netware file server are
generally similar to what we implemented in
NT. So hooking up their proprietary protocols to our implementation was easily
within our reach. Novell's mistake is
that they didn't build more sophisticated functions into their product and
create an ISV reliance on this. If, for example,
they had built a sophisticated file system with property indexing into their
server and gotten apps to use this, we still
wouldn't be able to have an answer to this.
In contrast, there are some proprietary implementations which haven't been
cloned. Sun failed in their Windows clone.
Why? Not because the Windows API is proprietary. Creating their own windows.h
file from our documentation is the
least of their problems. IP may have been an issue but they failed on their
own. I submit that Sun failed because the
semantics of the Windows implementation (particularly user) are unbelievable
complex. Creating an independent
implementation of the APIs and messages is within reach; what is hard is
matching the underlying semantics in ways
which ISVs rely on. Also, the breadth of Windows services (including COM and
OLE), make this a huge, huge task.
The key to the Windows asset is the thousands of person years we've invested in
the implementation.
Likewise, I submit that it would be very difficult to build an independent Notes
implementation. Again, it is not because
their protocol is proprietary. The same sniffer which worked for Novell will
work for Notes as well. The key asset
which Lotus has created is a deep set of semantics which applications rely upon.
That implementation has been built
over a 10 year period and undoubtedly took well over a thousand person years to
establish. Anybody who expects to
create a an independent version of Notes better be willing to spend hundreds of
person years to match the semantics
that Notes apps rely on. I believe strongly in interoperability with Notes and
have obvioiusly made significant
investments in this, but that is diffferent from creating a fully independent
So the bottom line is that I don't believe DAV is big exposure for us. First,
it is a relatively minimal set of capabilities. It
hardly represents the full set of Platinum semantics. Second, I believe that
our real asset with Exchange/Platinum
exists in the implementation. The store, all the clever work that has been done
to get great performance, the events,
all the specific semantics of the implementation. Of course, the importance of
this is based on getting apps to rely on
Fortunately, I think that the success of Exchange and the excitement we can
generate from Platinum will generate lots
of apps.

-----Original Message-----<br />
<b>From:</b> Bill Gates<br />
<b>Sent:</b> Saturday, December 05, 1998 5:09 PM<br />
<b>To:</b> Steven Sinofsky; Bob Muglia (Exchange); Jon DeVaan<br
<b>Cc:</b> Paul Maritz; Eric Rudder<br />
<b>Subject:</b> RE: Office rendering

I think the current support we have is just right for both technical and
business reasons.
Its right for technical reasons because the team worked hard to support old
browsers as much as they could.
Its right for business reasons because it supports competitive browsers but with
a clear benefit for people who use
our browser (particularly IE 5).
What I trying to say is that looking forward we should not do heroic things like
add new capabilities to the
standards to help Office.
We should look at even patenting the things that we do add to help Office.
I need to lean more about this whole DAV thing.

-----Original Message-----<br />
<b>From:</b> Steven Sinofsky<br />
<b>Sent:</b> Saturday, December 05, 1998 4:39 PM<br />
<b>To:</b> Bill Gates; Bob Muglia (Exchange); Jon DeVaan<br
<b>Cc:</b> Paul Maritz<br />
<b>Subject:</b> RE: Office rendering

Office does not love DAV. In fact we, I, didn't want to support it at all, but
the Exchange team delivered our
abstraction layer (the derivative of OLEDB that works against FrontPage). It
was not something we needed,
and several times pushed back since it made the FrontPage case we cared most
about more complex and
inefficient. I personally think this is an area that has been oversold as a
benefit and in terms of interoperability.
In essence, this is a proprietary protocol for us anyway since we are
re-building MAPI on top of it.
Nevertheless, Office 2000 will be able to save/load against FTP, FrontPage, SMB,
and the Exchange/IIS DAV
server. But DAV servers (to the extent they really exist) do not support any of
the richness we have with
FrontPage 2000's server extensions such as link fix up, checkin/checkout, page
themes, site statistics, etc.
For me, DAV is a case where Microsoft is out there leading with the newly
proposed (by Microsoft) but yet to
be implemented "open" standard. In contrast, HTML is a case where we
are dealing with an installed base
and standard that already existed and our conflicts are how to work within that
For all practical purposes, Office 2000 requires Windows and IE. We started the
project trying to be <i>great on
all browsers, and even greater on Internet Explorer</i> (from our vision
and presentation we did for you), but the
momentum inside the company essentially prevents that message from making it
through development. Only
the most basic rendering works in other browsers--IE is required for:
<li>PowerPoint (the default output is IE only, and that is essentially
<li>Access Data Pages (IE5)</li>
<li>Web Components (IE5)</li>
<li>Reasonable performance in Excel (due to big tables and the IE5 support
for a predefined table width)</li>
<li>Word and PowerPoint output tons of stuff that only looks good in IE
due to the shared line layout code and
bugs in other browsers implementation of CSS (which is essentially an
IE-specific feature)</li>
<li>HTML email essentially requires Outlook Express or Outlook</li>
<li>Vector Graphics (VML which renders using vectors rather than GIFs)
requires IE</li>
to name a few. I think these are enough to convince people that Office requires
IE in a proprietary way and
that if you want to exchange documents, the odds are your recipients won't be
happy with anything but IE.
On top of that, we have dozens of features in the product that require IE4 and
many that require IE5 -- this is
in order for them to run at document creation time.
I totally understand where you're coming from, but in trying to decide what to
do it isn't that black and white for
me based on the experiences I've had personally with people. We have talked
about this a lot and I really do
need your help. If Office documents can only be rendered in it is a complete
non-starter with customers. This
is not a religious issue, but just a practical one.
If Office documents only render in IE then there is zero chance that anyone will
be able to use Office to create
documents that will be shared outside an environment with the standardized
Window browsers (intranet
perhaps, but only perhaps given the time to migrate and the minority of Win 3 1,
etc.) Personally I put
pictures of a trip out on that were made with PowerPoint 2000 and
got a dozen messages from
friends and family (including a webtv person) saying they could not see the
pictures. Everything I've posted
here at the business school has been "recalled" by me because students
were notable to read it (all sorts of
combinations of OS/browsers).
No area of the product has received more skepticism and push back than our HTML
output--from reviewers,
analysts, and beta customers. The other night I attended a 500 person Office
2000 event in Boston (the
"Team Web Tour"). The whole presentation was in IE and every time the
browser was shown hands went up
to ask "what about non-IE browsers?". Finally the demonstration
showed powerpoint 2000 in IE which is
*awesome* output--then showed the non-IE output and it was just ugly (didn't
scale, fixed size slides, no slide
show view, no DHTML, etc.) I thought the audience was either going to get up
and walk out in disgust or rush
the stage in protest
Again, I really understand the business issues and strategic issues. I think
we're just faced with the reality that
if we require IE for rendering as an explicit choice (that is when you load a
page it just says "You're not running
IE") then we are just saying that Office's HTML is a demo feature and not
for practical use. If we didn't have
HTML support in Office 2000, then I'm still convinced we would have been working
on a release that
customers would have viewed as utterly irrelevant--creating web documents is
what people need/want to do:
with Office or without Office. That's the catch-22 I feel we're in. Unless
things change a lot, my feeling is that
an upgrade to Office 2000 is already in jeapordy with customers that do not use
IE and any higher level of
requirements will drive our upgrade changes way down.
I think this knob will continue to turn <b>even more</b> towards IE
over time as Windows/IE continues to achieve
success. I suspect that each release of Office will continue to require more
and more of IE. But in order to
even be in the consideration set we will have to have some amount of downlevel
support that customers will
tolerate if they want to exchange information in a professional manner.

-----Original Message-----<br />
<b>From:</b> Bill Gates<br />
<b>Sent:</b> Saturday, December 05, 1998 12:44 PM<br />
<b>To:</b> Bob Muglia (Exchange); Jon DeVaan; Steven Sinofsky<br
<b>Cc:</b> Paul Maritz<br />
<b>Subject:</b> Office rendering

One thing we have got to change in our strategy - allowing Office documents to
be rendered very well by
other peoples browsers is one of the most destructive things we could do to the
We have to stop putting any effort into this and make sure that Office documents
very well depends on
PROPRIETARY IE capabilities.
Anything else is suicide for our platform. This is a case where Ofice has to
avoid doing something to
destory Windows.
I would be glad to explain at greater length.
Likewise this love of DAV in Office/Exchange is a huge problem. I would also
like to make sure people
understand this as well.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )