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
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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

To read comments to this article, go here
More on DR-DOS - Exhibits from the Gordon v. MS Trial
Friday, May 14 2004 @ 02:46 AM EDT

As you know, the lawsuit in Minnesota against Microsoft was settled, and the courthouse removed the exhibits. However, we have preserved them, and here is the first day's exhibits from the trial, posted on the court web site on March 18. As you will see, it's about DR-DOS, for the most part.


Gordon Exhibits Published to Web March 18, 2004 Gordon et. al. v. Microsoft Corporation

Exhibits published to Court Web Site on Mar 18, 2004 (Complete)
Microsoft, Novell, Digital Research: DR-DOS, DOS OEM Royalties, application/OS bundling, ROM DOS Sep 1988 - Sep 1991 (8 exhibits, 26 pp.)
Last Revised 4/29/2004

PLAINTIFF'S EXHIBIT 35 Gordon v. Microsoft Plaintiff's Exhibit 35 Gordon v. Microsoft p. 1 of 2 will get upset. There is a strong likelihood however that we could get rid of debug exe3bin and link. That is 60 pages and 15% of the user's ref/guide

One thing we can get rid of though is the user's guide which is geared at the user which has never used MS DOS before That's 62 pages and about 15% more of the manual right there.

Finally as far as GW BAsic [sic] is concerned we need to incorporate a quick reference or whether we like it or not we will get zillions of calls for the manual.

From: mikeswl [indistinct]
To: mikescale [indistinct]
Cc: srkamr [indistinct]; tomle
Subject: DOS 4.0 Retail Upgrade Tree
Date: Thursday, September 22, 1988 12:17PM

Srkam [indistinct] and I created a project for the DOS 4.0 retail upgrade. We put it on TROJANDOS2. The project is called 40RETAIL.


Susan Johnson

From: billg
To: pascalm; russw; tomle
Cc: philba
Subject: Dr dos
Thursday, September 22, 1988 12:41 PM

You never sent me a response on the question of what things an app would do that would make it run with MSDOS and not run with DR-DOS. Is there any version check or api that they fail to have? Is ther[e a] feature they have that might get in our way? I am not looking for something they can't get around. I am looking for something that their current binary fails on.

This is a fairly urgent question for me and I have received nothing.

Susan Johnson

From: tomle
To: pascalm; rossw
Cc: philba; tomle
Subject: Dr dos
Date: Thursday, September 22, 1988 1:28 PM

Page 43

[STAMPED] Exhibit 7
Plaintiff's Exhibit 35 Gordon v. Microsoft p. 2 of 2 I am assuming your [sic] handeling [sic] this one based on the info you got from AaronR pascal. Please correct me if I am wrong?


P.S. I am referring to Bill's quiestion [sic]

Susan Johnson

anthonys; davidma; vich
msSteam; rsype
NP faults in device drivers
Thursday, September 22, 1988 1:35PM

After discussing this with Ross Cook, I decided to do some research. On page 8-91 of the IBM OS/2 Technical Reference, Vol. 1 (VerifyAccess) I see the following paragraph:

Once the process has been verified as having the needed access to a specific address location, the device driver doesn't need to request access verification each time it yields the CPU during task-time processing of this process's request. If the process makes a new request, then the device driver must request access verification.

If I were reading this, I would not assume that I had to do any kind of locking of the segment. The next paragraph says

Note also that, prior to requesting the Lock on user process-supplied addresses, the device driver must verify the user process's access to the memory with the VerifyAccess DevHlp call. The device driver must not yield the CPU between the VerifyAccess and the Lock, *otherwise the user process could shrink the segment before it hsa been locked* [then, in square brackets: ] [emphasis mine]. Once the user access has been verified, the device driver may convert the virtual address to a physical address and lock the memory. The access verification is valid for the duration of the lock.

So the documentation implies that the only reason you'd want to lock a segment would be to prevent a shrink (and presumably a free). There is no mention anywhere in the VerifyAccess man page that says anything about having to protect the segment from swapping or discarding.

I suggest someone check our documentation on this.

It may be wrong, but it's documented, albeit badly. A question: can we detect if a device driver was built with 1.0 tools, or something similar? We may be able to do something to let 1.0 DOs [sic] run unhindered. I asked why this was never seen before, and Ross told me that the EE guys tend to run machines with lots of memory, so they've just never had this happen before.

Based on the above, I'm leaning towards either taking out the message or putting it under vmstrict control. Comments?


Page 44


PLAINTIFF'S EXHIBIT 35A Gordon v. Microsoft
Plaintiff's Exhibit 35A Gordon v. Microsoft p. 1 of 1
[STAMPED] Depo. Ex. 8
[STAMPED] Depo. Ex. 132

>From pasacala Thu Sep 22 14:55:51 1988
To: billg
Cc: aaronr philba russw timle
Subject: Re: DR DOS
Date: Thu Sep 22 14:47:50 1988

Here follow the three "differences" (between DR and MS DOS) that Aaron has been able to find so far. Except for these differences, the two OSs behave similarly, including documented calls.

The bottom line is that, given Aaron's current findings, an application can identify DR DOS. However, most apps usually have no business making the calls that will let them decide which DOS (MS or DR) they are running on.

Do you think differently?

This is the list of differences aaron was able to find.
The DR DOS BOOT RECORD is different. It contains the OEM ID string "DIGITAL" in it.

Undocumented DOS system call 52H returns a pointer to an internal DOS structure known as the "sysinit variables". The DR DOS structure does not match well with MS-DOS:

SysInitVers STRUC
SYSI_DPS DD ? ; DPS chain
SYSI_SFT DD ? ; SFT chain
SYSI_CON DD ? ; CON device
SYSI_MAXSEC DW ? ; maximum sector size
SYSI_BUF DD ? ; buffer chain
SYSI_CDS DD ? ; CDS list
SYSI_FCB DD ? ; FCB chain
SYSI_Keep DW ? ; keep count
SYSI_MMIO DS[?] ? ; Number of block devices
SYSI_MCDS DS[?] ? ; number of CDS's
SYSI_DEV DD ? ; device list
SysInitVers ENDS

SYSI_DFS == 0:0 on DR DOS, never see this on MS-DOS
SYSI_BUF == 0:0 on DR DOS, never see this on MS-DOS
SYSI_CDS == 0:0 on DR DOS, never see this on MS-DOS
Undocumented DOS system calls 12H and 1FH return a pointer to an internal DOS structure known as the "Drive Parameter Block". On MS-DOS all of the DFSs are linked together into a dword linked list. The DR DOS DFSs all have FFFF:FFFF is [sic] the link field and do not form a linked list (this is consistent with the fact that SYSI_DFS == 0.0).

[STAMPED] X0196084 [or X01960S4, intelligible]

PLAINTIFF'S EXHIBIT 109 Gordon v. Microsoft
Plaintiff's Exhibit 109 Gordon v. Microsoft p. 1 of 10
[STAMPED] MSC00474985

