David Swart (msg #861) wrote:
> Reality Bites-
> ....
> "The memory needed by a Windows CE system is totally dependent
> on which components the designer of the system selects. For
> example, a low end system with just the kernel, the communications
> stacks, and a single non-display application would require less
> than one-half Megabyte of ROM and 256KB of RAM (depending on the
> application needs, of course)."
> Doesn't sound to me like Windows CE application needs a display
> or visual interface (GUI).
I'll be the first one to admit that, because of the emphasis MSFT
gave the Windows UI in WinCE press releases, I wasn't sure it
could be configured without it. If we take MSFT's marketing
literature, which you so frequently quote, at face value, it
certainly looks like WinCE can run without its UI component. When
WinCE is so configured, what's left? I see a kernel that:
o cannot guarantee timeliness (soft);
o has VERY limited processor support (only 2 flavors of
MIPS and the Hitachi SH3, as of this writing);
o relies on third-parties, or the customer, for hardware
driver support; and
o has no track record to prove reliability.
These last two WinCE traits represent the largest risk, by far, to
timely and successful product development for the potential WinCE
customer.
VxWorks, by contrast, is a "hard" RTOS, capable of guaranteed
timeliness. A company that selects VxWorks as its RTOS can build
products with both "hard" and "soft" real-time requirements, as
needed. The customer also enjoys "guaranteed integration", which
is WIND's assurance that its single-source, multi-vendor hardware
support (CPUs and interface/controller chips) will minimize both
the risk and the time-to-market factors of the product development
process. In addition, Tornado provides an Open Systems development
environment that is not restricted to the Wintel platform. Finally,
VxWorks has nearly a decade of diverse, real-world field applications
to demonstrate its high reliability; I guess that's why NASA selected
it.
> "There are also thousands of Windows CE Independent Software
> Vendors (ISV's) and Independent Hardware Vendors (IHV's) who
> can work with designers on custom applications and peripherals
> or provide already working components. This combination of
> Microsoft's Windows CE technology with our partner companies
> yields a tremendous set of resources and opportunities for the
> embedded system designer."
You apparently think that relying on third-party vendors for basic
RTOS functionality is somehow an advantage for WinCE. I couldn't
disagree more. This is the same business model MSFT used for the PC.
MSFT does the high-margin, low-risk portions of the software, and
leaves the more taxing, less profitable, but most critical system
components to third-parties. The result: an unreliable, unstable,
and expensive to maintain hodge-podge. The reason the Network
Computer (NC) initiative is being embraced by the business community
is the tremendous cost involved in maintaining the PC-based office
environment. When corporate users began deploying network
applications, the lack of stability of Win3.x became so overpowering
that MSFT was forced to develop Plug-n-Play to address the issue. The
result was a year and a half delay in the next release of Windows -
what is now Win95. This doesn't mean that MSFT solved the problem,
it just means they finally took ownership of it. The problem still
exist as evidenced by the recent slip of Win97 to 1998. Even this
minor update of Win95 requires a monumental amount of testing by
MSFT to ensure it will work with the mountain of third-part device
drivers. This effort is required in spite of the fact that there is
a well defined PC hardware standard. The PC paradigm has proven one
thing: it is cheap to buy and expensive to keep.
I'm not saying that there is no place for third-party vendors.
Obviously, no single company can provide everything a diverse
customer base needs. However, third-party products should NOT be
in critical system components. It's one thing to establish APIs
and have third-party vendors supply applications that adhere to
them. It's a completely different story when third-parties are
independently supplying low-level device drivers for an OS. Just
the problem of keeping these third-party device drivers in sync
with OS releases is a configuration nightmare for the customer. A
simple change to an OS kernel data structure can prove fatal to
device drivers, in ways that are not immediately apparent. MSFT
is taking a short-cut to hardware device support for WinCE by using
third-party vendors, as they did for the PC, and the results will
be the same: a product that will be unreliable and unstable for
years to come. Tell me, David, how long was it from MSFT's release
of Win1.0 to the debut of Win95? The answer is about 8 YEARS. Most
corporate users would agree that this is how long it took MSFT to
produce a single-user desktop OS with acceptable stability for the
office environment. On a well defined hardware platform, no less.
What can we expect from WinCE, with its mish-mash of third-party
device support, given that the hardware platform, by definition,
is completely custom? Basically, it will be the WinCE customer that
ends up debugging this mess. Or, he can base his product on VxWorks,
which offers "guaranteed integration". The VxWorks customer knows
that a single supplier provides the quality assurance for the RTOS
and hardware device drivers required by the company's product line,
now and in the future. At the same time, he has the advantage of
Tornado - an Open System, multi-vendor, multi-platform development
environment with every conceivable development tool at his disposal.
> Isn't it interesting that Microsoft is now distributing a
> publication called the "Microsoft Embedded Review".
Why is this so "interesting"? It's called marketing - lots of
companies seem to do it. However, I DO find it interesting that a
third-party vendor hacks the NT kernel to give it "real-time"
capabilities. Isn't MSFT up to it? Who is responsible for testing
new NT/RT releases? Does the third-party supplying the NT "real-time"
kernel extensions re-run all the MSFT system tests - with all the
third-party device drivers - with each new release, or does MSFT do
the re-certification? Any company willing to base their product
line on this type of arrangement should just put a bullet through
their head - it will be a quicker and less painful way to go. I'll
also remind you of post #792 that pointed out that NT can't run
from ROM and, therefore, requires a hard disk and all the associated
file system software to execute. Although you like to make NT/RT
out to be a threat to WIND, it's really competing with modern UNIX
systems, which also have "real-time" capabilities, but certainly
don't participate in the embedded systems RTOS market. By the way,
these UNIX systems (e.g. Sun Solaris) don't rely on third-parties
to hack their OS to provide their "real-time" functionality.
> Interesting reading for anyone trying to see where the
> embedded/real-time market is really going.
Since you seem to enjoy disseminating MSFT information, why don't
you bother to mention that the latest version of WinCE (1.01, due
out this month), according to MSFT, was designed for hand-held PCs.
This version only supports two flavors of the MIPS processor and
the Hitachi SH3 CPU. Version 2.0, which isn't even scheduled to
be released until late 1997 (how long will THIS MSFT product slip?),
only adds support for two more processors - the Intel/AMD 486 and
the 82x series PowerPC. Version 2.0 will also be the first WinCE
release to support LAN connectivity. Maybe you are not aware that
the Intel RISC CPUs (i960), the Motorola 68K family, and the ARM
processors are among the most prevalent in 32-bit embedded systems.
When will they be supported by WinCE - the turn of the century? I
guess you think the world will put its embedded systems development
plans on hold for 4 or 5 years waiting to see if MSFT gets its act
together. Well, I'll remind you : "Reality is not optional".
-Dave Lehenky
P.S. The information on WinCE release schedules and processor support
came from www.mircosoft.com this past weekend. |
