decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Comes 4262-->1997 emails: re future plans for Java on win 3.1 | 226 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Comes 4262-->1997 emails: re future plans for Java on win 3.1
Authored by: foulis on Monday, October 29 2012 @ 05:34 PM EDT
<p
align=right><b>PLAINTIFF'S<br>EXHIBIT<br><u>4262</
u></b><br>Comes v. Microsoft</p>
<b>From:</b> David Sauntry<br>
<b>Sent:</b> Wednesday, April 02, 1997 3:00 PM<br>
<b>To:</b> Rodney Vieira; Alessandro Muti; Edward Ye<br>
<b>Cc:</b> Guy Shefner (RhoTech); Sreeram Nivarthi; Colin Miller;
Michael Toutonghi<br>
<b>Subject:</b> RE: Future Plans for Java on Win 3.1</p>
the ce vm is tied pretty closely to windows ce, which is much like win32. WCE is
hosted of 32 bit cpus, and we take advantage of threads, synchronization,
virtual memory, etc. You should review our src code to better estimate if it
will be of value for you.</p>
That said, here's the info you requested:<br>
<ul><li>what is the footprint of your vm</li></ul>
~100k for the vm (including native code for io/lang/net/util). add around 200k
for the base classes (io, lang, net, util). add another 1M or so for awt and
applet.<br>
<ul><li>what level of functionality do you support...JDK 1.1
compatible?</li></ul>
these numbers are for 1.02. We're moving (fast) toward jdk 1.1 with wce v2
(alder release)<br>
<ul><li>what is your schedule</li></ul>
4/30 1.1 preview at WCE devcon<br>
6/13 1.1 beta<br>
8/29 1.1 alder rtm<br>
<ul><li>would are your thoughts on whether the vm can be easily
ported to win16. we rejected the win32 vm in part because its tightly tied to
win32.</li></ul>
without really thinking about this, I think that we're just as tied to win32 (or
at least the wince subset). java threads are win32 threads, etc. You are welcome
to look thru our src to see if you can use it.</p>
For v3 (birch/1Q98), we're going to look into doing a jitter - something that
will generate native code for the stack machine - we think we can improve our
execution speed by 3-4X by just getting rid of the overhead of the interpreter
loop... No schedule or spec for this yet.</p>
daves</p>
<blockquote>--------<br>
<b>From:</b> Rodney Vieira<br>
<b>Sent:</b> Wednesday, March 26, 1997 4:00 PM<br>
<b>To:</b> Ben Slivka; Charles Fitzgerald; David Cole; John Ludwig;
Michael Toutonghi; Russ Arun; Thomas Reardon<br>
<b>Cc:</b> Alessandro Muti; Colin Miller; Edward Ye; Michael Guo;
Vamshidhar Reddy; Rodney Vieira<br>
<b>Subject:</b> Future Plans for Java on Win3.1</p>
As you know we shipped the Java VM (JDK 1.02) for Win 3.1 in mid-March. We are
now thinking about what our strategy should be moving forward. Do we stop
investing in Java and focus on core HTML features? Do we simply make incremental
improvements on the 1.02 code or should we move to the JDK 1.1 codebase? even
better..do we adopt the MS VM?</p>
Below I have summarized some of the alternatives we are
considering....</p>
1. <i>Stop investing in Java for Win 3.1</i>
<blockquote>Several people have suggested that we should give this more
serious consideration The thinking is that corps will not target Win3.1 for Java
development because of the performance limitations and
that</p></blockquote></blockquote>
<p align=right><b>MS-PCA
2615137<br>CONFIDENTIAL</b></p>
<hr>
<br>
<blockquote><blockquote>making huge gains in perf will be extremely
difficult (Note: Peterku believes a JIT would only give us between 2-5X
performance gain over the existing VM because of probs associated with 16 bit
code generation). Consequently, we should think of Java on Win3.1 as a marketing
"check box"...one which we have already satisfied.</p>
My thought are that there are several minor reasons which together justified our
continued investment in Java for Win 3.1. They
are...</p><blockquote>-As far as we know NS will have a 1.1
compatible VM for Win3.1<br>
-Even if perf is limited, NS will have an advantage in selling into corps if
they can claim 1.1 support.<br>
-Compromising on Win3.1 development will just fuel the rhetoric about how we are
not really committed to cross platform solutions and abandoning win
3.1.<br>
-Performance is acceptable for certain class of applets/applications. We are
fine for the "eye candy" stuff and we aren't that bad on apps which
aren't math intensive/graphical.<br>
-The Win 3.1 VM is what we currently have for NT 3.51. How do we explain the
lack of 1.1 support to these
users.</p></blockquote></blockquote>
<center><b>Privilege
Material<br>Redacted</b></center>
<br>
2. <i>Make incremental improvements to the existing 1.02
codebase.</i></p>
<blockquote>If we took this approach the intent would be to focus on
performance and sacrifice additional major functionality like Javabeans, JAR
file support and other JDK 1.1 features. Once we start trying to add major
functionality to this codebase it makes more sense to just use the 1.1
codebase.</p>
Using the existing code also allows us to release improved revs of our VM more
frequently. If we use 1.1 or the MS VM we will probably only do qfes on the
existing VM until we're ready to go public in several months with the new
VM.</p>
My thoughts are that this option is less desirable than (3) or (4) because the
press expects 1.1 level functionality (NS will probably be 1.1 compatibility on
Win3.1). Our corp customers probably also expect 1.1 features, although it could
be argued that they are not depending on java for Win16.</p>
Again there may also be legal complications with option (2). (I suspect we could
figure out how to work around this if we felt this option were the way to
proceed)</p></blockquote>
3. <i>Adopt the JDK 1.1</i></p>
<blockquote>The two major positive aspects to this plan are that it
involves using a codebase that we are reasonably familiar with (less risk/time
than porting the MS VM) and we get 1.1 compatibility...which is probably good
enough for our corp customers since they seem to be writing to the lowest common
denominator (this will probably continue to be the case for as long as Win 3.1
is interesting). The principle down side is that (1) we remain dependent on Sun,
(2) can not leverage our own code (and associated developers), (3) it sends the
wrong message externally...although this hasn't been an issue so far and (4) we
may not choose to implement Java to COM because it will be a significant
investment in resources if we start with the Sun JDK. Given that we are not
investing heavily in ActiveX controls for Win16 this may not be a big deal. Java
apps can use Javabeans.</p>
Clearly, option (4) is a better long term solution, however given the finite
existence of Win 3.1 it may be appropriate to go with 1.1 based on the lower
risk and shorter development time. Unfortunately, its difficult to predict how
long it will take to port the MS VM without spending alot of time going thru the
code. Nonetheless alessandro &amp; co are making an effort to gather more
data. However, given our past experience porting Win32
code</p></blockquote></blockquote>
<p align=right><b>MS-PCA
2615138<br>CONFIDENTIAL</b></p>
<hr>
<br>
<blockquote><blockquote>its safe to say that there will be many
unknowns/surprises. We are also concerned about the fact the MS Java code we
would pick up is still in development.</p>
Our conservative estimate for porting JDK 1.1 is 8 months (Final release) with
the existing 4 dev resources we have on the team.</p></blockquote>
4. <i>Adopt the Win 32 Java VM</i></p>
<blockquote>This approach is attractive for obvious reasons...leverage MS
code, leverage MS developers, more functionality and consistent with overall
strategy. The main concern is that the investment needed to pull this off may
exceed the benefit we derive over the remaining life of Win31. Another
consideration is whether our customers can live with 1.02 while we prepare the
new release of the MS Java VM or would we take an unacceptable beating because
of our lack of a quick 1.1 solution (Win16).</p></blockquote>
My sense is that we should pursue (3) or (4).</p>
Thoughts/Comments?? Other approaches?</p>
Rodney</p></blockquote>
<p align=right><b>MS-PCA
2615139<br>CONFIDENTIAL</b></p>


[ 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 )