Microsoft Corporation [address/tel/telex/fax]

[MICROSOFT branding mark]

Microsoft Memo

TO: Russ Werner

FROM: Mark Chestnut

SUBJECT: Status Report for April, 1989

DATE: 5/22/89

The following summarizes major product marketing activities this past month. A summary of the current status of DOS group projects is also attached.


This was a great month for ROM DOS, as two very high volume potential OEMs who were on the verge of signing with DRI both committed to MS ROM DOS. Vendex/Hcadstart, which is launching a very low cost 8088 machine for distribution through the mass merchant channel, committed to 250K units of ROM DOS and $1 million for the first year. Emerson, which is introducing a full line of low cost PCs (8088, 286 and 386SX), also for distribution through mass merchants, also committed to 250K units and $1.75 million for the first year.

Both Vendcx and Emerson were planning to sign with DRI because it did not appear that we could deliver ROM DOS in the very short term, which is when they needed it Closure of both of these deals was made possible by our decision to do a ROM copy version of DOS 3.31 with large disk partition support, for shipment by the end of this month. Thanks to Tom Lennon and the entire DOS team for moving very quickly and making it possible for us to get this business.

Good progress was also made in getting Intel to move closer to licensing ROM DOS for their Wildcard product I told Intel about our short term plans for ROM copy DOS, and they have agreed to reference sell this with the Wildcard for the time being. Once we have our ROM executable version done, indications are that they will license this from us and distribute it with the Wildcard.

Philba, Tomlc and I also had a meeting with Bruce McCormick, Intel's marketing guy for Flash EPROM. Intel is really pushing their FEPROM technology (they claim to be 2 years ahead of the Japanese), and are actively trying to get OEM design-ins. A big plus for them towards this end is support in DOS for FEPROM which we happen to be working on and will have completed in a couple of months. Intel is very interested in doing some type of joint PR announcing the availability of the FEPROM file system for DOS from MS and Intel's next generation of FEPROM products (target late summer timeframe). I proposed that, at the same time, we announce our ROM executable DOS and that Intel is licensing it and distributing with the Wildcard. Intel is very receptive to this. I will be taking Rich Freedman (our summer intern who will focus on the embedded market) to meet with Intel in early June to discuss this further. Getting Intel to license ROM DOS for the Wildcard would be a big win, and the joint PR could give us a great head start in attacking the embedded market

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 2 of 10


The RUP plan was revised this month so that some additional utilities could be added. Final release is now targeted Tor Sept 30. We .have looked closely at several utilities and feel at this point that we can prqbably include the following in time for a 9/30 release:

  1. QuickHelp
  2. command line editor
  3. undelete command
  4. EMM386 with "loadhigh" option

We also looked very closely at doing "Extended Where", a Magellan-type disk organizer that would be integrated with the shelL It would also have an extensible architecture that would allow for ISVs to easily develop "viewers" (ability to view the files created in a specific application in native form) for their applications. This would be a major advantage over Magellan, which is a closed system (Lotus has to develop the viewers for each application that Magellan supports, resulting in limited app support). We ultimately concluded that we can't do Extended Where for a 9/30 release, but we'll continue to work on it for RUP version 2.

There are some issues with the RUP which need to be resolved. They include:

  1. 3rd party peripheral support. There are concerns about our ability to support weird mass storage devices, WORM drives, etc
  2. OEM support We are currently lacking cooperation from NEC and Toshiba, which represent several hundred thousand machines in the US.
  3. Cost to support the product through PSS.

We will be putting together a plan to address the above and will present this along with our recommendations to Steveb on 5/25.


The DOS group's action items from the last IBM DOS/Win meeting have been completed, and IBM is working towards presenting a plan for DOS/Win to Hanrahan on 6/7. Tomle is coordinating our end of this and is working on a plan designed to gain MS development control over the DOS portion of DOS/Win.

DOS 4.01

DOS 4.01 continues to gain momentum, as several more OEMs began shipping DOS 4.01 in April The list of OEMs currently shipping now includes:

  • Compaq
  • Unisys
  • Olivetti
  • Siemens
  • Amstrad
  • Intel
  • Dell
  • Compuadd
  • Phoenix
Plaintiff's Exhibit 109 Gordon v. Microsoft p. 3 of 10

Another big boost to DOS 4.01 momentum will come in the first part of June, when we expect to issue a "DOS 4 works great with networks" press release. The release will announce 3 COM's shipment of the 3+ redircctor that works with DOS 4, and will also include favorable statements from Novell and Banyan that their products work fine with DOS 4, etc. All three companies have agreed to participate, and I will be working with Marianne Allison to get this thing finalized over the next couple of weeks.

PRI Competitive Response

The first MS product with the nonnested DOS warning code. Quick Pascal, was released. Tom Reeve and Cindy Kasin have committed to implementing it in all new MS application and language releases from this point forward, including international.

I am also planning to hire an independent DOS guru to do an in-depth comparative analysis of MS vs. DR DOS, with the idea of somehow making those results available to the press. This could be useful ammunition to have against DRI, and will be of value even if we choose not to make it public. I approached Ray Duncan about doing this, but he finally said "no thanks", so I am now talking to Rick Wilton, another DOS guru who writes for MS Press.

DOS Royalty and Packaged Product Business

DOS OEM Royalty, Domestic and International

Royalty business continues to be very strong, with both domestic and international OEM well above budgeted unit shipments for the year (see attached spreadsheet and charts). Domestic revenue is only 92% of budget, however, primarily due to the effect of several OEMs having prepaid balances (meaning that they previously paid royalties on units shipped this year, which explains why units shipped exceeds revenue recognized for the year). .

International royalty revenue is 174% of budget, so overall DOS royalty revenue is $19 million ahead of budget year to date.

DOS Packaged Product, Domestic and International

Domestic packaged product shipments continue their upward trend for April was the best month this year with over 22K units shipped. International packaged product shipments were down in ApriL Both domestic and international packaged product shipments for April show an increase in DOS 3-3 shipments relative to DOS 4.01 shipments. This is because DOS 4.01 shipments were temporarily suspended in April until the Amstrad bug was fixed and all inventory re-worked. I therefore expect DOS 4.01 shipments to continue to increase relative to 3.3, as was the trend in the months prior to April

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 4 of 10

Performance Against April Objectives

1. Get commitment from Vendex to license ROM.DOS


2. Get commitment from Emerson to license ROM DOS


3. Finalize plans for utilities, online doc, etc. to be included in RUP


4. Set up European trip with MS subs, get all info needed for RUP support of European OEMs.

Turned over to Tomle.

5. Reach agreement with IBM on functional spec and plan for 6/90 seamless product


6. Finalize ROM DOS business plan


May/June Objectives

1. Finalize and issue "DOS 4 works great with networks" press release

2. Finalize plans for utilities, online doc, etc. to be included in RUP

