|
Authored by: Anonymous on Sunday, November 18 2012 @ 08:10 AM EST |
<li><b>Create a large marketing war chest.</b> This can
be funded through contributions from our
OEMs etc.</li>
<li><b>Make a great cross development system for x86.</b>
One way to get software developers
interested in the machine is to make it a very nice, fast
environment for their own use. If it
is a great platform for developing Windows apps for any
machine, and there are cross
development features so that you can produce x86 binaries,
then you will get a lot of ISVs
buying them (with a special discount from the OEMs) for
their own purposes. There is
nothing like having a fast machine in front of developers
to get a lot of midnight projects
going.</li>
</ul>
<h3>3.4. Conclusions</h3>
<p>
There is no silver bullet which we can use to stop SPARC
in its tracks. This was true before the
possibility of Compaq going with SPARC came up, and it is
even more true afterwards. The ideas
discussed in this section give us a very good chance of
slowing SPARC down, and with good
execution we have a solid chance of beating them. "Beat"
in this context means to establish RISC in
the Windows community in such a way as to prevent SPARC
from gaining a foothold in the PC
industry and retail channel.
</p>
<h2>4. RECOMMENDATIONS</h2>
<p>
The first, and obvious thing to do is to work as hard as
possible to try to change Compaq's mind and
not do a SPARC machine. In parallel we should:
</p>
<ol>
<li><b>Redouble our efforts to rapidly define and
implement NT Windows.</b> This includes both
the portable Windows and kernel pieces. This is key
technology in any all scenarios, and
the quicker we have it the better.</li>
<li><b>Do not start work on any SPARC based software.</b>
The time required to port NT is very
small, as has been demonstrated with the 386 port. There
is no reason to confuse the
development team or waste any resource at this time - we
could port the system very
rapidly at any point if it is required. The situation
with our Apps group also does not
require any new action - any spare bandwidth that they
have should be directed toward
moving to 32 bits, which will be required for SPARC as
well as for x86 and MIPS.</li>
<li><b>Refine a plan for uniting the MIPS camp.</b> This
mainly involves figuring out what position
we want with respect to UNIX with MIPS and SCO, and then
taking the show on the road.
Actual implementation of the plan should begin within the
next couple of weeks once we
have a chance to review it. There appears to be little
downside in taking this approach, and
it will benefit us</li>
<li><b>Define Power PC and work out the strategy in more
detail.</b> This is a key part of any plan
and we need to get it very solid very soon.</li>
</ol>
<p>
This list will obviously change as things move along, but
it is a good place to start.
</p>
[ Reply to This | Parent | # ]
|
|
|
|
|