3. Ship ROM DOS 1.0

4. Get closure on Intel licensing ROM DOS for distribution with Wildcard

5. Bring Rich Freedman on board, get him going on embedded market analysis

6. Get closure with DOS guru on MS/DR DOS comparative study

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 5 of 10 MS-DOS year-to Budget vs Actual
Domestic OEM, Royalty

Q1 Budget Q1 Actual % Budget Q2 Budget Q2 Actual % Budget Q3 Budget Q3 Actual % Budget YTD Budget YTD Actual % Budget
Units 484,200 769.800 159% 726.700 817,900 113% 760.900 1,054.300 139% 1.971,800 2,642,000 134%
Revenue $12.658,000 $12,958,000 101% $14,184,000 $14,337,000 101% $20,721,000 $16,638,000 80% $47,763,000 $43,933,000 92%
Domestic OEM, Packaged Product

Q1 Budget Q1 Actual % Budget Q2 Budget Q2 Actual % Budget Q3 Budget Q3 Actual % Budget YTD Budget YTD Actual % Budget
Units 35,200 8,704 25% 46.100 23,200 50% 40,300 52.024 129% 121.600 83,828 69%
Revenue $2,146,000 $543,000 25% $2,812,000 $1,456,000 52% $2,457,000 $2,643,000 108% $7,415,000 $4,642,000 63%
International OEM, Royalty

Q1 Budget Q1 Actual % Budget Q2 Budget Q2 Actual % Budget Q3 Budget Q3 Actual % Budget YTD Budget YTD Actual % Budget
Units 595,600 1.191.100 200% 636,500 $1,217,000 191% 778.500 2,422,400 183% 2,010,600 3,838,500 191%
Revenue $12,845,000 $15,613,000 122% $14,506,000 $19,613,000 135% $18,264,000 $20,933,000 115% $32,326,000 $56,159,000 174%
Int'l OEM. Packaged Product

Q1 Budget Q1 Actual % Budget Q2 Budget Q2 Actual % Budget Q3 Budget Q3 Actual % Budget YTD Budget YTD Actual % Budget
Units 17,285 14.503 84% 23,645 27.112 115% 24.249 30.369 125% 68,646 71.984 105%
Revenue $1,420,436 $953,224 67% $1,949,640 $1,937,190 99% $2,013,299 $2,126,057 106% $5,383,375 $5,016,471 93%

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 6 of 10 [STAMPED] HIGHLY CONFIDENTIAL
[STAMPED] MSC 00474990
[The exhibit page is a bar graph. Approximate numerical values have been eyeball-estimated from the bargraph for purposes of this transcript.]

Worldwide DOS OEM Royalty Revenue, FY [19]89 Actual vs Budget

Q1: Budget $25,000,000 Actual $30,000,000
Q2: Budget $30,000,000 Actual $35,000,000
Q3: Budget $41,000,000 Actual $40,000,000
YTD: Budget $97,000,000 Actual $102,000,000
Plaintiff's Exhibit 109 Gordon v. Microsoft p. 7 of 10 [STAMPED] HIGHLY CONFIDENTIAL
[STAMPED] MSC 00474991
[The exhibit page is a bar graph. Approximate numerical values have been eyeball-estimated from the bargraph for purposes of this transcript.]

Worldwide DOS OEM Packaged Product Revenue, FY [19]89 Actual vs. Budget

Q1: Budget $3,800,000 Actual $1,700,000
Q2: Budget $4,900,000 Actual $3,800,000
Q3: Budget $4,200,000 Actual $4,900,000
YTD: Budget $12,900,000 Actual $9,000,000

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 8 of 10
[STAMPED] MSC 00474992
[The exhibit page is a bar graph. Approximate numerical values have been eyeball-estimated from the bargraph for purposes of this transcript.]

International DOS Packaged Product Units Shipped
[Presumably, 3.3 Refers to DOS Version 3.3. 4.01 Refers to DOS Version 4.01]
Jan: Version 3.3: 2,000 Units. 4.01: 7,400 Units.
Feb: Version 3.3: 1,900 Units. 4.01: 7,900 Units.
Mar: Version 3.3: 2,000 Units. 4.01: 10,000 Units.
Apr: Version 3.3: 3,700 Units. 4.01: 5,000 Units. Plaintiff's Exhibit 109 Gordon v. Microsoft p. 9 of 10 [STAMPED] HIGHLY CONFIDENTIAL
[STAMPED] MSC 00474993
[The exhibit page is a bar graph. Approximate numerical values have been eyeball-estimated from the bargraph for purposes of this transcript.]

Domestic DOS Packaged Product Units Shipped
[Presumably, 3.3 Refers to DOS Version 3.3. 4.01 Refers to DOS Version 4.01]
Jan: Version 3.3: 4,300 Units. 4.01: 8,100 Units.
Feb: Version 3.3: 8,000 Units. 4.01: 12,000 Units.
Mar: Version 3.3: 8,100 Units. 4.01: 11,900 Units.
Apr: Version 3.3: 11,900 Units. 4.01: 11,800 Units.

Plaintiff's Exhibit 109 Gordon v. Microsoft p. 10 of 10
DOS Group Projects 5/22/89
Project Status Major Issues
1. ROM DOS - Development on schedule for July release
- FEPROM development on schedule
- Vendex, Emerson deals closed
- Business plan complete
- Need to do 3.31 level ROM executable
2. RUP - Stevcb meeting 5/25 to finalize utilities, etc.
- Development finishing sizing of utilities
- European status: some OEMs have agreed to cooperate, others needed
- Corpcomm communications plan complete
- Marketing Plan complete
- Initial BOM complete
- Need to plan European OEM trip for June - PSS support issues - Wang, Zenith issues
3. DOS/Win Merge - DOS group action items complete
- IBM presenting to Hanrahan 6/7
- Externals group work items not complete
4. Non MS/PC DOS warning code - Code complete and fully tested
- Code shipping with QuickPascal
- Apps, languages, int'l program mgrs. have committed to incorporating into all MS products from this point on
6. Packaged Product - packaging to be changed in June to reduce COGS by ~$3 (GW Basic manual to be removed)
7. DOS 4 Maint - no resources to address other reported bugs currently assigned - Several potentially severe bugs need attention
8. LIM Issues - MS involvment in Quarterdeck response complete
- Awaiting Intel proposal for LIM 4.1

PLAINTIFF'S EXHIBIT 136 Gordon v. Microsoft Plaintiff's Exhibit 136 Gordon v. Microsoft p. 1 of 2 year old for a day when my regular sitter couldn't one day last month. she lives on 156th just north of Redmond campus. 5 minutes away. she called last week and asked me to let people know she was available periodically. she lives in an apt., has 2 kids (4 and 7), great outdoor play areas. my daughter had a great time there. you might give her a call ([telephone number]) let me know if it works out.

>From bjbank We Aug 9 15:31:08 1989
To: tomle
Cc: bclee bjbank yasukim yongchi
Subject: dos clone check on windows
Date: Fri Jul 03 13:52:46 PDT 1992

Hi Tom,

I need your help again.

MSH of Korea is localizing windows 2.10 and they want to make it check whether the system is real MSDOS or not. If it is it not, it should generate a warning message. I talked to philba and davidw, and davidw said you could help us.

If you read the following emails, I think you will understand our current situation.


>From davidw Wed Aug 9 14:04:57 1989
To: bjbank
Cc: jodys philba tomle
Subject: dos clone check on windows
Date: Wed Aug 09 14:01:11 1989

Windows has no such code in it. Since we do not have any code that does this we put up no warnings. However our testers have informed us that we crash while booting Windows if running under some dos not our own.

Tomle can give you checking for a warning message.

>From bjbank Wed Aug 9 13:10:07 1989.
>From philba Wed Aug 2 15:53:18 1989
Sender: jodys Wed Aug 2 15:47:16 1989
Sender: bjbank Wed Aug 2 15:41:33 1989

Hi, Jody.

I am a project manager at Far East Product Engineering group. My main responsibility is to support far east subsidiaries (MSKK and MSCH) technically. You have been great help to us and we really appreciate it. Recently, I have an inquiry from Korea about the windows product.
Plaintiff's Exhibit 136 Gordon v. Microsoft p. 2 of 2

The question from MSCH is "How to check the DOS is MS-DOS or clone". MSCH wants to include such routine in Hangeul Windows so that Hangeul windows can run only on Hangeul MS-DOS.

Could you tell me to whom I can ask to resolve this problem?


bjbahk/Far East Product Engineering Group

Sender: yongchi Thu Jul 20 18:08:50 1989
To: bjbahk
Subject: DOS clone check on Windows
Cc: bclee dkkim ischoi ivys sangc ucmoon yhjeon
Date: Thu Jul 20 18:08:49 1989

Hello BJ,

We will finish our Windows project before October. Now I must decide our product retail Windows sepc. Would you please let me know how Windows(or other Apps too) check current dos is MS-DOS or MS-DOS clone ? And if it is MS-DOS clone how original WIndows [sic] handle them - stop windows, warning messages ?

Thanks, yongchi


>From tomle Wed Aug 9 16:06:08 1989
To: ibmboca?b391747
Cc: philba tomle
Subject: Busmaster interface review
Date: Fri Jul 03 13:52:50 PDT 1992

I understand the busmaster interface proposed by Ralph Lipe is going in front of the architectural review board tomorrow (8/10). I would like to talk to you for a moment to find out if you are on that board as well as getting your impression of the appropriate process to follow. We have not had any previous dealings with the architecture board and so are uncomfortable with the lack of any crisp process to gain acceptance of the interface.

If you don't object, I would like to call you first thing in the morning to talk about this.


>From billg Wed Aug 9 16:32:07 1989
To: markcl
Cc: darrylr paulma tomle
Subject: Extended attributes
Date: Fri Jul 03 13:52:50 PDT 199

[document footer:]
WinMail 1.21 brucen Fri Jul 03 13:42:36 199Page: 150


PLAINTIFF'S EXHIBIT 286 Gordon v. Microsoft [Plaintiff's Exhibit 286 Page 1 of 1]
[STAMPED] Depo. Ex. 822

>From russw Wed May 16 07:36:52 1990
To: billg steveb
Subject: I have asked philba to spend a lot of time making dos 5 happen fast
Cc: ericst jeremybu joachimk markche richardf
Date: Wed May 16 07:34:40 1990

given the aggressive stance taken by dri this week, I have asked philba to spend more of his time on dos 5 than on win 3.1 planning -- like 60-70% to make sure this product happens as fast as it can and that it checks out and to get the troops pumped up.

we are also planning some more extensive pr around our beta ship ( in about 3 weeks) to get acros the message that the product is a now thing vs. a later thing -- dri is spending time saying that our dos 5 won't be around for a long time.

also, I believe that their ems and load-hi modes are incompatible with Win 3.0. we are trying to verify this by the announce timeframe.

[STAMPED] XO196018

Plaintiff's Exhibit 841 Gordon v. Microsoft [Plaintiff's Exhibit 841 Page 1 of 4]
File ; c:bradsinovell.fld
Messages ; 1 - 19

######################################################## 1
>From davidcol Wed Jul 17 08:46:49 1991
To: bradc bradsi gregle philbe richt russs tomle
Subject: novell
Date: Wdd Jul 17 08:46:14 1991

I think we should use Windows to get a Microsoft OS back onto the Netware clients which will bundle or require DR. DOS. We should alter our plans a bit and move all the DOS 6.0 improvements directly into Windows. When the user starts Windows, they get the Microsoft OS (including networking) and all the other cool features that go with that. When they quit, they get Netware and DR DOS and no Windows apps. The key is getting a piece of MS system software on that client so we can deliver our stategy and vision. We can leverage Windows and Windows apps to to this.

We should not consider things that stop Windows from working on Netware. (Netware here = netware + DR DOS.) If it was just DR DOS alone, then we should prevent Windows from working there. Netware has too much market share and too many customers are loyal to it for us to exclude windows from that market.

I think this dictates that we maintain good relationships with Novell so we can stay abreast wjth what they are doing at the detailed technical level. However, I do think that we should do our own winnet drivers and other Novell provider components. If we are going to take over the desktop when Windows starts, it MUST be all Microsoft written software since Novell won't help us do that.

######################################################## 2
>From jimell Wed Jul 17 08:54:44 1991
To: billg bradsi mikemur paulme steveb
Cc: jimell
Subject; Fw: Novell/Digital Research reach definitive agreement...
Date: Wed Jul 17 08:53:48 PDT 1991

I thought about it all night. Since I came here I said there were two things that concerned me related to Novell: one Novell partnering with IBM and two Novell coming at us at the desktop. Both fears have now come true.

I had planned to call Novell this morning and ask them (I know lots of people there) how they plan to position, etc. But the release below makes it pretty clear.

Given this, I suggest (at least for Systems) that we

a) do not change our public posture

b) do not appear alarmed .. "that's interesting or curious or something" would be a good quote.

c) we get serious about supporting our networking more than others. This is the strategy that Novell will adopt as soon as they have a product to do so. They will of course continue to support "foreign" OSs like Windows and DOS, but their focus will be on building a new generation OS for the desktop.

I understand the difficulties of working with ISVs to get them to change their support from Windows, but we shouldn't kid ourselves. I have been fighthing Novell for years -- we shouldn't underestimate their technical or marketing abilities. Their intentions are clear.

Our posture should be the same. We support out networking and also "foreign" servers such as Novell, etc.

d) I suggest that we only include our software on the diskettes for Windows 3.1 and future DOS versions. We can be open without doing this. (Note that doing Netware and LM dual redirectors and the service provider environment are still critical components of the system.) (We ship compatibility software to other formats -- we should do the same for networking. We don't ship parts of 123 or other products in Excel. I never have agreed with this strategy and still don't. Actually for the current set of products and given where LM has been, that was probably the right strategy, but we must change this for the future.)

e) I suggest that we include winball into 3.1 as a standard feature as soon as its ready with minimal price change.

f) We should provide some part of LM as a standard packaged part of NT. Support pricing must be worked out.o

g) We consider changing our apps to not run unless the OS is our OS.

h) We must leverage our networking and OS strengths together to win this battle. Not doing so already has hurt the networking business and if the release is any indication, it will hurt the OS business in the future.

| >From rooternef Wed Jull 17 08:12:40 1991
| To: execnews
| Cc: sharonb
| Subject; Novell/Digital Research reach definitive agreement...
| Date: Wed Jul 17 08:02:56 1991
| NOVELL DGTL RESEARCH: Novell and Digital Research sign definitive merger
| agreement
| July 17, 1991
| PROVO, Utah--(BUSINESS WIRE)--Novell Inc. (NASDAQ:NOVL) and
| Digital Research Inc., a developer of advenced operating system
| software. Including the first DOS 5 operating system, Wednesday
| signed a definitive agreement to merge the two companies, making
| Digital Research, headquartered in Monterey, Calif., a wholly-owned

[Plaintiff's Exhibit 841 Page 2 of 4]

| subsidary of Novell.
| Under the terms of the definitive agreement signed yesterday,
| existing shares of Digital Research common stock, convertible
| securities and options will be exchanged for $1.5 million newly
| issued shares od Novell common stock.
| Digital Research is a private company incorpotated in the state
| of California, It is the originator of CP/M, the precursor of
| today's disc operating systems and DR DOS.
| "Our strategy is to provide computer users and industry partners
| with easier to use, more powerful, software products to support tight
| integration between desktop computers, computer networks and host
| computer systems," said Ray Noorda, Novell's president and chief
| executive officer.
| "Digital research is an important part of this strategy, Novell
| is welcoming a talented organization with technology leadership not
| only in DOS operating system products, but also forward looking
| expertise in multi-tasking and graphical user interface technology."
| Novell said it is responding to customer demand for tightly
| coupling network operating system software with desktop and host
| computer operating systems. Novell has already become the largest
| outside investor in UNIX System Laboratories, the developer of UNIX
| System V release 4.
| With the merger with Digital Research, Novell is adding DOS,
| multi-tasking and real-time operating system technology. The
| combined resources are seen as providing a dynamic technology
| platform for better integrating DOS, UNIX and Netware operating
| system environments.
| In addition, the company will continue to develop innovative
| software products to support customer utilization of OS/2, Windows,
| Apple Macintosh and other operating system environments.
| Dick Williams, president and CEO of Digital Research, said the
| merger gives Digital research significant new market reach through
| Novell's relations with leading computer vendors, its presence in the
| systems integration market, and far reachind distribution, marketing,
| education and customer support resources.
| "We have long understood the value to customers of significantly
| extending the capabilities of DOS. Digital Research and DR DOS have
| already set the standard for DOS capabilities in the 1990s. Tightly
| integrated products from Novell and Digital Research will simplify
| network use and better support our mutual customers and industry
| partners."
| "With novell, we see ourselves as supplies of total, operating
| system solutions for the enterprise computing environment, from
| banking to industrial automation real-time requirements, to advanced
| graphical user interface technology," Williams added.
| Digital Research brings two new software engineering centers to
| Novell. In Monterey, Digital develops graphical user interface
| technology and FlexOS, a real-time, multitasking, multiuser operating
| system for the Intel family of microprocessors.
| FlexOS combines general purpose operating system ease-of-use with
| real-time, transaction oriented capability necessary for
| point-of-sale, and industrial and process control systems. Original
| equipment manufacturers who deliver FlexOS with their systems include
| FANUC, IBM, ICL, TEC and Siemens.
| In Hungerford, Berks, the United Kingdom, Digital develops its
| general operating system family of products, including DR DOS, DR
| Multiuser DOS and Concurrent DOS. DR DOS represents between 10 and
| 15 percent of the overall DOS market, is translated into major
| languages, and is sold to end-users worldwide through both software
| distribution channels and more than 200 OEM vendors.
| The merger agreement has been approved by the boards of directors
| of each company, but remains subject to the approval of Digital
| Research stockholders, regulatory approvals and other normal conditions
| to closing. Certain digital Research stockholders, including each of
| its directors, have signed agreements to vote their shares in favor of
| the merger, which is expected to be completed in October 1991.
| As part of the agreement, Digital research has agreed to pay a fee
| in the event the merger fails to be completed due to a vote of their
| shareholders, or a change in recommendation by the Digital Research
| board. The merger agreement is expected to be accounted for as a
| pooling-of-interests.
| Digital research, with 273 employees, had revenue of $40.9 million
| in its fiscal year ended Sept. 30, 1990, up from $36.2 million in
| fiscal 1989.
| Novell, Inc. is the leading providor of network server operating
| system software that integrates desktop computers, servers, and
| minicomputer and mainframe hosts for information sharing.
| Novell's NetWare network computing products manage and control
| the sharing of services, data and applications among PC workgroups,
| departmental networks and across business-wide information systems.
| CONTACT: Novell Inc.
| Peter Troop, XXX/XXX-XXXX
| or
| Digital Research
| Joe Taglis, XXX/XXX-XXXX

######################################################## 3
>From philbe Wed Jul 17 08:S9:13 1991
To: bradsi
Subject: ReL novell
Date Tue Jul 16 08:47:52 1991

I think we need to carefully measure our ewsponse. Totally freezing them out will force them to compete on a wider basis and could cause the disaster scenario to occur. Not to mention the thin FTC ice that we would be on. On the other hand, we have an advantage with windows and should press it in the system arena. One approach would be to deny enhanced mode to all but real-mode dos customers. This can be to move kernel (or major components of it) into a VxD and thus significantly up the cost of entry to running 'full' windows. This has the 'side effect' of disallowing enhanced mode under a dpml server and not running the more advance components except in enhanced mode. It is, however, a bunch of work -- my guess is 1+ MM.

As for denying them access to windows info, I think this is something we should not do. Having shitty windows support in netware will only hurt us.

| > From bradsi Tue Jul 16 23:33:12 1991
| To: bradc davidcol greglo philbe richt russs tomle
[Plaintiff's Exhibit 841 Page 3 of 4]

| Subject: novell
| Date: Tue Jul 16 23:32:44 1991
| this novell thing bugs me. we need to think through what kind
| of relationship we can/should have with novell now
| for dos, windows, dos6 and win32. i'm
| sure jimall and stevea are thinking the same for winx/win4.
| send me your thoughts on novell, I'll pass along
| some of mine. I want to put together recommendations
| and present to other execs.

######################################################## 4
>From tomle Wed Jul 17 09:29:18 1991
To: bradsi
Cc: tomle
Subject: Re: novell
Date: wed, 17 Jul 91 09:28:03 PDT

I spent time last night since I couldn't sleep very well. Her is what I came up with:

Why would Novell do this?

This seems like an odd move if they really understand the position we were placing them in, why would they make the move gauranteed to get us the most angry?

1) Their greedy. They see a marvelous opportunity to take Microsoft's position in the systems market. With IBM and MS going at it, it would be a great time for Novell to leverage their Net dominance, their current relationship with IBM and their advantage in Corporate loyalty to muscle our cash cow away from us.

2) They are planning to use the DR-DOS threat to force MS to do what Novell wants in both Dos and Windows. My understanding from Kaveen and Terry is that Novell has a strong Windows strategy so unless they are moving away from that strategy, this move somehow has to make sense in a Windows strategy.

3) Both of the above.

4) They think that offering a complete Novell solution gives them an edge in the corporate environment. You must question, an edge over what? Can they achieve this knowing that Windows will be everywhere?

The really scary part for me is that we were in the infancy stages of developing a relationship with Novell so we know very little. The first question I want to try to answer is, given Novell control over Dos, what would they do to it? My strategy would be to release Dos products very early on that hit key features on the list of things we think Novell would do.

How do we deal with Novell now that this has happened.

1) Windows gets another reason it must succeed. Because of that I strongly recommend the Windows group NOT close off to Novell. Windows must execute on the strategy of being the best network workstation environment and Novell is the key player there. I have to trust the windows folks to be in bed with my enemy while still being on my side. This is exactly what i asked of the lanman guys in Dos 5.00 and it worked.

2) Dos can't be that close yet. I am sure it was a little disconcerting for the Novell guys to start talking to the Dos group but we gave them assurances and we were building trust. We need assurances from Novell that these groups are maintained separatly and that their NDAs are meanigful before the Dos group can continue developing it's Novell relationship.

Strategy for dealing with Novell DR-Dos

I am assuming they will take over the Dos market if they can and if they can't they will force some control over Windows directions.

DR-Dos 6.00 is real and is in beta. If I am right about what they are doing, they will release DR-Dos 6.00 before adjusting the DR-Dos priorities on a Network focus. We can't let Novell take the lead in the Dos technology market. This will bw a real challange for us but one I think we have to meet.

We must convice Novell there is real value in Windows and Dos having a close intimate relationship.


| > From bradsi Tue Jul 16 23:33:12 1991
| To: bradc davidcol greglo philbe richt russs tomle
| Subject: novell
| Date: Tue Jul 16 23:32:44 1991
| this novell thing bugs me. we need to think through what kind
| of relationship we can/should have with novell now
| for dos, windows, dos6 and win32. i'm
| sure jimall and stevea are thinking the same for winx/win4.
| send me your thoughts on novell, I'll pass along
| some of mine. I want to put together recommendations
| and present to other execs.

######################################################## 5
>From russa Wed Jul 17 10:16:16 1991
To: bradsi
Subject: Re: novell
Data: Wed Jul 17 10:15:07 PDT 1991

My initial thoughts on this are that:
1) this is a strategic mistake for Novell
2) If they change their product strategy mush (ie. build net products that are proprietary to DR DOS) it will be to their detriment
3) they have acquired some programers that will make them more agressive (and successful?) at GUI work
4) the biggest danger for us that they try to be very agressive with DR DOS pricing
5) that competition is not all bad: it may have some shirt/longterm effect on our profits, but it will get us all that much more focused
6) relationship-wise we do have to tread lightly with them
[Plaintiff's Exhibit 841 Page 4 of 4]

In a nutshell, I don't see why it will be an easier for them to enter our market (DOS) as it was for us to enter theirs (Netware). I suspect if they try a frontal assault on the DOS/desktop os biz it will cost then big $'s and they will not succeed. On the other hand if they use it as a platform for "proprietary" net products (ie. that don't run on DOS 5.0/6.0) they will be shooting themselves in the foot. And if they offer 2 versions, a "better one" on DR DOS and a "normal one" on DOS 5/6, I think the market will shrug. If they try to beat us to mky with a 32 bit DOS, again, I think the market will shrug, and this might complicate their relationship with IBM. Product wise in desktop or market, if we execute, then I don't see what they gain.

The flip side of this is, I don't see why we would change our product strategy to somehow "exclude" them, which would be suicide from a net mkt perspective. From a winball perspective, I don't think it changes our Netware plans. We still have to co-exist with installed NetWare LANs, and if we can get them to sign up for licensing us the redir/xport, we'd still like to make it easier for the NetWare customer to install winbell/windows on a NetWare LAN. This is good for them, but good for us.

As far as our relationship with them, I think there are some open issues that we need to think through carefully. We obviously need them to continue to support Windows (including winbell), so if they come to us and ask to help them write VxD's etc, I think we have to help. On the other hand, what if they come and want help getting their new peer to peer product to co-exist with winbell? It's windows, but it's a directly competitive product. This is the sticky territory where I think we are bound to have to work with them, but it will be difficult for both companies. One way to look at it is, for the first time we are looking out at a company that is in 2 businesses and that causes conflict for us because we compete with them and need to be friends with them at the same time. Of course this is exactly what companies like Novell have been faced with in dealing with MS for so long. We'll just have to continue to tread the fine lines. Both companies need each other too much.

The 2 biggest residual effects of the deal are that they can cut the price of DR DOS If they choose to, which might cause us some short term price pressure, and they have apparantly acquired some good GUI programmers. This will probably make them more aggressive about graphical interfaces throughout their product line, which will be good for them.

######################################################## 6
>From russe wed Jul 17 11:43:41 1991 To: bradsi
Subject: RE; Novell/Digital Research
Date: Wed Jul 11:44:38 PDT 1991

Between you and me, I don't see what has changed that would make us reconsider this. I hope no one at MS, including myself, gets defocused reconsidering this transaction just because Adrian is at Artisoft now. We are embarked on a dev course that makes sense for and we should be single minded in pursuing it. The decision to do all 32 bit VxD work is looking better everyday. I bet that's why Adrian wants to re-ignite this merger (because he knows that Artisoft probably can't do it on their own), and it will also give us an advantage against whatever peer product Novell comme up with (I assume they are not ding VxD work since they have not come to us for help.

| >From bradsi Wed Jul 17 11:07:00 1991
| To: russs
| Subject: Novell/Digital Research
| Date: Wed, 17 Jul 91 11:04:49 PDT
| fyi but not for forwarding or discussion with others.
| | >From mikemur Wed Jul 17 09:20:55 1991
| | To: billg steveb
| | Cc: bradsi jimll paulme
| | Subject: Novell/Digital Research
| | Date: Wed Jul 17 08:20:48 PDT 1991
| |
| | Adrian King called this morning from his new office at Artisoft.
| | He said that Jack Schoof is "very" interested in re-opening
| | discussions with us regarding MS acquiring Artisoft. Jack
| | believes that Novell is gunning for us. While he understands
| | our decision to do Kate (Winbell) ourselves, he thinks we're
| | at risk on the low-end DOS peer networking market. He feels
| | that Artisoft can plug that hole instantly for us and can then
| | share with us their sound and windows knowledge.
| |
| | They (Jack and Adrian) would like us to take this as a real
| | "offer" to re-open discussions.
| |

######################################################## 7
>From russs Wed Jul 17 12:08:14 1991
To: bradsi
Subject; REl Novell/Digital research
Date Wed Jul 17 12:07:04 PDT 1991

What I meant by the VxD comment is the following. Today Artisoft has only a DOS real mode product. I am reading into the new merger proposition from Artisoft that the first thing Adrian talked about with Jack was "how do we get a better Windows product, ie. better integrated UI with Win, prot mode support" etc. And the ease answer of course is, have MS buy us. I think a big piece of this decision, if I was Adrian, would be the 32 bit prot mode work, which I know MS is doingm and I know it is market critical, and I know it will be hard to get it developed at Artisoft.

I am also reading into the Novell picture. Given that there plans to do a peer product are serious, they are most likely giong to follow the LANtastic model (the CNN article even said something like they were out to get Artisoft), ie. a DOS real mode peer product that runs under Windows with the UI being an app.

In both these cases we have 2 significant advantages 1) better memory solution since runs in Win prot mode 2) better integration with Win, since we can hack on file and prt mgr

So where we have an advantage is windows - we will have a significantly better windows product. Meanwhile, Novell, Artisoft and the rest will fight it out for the DOS real mode running under WIN market - good decision by us to stay out of that dogfight and focus on where we add value and gain competitive advantage - Windows.

PLAINTIFF'S EXHIBIT 986 Gordon v. Microsoft [Plaintiff's Exhibit 986 Page 1 of 1]
####################################################### 346
>From philta(?) Mon Sep 30 09:03:27 1991
To: chuckst(?) mikedr scottq
Cc: bradsi davidcol(?) mackm tomle
Subject: Re: Bambi on DR-DOS 6.0
Date: Sat 28 Sep 91 08:46:59 PDT

The approach we will take is to detect dr 6 and refuse to load. The error message should be something like `Invalid device driver interface'.

mike, tom? make - do you have a reliable dr6 detection mechanism?

>From chuckst(?) Sun Sep 29 17:16:46 1991
To: mikedr philba scottq
Subject: Bambi on DR-DOS 6.0
Date: Sun Sep 29 17:16:39 1991

I tracked down a serious incompatibility with DR-DOS 6 -- They don't use the 'normal' device driver interface for >32M partitions. Instead of setting(?) the regular START SECTOR field to 0ffffh and then using a brand new 32-bit field the way MS-DOS has always done, they simply extended the start sector field by 16 bits.

This seems like a foolish oversight on their part and will likely result in extensive incompatibilities when they try to run with 3rd part device drivers.

I've patched a version of Bambi to work with DRD6 ad it seems to run Win 3.1 without difficulty. This same problem may have caused other problems with Win 3.1 and the swapfile under DRD6.

It is possible to make Bambi work, assuming we can come up with a reasonably safe method for detecting DRD6. The runtime hit would be minimal in time and space, although we wuld have a couple of instructions in the main code path for checking the 'special' DRD6 flag.

What do we think? Should we test further with the patched Bambi to see if there are any more incompatibilities????

####################################################### 347
>From bradc Mon Sep 30 09:08:07 1991
To: lorisi(?) sharonh
Cc: bradsi
Subject: steveb meeting
Date: Mon Sep 30 09:09:00 PDT 1991

i have a meeting with steveb tommorrow[sic] at 1pm to go over the dr dos stuff. i'd like brad to attend with me. if he can't see if we can rechedule for another time tommorrow[sic] when he can.

PLAINTIFF'S EXHIBIT 4407 Gordon v. Microsoft Plaintiff's Exhibit 4407 p. 1 of 3
Win 3.1 Beta Plan
17 December 1990


Plaintiff's Exhibit 4407 p. 2 of 3

Types of Beta Programs:

There are three concurrent Beta Programs planned for Windows 3.1.

  • Technical Beta
  • Pre-Release
  • Preview

Technical Beta is defined as those actively testing the Retail Windows product as part of a Beta Test. Pre-Release is to give customers, primary ISVs, early access to Retail, the SDK and the DDK as appropriate. The Preview program is for those who will not be actively doining testing, but who wish to preview the Retail product (ie. Corporate Accounts).

There are four other groups which will be receiving the Windows 3.1 software early. They are Windows Development Partners, ESP (Early ship program) OEMs (Original equipment manufacturers), general OEMs and some Press/Authors. There may be some general OEMs who are also Technical Beta testers, but it is important to note that they will be receiving additional software besides the retail product


The purpose of the Beta programs is to:

  • Get feedback from external sites on the stability of the product
  • Test the product on a variety of machine configurations provided by the beta test sites
  • Allow early accoss to the software and tools so ISVs gain a *head-start" on updating their applications
  • Provide early exposure for the product

Number of Sites:

There will be approximately 360 sites involved with Iha Technical Beta. This groop will consist of Corporate accounts. ISVs, and End users. The Pre-Release program will have have upwards ot 2500 ISV participants. Approximately 500 retail copies will be given out as part of the Preview program. There are approximately 12 Development partners, 15 ESP OEMs and 300 general OEMs who will be receiving Windows 3.1 software.

Software and Frequency of Shipments:

Program Software Frequency
Technical Beta Retail 3x (1/21,3/15,5/10)
Pre-Release Retail/SDK/DDK 3x (2/15,3/29,5/10,6/10)
Pre-Release (Strategic) Retail/SDK/DDK every 4 wks plus 2/15,3/29,5/10,6/10
Preview Retail 2x (1/21,3/15)
ESP OEMs OAK every 4 wks plus 2/15,3/29,5/10
Development Partners Retail/SDK/DDK every 2 wks plus 2/15,3/29,5/10
General OEMs OAK 3x (2/15,3/29,5/10)
Press/Authors/etc. Retail 1x (3/15)

Windows 3.1 Beta Plan


Plaintiff's Exhibit 4407 Page 3 of 3

Length of Beta:

The Technical Beta is scheduled to start on 1/21. The Pre-Release program oficially starts on 2/15. Primarily he difference between 1/21 abd 2/15 is to allow time to create the SDK, DDK and OAK kits and also for some additional testing time. The next major updata will be on 3/15. Some hardcopy docs (updated File Manger/Control panel and release notes) will be included in the 1/21 and 2/15 shipments with the possibility d of an updated version being sent with the 3/15 version. 5/i0 is theapproximate Retail ship date and 6/10 is the appoximate SDK ship date. See table below far dates and approximate numbers shipped.

Key ISVs ISVs Others Total Number
2/15 2/15 2/15 ~1500
3/29 3/29 3/29 ~2000
5/10 5/10 5/10 ~2500 (Retail)
6/10 6/10 ? ~3000
~200 500-2500 ~500 ~9300

Beta Coordinator;

The DOS/Windows Beta Coordinator will assist Program Management by providing information on how to start and run a beta program with specific duties in the following areas:
1) With initial input from Program manager, define fields and write database tables using Superbase as startup database.
2) Make recommendations on staffing levels of temporary staff including start date and duration of assignment.
3) Hire and manage temporary staff.
4) Disseminate flow of incoming information, to the admin and tech staff.
5) Coordinate mailings and other projects
6) Maintain inventory of Beta equipment, including printer to do labels (most of this equipment is currentiy in use by the DOS 5.0 beta program).
7) Special projects as requested and time permits.


Up to two people from PSS (DSBU) will be providing support for the Technical Beta testers. One person from PSS (SSBU) will be answering SDK-type questions from the ISVs (Ie. Pre-Release participants). These dedicated PSS members will be resident in bldg 3 during the Bets Programs. There, will be a dedicated FAX. and answering machine to report bugs. Use of Online 2 will be required by the Pre-Release members. Those customers who are previewing the retail product can Fax or phone in their bugs, but will not be given support unless they buy Online. A bug report sent to Online will not be counted as an SR.

Note: The use of CompuServe has been suggested. I am waiting to see how well CompuServe works for DOS 5 beiore deciding whether it will be used in the Windows 3.1 Beta programs.
Windows 3.1 Beta Plan


PLAINTIFF'S EXHIBIT 4546A Gordon v. Microsoft Plaintiff's Exhibit 4546A p. 1 of 3
Bruce Neiminen

From: bradc
To: galld; mmerker; rond
Cc: bradc; dosmktg
Subject: Key Competitive Info
Date: Thursday, May 09, 1991 11:47AM

Date: Thu May 09 11:42:49 PDT 1991

As an FYI/reminder, there are two key competitive Info docs that need to go to the field/onto SmartPages. Both of these docs are on pyrexpublic. They are in dosmktgsales.inf.

Document #1 - OEM.DOC
Explains how to sell the MS-DOS 5 Upgrade when you encounter an OEM also selling a DOS Upgrade. It focuses alot on the advantages of our product over the IBM product

Document #2 - Drdos.doc
Summarizes the key advantages of MS-DOS 5 and the MS-DOS 5 Upgrade versus Dr.DOS. We are doing further research on this and will have even more data soon.

Please work with richf to get these to the people out there that need them...

thanks for all your help

Bruce Neiminen

From: bradc
To: bradsl (bradsi?); steveb
Cc: bradc; joachimk; sergiop
Subject: RE: DRI
Date: Sunday, May 12, 1991 10:38AM

Date: Sat May 11 22:45:38 PDT 1991

consider it done.

>From steveb Tue May 14 19:02:58 1991
To: bradc bradsl (bradsi?)
Cc: joadhimk
Subject: DRI
Page 43


Plaintiff's Exhibit 4546A Page 2 of 3

a customer can buy a network operating system from Novell without buying anything from Microsoft.
Ray Noorda, Novells chief executive, downplayed his company's rivalry with Microsoft, saying he was attracted to Digital Research because its version of DOS is superior to Microsoft's in some ways.
"Now we can add capabilities (to DOS) in advance of Microsoft doing it" Noorda said in a telephone conference.
The deal, which the companies expect will be completed by October, calls for Novell to issue 1.5 million in new shares in return for Digital Research's private stock. Digital Research said it had revenues of $40.9 million for its fiscal year ended last September.
-O- 5 18 pm edt 07-1 $-91 23

Copyright (c) 1991 Dow Jones and Company, Inc.
Received by NewsEDGE/LAN: O7/16/S1|14:2O

Bruce Neimlnen

From: bradc
To: bradsi; davidcol; greglo; philba; richt; russs; tomle
Cc; bradc; rtcht; sergjop
Subject: RE: novell
Date: Tuesday, July 30,1991 1:41 PM

Date: Thu Jul 18 14:15:35 PDT 1991

One of my thoughts is that we have to thlink about how to short circuit Novell DOS before it gets off the ground. If we can put a daggar in Dr. DOS (or perhaps we should call it Novelal DOS) now then it will put them on the defensive and have customer worried

Now that we have the NSTL data back and some reasonable data on where Dr. DOS is problematic, I'd like to start a 'slow leak' program - every other week or month we try to get the word out on some major dr. dos compatibility problems. At the same time we should be prepared to invest in more third party testing to look for other holes - for example with netware and dr. dos. I'd have to work with PR to develop the specifics of the plan, but if we can get the world to understand that dr. dos has a kit of incompatibities with apps, windows and networks then it will put Novell on the defensive and make it hard for customers or oems (ibm???) to consider dr. dos seriously.

Page 57


Plaintiff's Exhibit 4546A Page 3 of 3

> From davidcol Wed Jul 17 08:47:01 1991
To: bradc bradsl greglo phlba richt russs tomle
Subject: novell

Date: Wed Jul 17 06:46:14 1991

I think we shoud use Windows to get a Microsoft OS back onto the Netware clients which will bundle or require DR. DOS. We should alter our plans a bit and move all the DOS 6.0 improvements directly into Windows. When the user start Windows, they get the Microsoft OS (Including networking) and all the other cool features that go with that. When they quit, they get Netware and DR DOS and no Windows apps. The key is getting a piece of MS system software on that client so we can deliver our strategy and vision, We can leverage Windows and Windows apps to to this.

We should not consider things that stop Windows from working on Netware. (Netware here = netware + DR DOS.) if it was just DR DOS alone, then we should prevent Windows from working there. Netware has too much market share and too many customers are loyal to it for us to exclude windows from that market.

I think this dictates that we maintain good relationships with Novell so we can stay abreast wjth what they are doing at the detailed technical level. However, I do think that we should do our own winnet drivers and other Novell provider components. If we are going to take over the desktop when Windows starts, it MUST be all Microsoft written software since Novell won't help us do that.

Bruce Neimlnen

From: russs
To: bradc
Subject FW: more on DR DOS. Artisoft, and Novell from Jonathon Schmidt
Date: Thursday, August 08,1991 1:53PM

Date: Thu Jul 18 17:24:07 PDT1991

Here Is the mail I sent that BradSI and I werfe telling you about If you want to talk to Jonathon Schimdt his # at Performance Technology is XXX-XXX-XXXX. Tell him I sent you.

>From russs Thu Jul 18 1423:27 1991
To: steveb bradsl mikemur jilmall
Cc: davidl johnlu
Subject: more on DR DOS, Artisoft, and Noj/ell from Jonatbon Schmidt

Page 58


  View Printable Version

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 )