Fog Creek Software
Discussion Board




WinCE beats VxWorks in revenue

http://www.embedded.com/story/OEG20030321S0033

With the handheld market growing, MSFT's revenue numbers exceed VxWorks.  Nothing revolutionary, but certainly a data point on the history timeline.

Nat Ersoz
Sunday, March 23, 2003

XP Embedded is the new Big Guy in town if you aren't after a small footprint.  Near as I can tell from our own customer feedback is the adoption rate on this thing is amazing.

Why?  Because the masses already have the development tools and already know the Win32 API in their sleep.

Over time, VxWorks, Wind River, and QNX are probably going to get hosed.

Mitch & Murray (from downtown)
Sunday, March 23, 2003

Being an embedded programmer, I HIGHLY disagree with that statement.  XP Embedded targets an entirely different market than VxWorks, WinCE, or QNX.

XP Embedded is for lightweight PC's, like set-top boxes, thin clients, kiosks, etc.  The biggest selling point for XP Embedded is its compatibility with desktop Windows.  XP embedded does NOT provide any sort of enhanced reliability or deterministic real-time capabilities.  It doesn't support any non-x86 architectures.  You won't find XP Embedded in an avionics system, satellite, or submarine.

VxWorks, WinCE, and QNX are hardened real-time OSes.  They're made for truly embedded systems.  Most RTOSes have no GUI (or it's optional).  They usually don't have any separation between user mode and kernel mode.  Real-Time operating systems are expected to be quick-booting and respond to interrupts instantly.  CPU overhead is minimized.  Also, most RTOSes support a wide range of architectures (PowerPC, XScale, ColdFire, etc).

I will agree that WinCE is an up-and-comming player in the embedded market.  I have more and more customers asking about it (Linux too).  The embedded world is a huge growth market for Microsoft.  98% of all processors sold last year went into embedded systems.

I read about this study about a week ago.  WinCE, Symbian, and Palm are used in handhelds, cell phones, and industrial PCs.  They all have practically zero usage in the military market.  VxWorks and Green Hills are totally unused in the consumer market, but is a huge player in the military market.  QNX is used in the medical and scientific systems.

This study mistakenly lumps all consumer and military systems into one category.  All this really shows me is that the consumer market uses almost as many embedded systems as the military market.

Although, I must admit, I was very surprised to see LynuxWorks in the top 10.

Myron Semack
Sunday, March 23, 2003

Well, for sure you are completely correct about that.  Embedded XP is not for the "hard realtime" folks.  I missed the boat there completely with my comments.

That said, I still contend the Embedded XP is going to clean up for just about everything else.  I worked on some projects in the past where various embedded OS's were used that did not require a hard real-time response.  These guys were farting around with WinCE, QXP, flavors of embedded Linux (ouch, what a POS), etc.  All they really wanted/needed was a modular Win32 OS, and that is exactly what Embedded XP gives them.

What the hey, there's still a huge bunch of folks running embedded MSDOS, and MS will still sell you an OEM distribution license if you don't want to go with several clones that will boot form ROM.

Mitch & Murray (from downtown)
Monday, March 24, 2003

How is it that embedded Linux is a POS, other than your saying so?  Something specific you'd like to comment on?

Nat Ersoz
Tuesday, March 25, 2003

Sorry, I forgot.  Linux doesn't run VB6. 

Nat Ersoz
Tuesday, March 25, 2003

I am personally aware of a very popular line of consumer products that use VxWorks in their firmware. I'd hardly say that VxWorks is "unused in the commercial sector." VxWorks is *expensive*, I'll grant you, but that just means that it's only used where volume makes up for the licensing costs.

Chris Tavares
Tuesday, March 25, 2003

Hey Nat, I don't run VB6 either.  Have you had some excellent success with a flavor of Embedded Linux that you can share with us?  If so, and you can straighten me out, I'd like to hear it.

Really.

Mitch & Murray (from downtown)
Tuesday, March 25, 2003

Nat, in my opinion and (limited) experience embedded linux is often a bad fit for groups doing embedded development. I may be generalizing too much, but out of three linux integrations with my companies tools (getting them working with a specific kernel and board/chip), twice we have been stalled by kernel level bugs (once with ptrace, once with the icache implementation). Since in both cases the client did not possess any linux developers, they were forced to wait and hope someone else would fix the bug.

Now, obviously, the above comments are moot if you DO have someone who is a competent kernel hacker or if you get lucky and don't run into any significant kernel bugs.

Of course, that's just my opinion. *shrug*

Steven C.
Tuesday, March 25, 2003

You are dead right about the popularity of DOS.  About 50% of our customers use DOS.  The same is true for a lot of embedded x86 companies.    It's interrupt performance, low overhead, and rapid boot times make it very popular.  Not to mention it's licensing costs are very low.  As long as you don't need easy network support, high-performance disk access, or a GUI, it's one the best choices.

MS-DOS isn't so popular anymore, though.  The big player these days is Datalight's ROM-DOS  (it's what we ship on our systems).

As for embedded Linux...

It's ok, but I think it's got a long way to go.  Maybe it can compete with XP embedded, but not an RTOS.  Linux/Unix was not developed with the embedded world in mind. 

The kernel has no native real-time support.  You can use a real-time kernel patch, but then you have to re-write all of your drivers to use the real-time API's.  Support is totally non-existant.  You don't find the community support for embedded Linux like you do with desktop Linux (as if that was anything to be excited about).  You can selectively build your own Linux distro, but that gets you a lightweight desktop OS, not a real-time operating system.  Most of the development environments are pretty shoddy (emacs and gcc aren't enough).  Even the commercial ones are dissapointing.  It's trouble-free once it's up and running, but so is any popular RTOS.  I've also encountered more bugs in the Linux kernel than I have with all other RTOSes combined.

Linux has a few advantages:
1) Open source makes the code easier to audit for things like DO-178.
2) No royalties.
3) Better hardware support.
4) Familiar Unix shell.

To get a really solid Linux build, you're better off going to LynuxWorks or MontaVista.  Once you do that, you start to wonder "Why didn't I just get a commerical RTOS in the first place?"

Myron Semack
Tuesday, March 25, 2003

"Most of the development environments are pretty shoddy (emacs and gcc aren't enough). "

<plug>Well if you want to pay for it (read: not most people who are looking at using embedded linux), MULTI (the Green Hills Software IDE) has pretty good support for debugging gnu code -- i.e., numerous body parts above gdb + emacs</plug>

Steve C.
Wednesday, March 26, 2003

Sure.  We use embedded Linux, exclusively.  And, it works very well.  We do not require real-time performance, but that doesn't mean we don't require good performance. 

Bottom line, is you've got to be willing to read source code.  But, in exchange for your efforts, you control everything.  We find, debug and report network driver, kernel, etc. bugs and patches occaissionally.  In addition, I or our partners write all of our video decoder and rendering drivers.

In Consumer Electronics Land, it is hard to find a manufacturer who is *not* supporting or prefering Linux.  No licensing fees - and when your margins are razor thin, taking $10 profit per unit is much more favorable than paying licensing fees.

The Linux kernel is very configurable.  Our typical kernel size is 750KB (and still considered rather featured), compared to a RedHat kernel of 3.2MB.  Just to demonstrate the granularity of configuration.

We currently run on Fujitsu, i3 (sweden) and NextLevel (though NLC is VxWorks) hardware, but just received STB's from Pace and Amino - both preloaded with Linux kernels and the ability to NFS mount root files systems so we can do development work.

The Amino is a very cool and small STB, just barely large enough to fit video and audio output connectors.

I personally use VSlickEdit for development.  Each of our developers has their own preferences.  2 use emacs, one uses Idea, others use Eclipse.  Emacs is very powerful if you're interested in working on the learning curve (I'm not.  As a former BRIEF convert from long ago, Slick performs very nicely).

One final note:  if you're writing a linux device driver, you should be writing it as though it were fully preemtable.  The driver model certainly supports this, and it makes for cleaner code.  If you decide to patch the kernel for RT performance, your pain will be minimal.

Nat Ersoz
Wednesday, March 26, 2003

While the $10 royalty for an OS may indeed impact razor thin profit margins, so can having to hire people to fix kernel bugs that suddenly show up with Linux. I'm not really saying one way is "better" than the other, except insofar as some companies would be wiser to choose one path than the other (as I said earlier).

On the other hand, it sounds like you have a lot more direct experience working with various kernels on different hardware. *shrug*

Steven C.
Wednesday, March 26, 2003

Hey, at least the bugs get fixed.  Do you think that just because you pay for an OS, that its bug free?

Nat Ersoz
Wednesday, March 26, 2003

You misunderstand me Nat. I'm not saying Linux is a bad OS -- simply that many embedded groups seem (again, in my experience) to not have the skills and abilities for it to be a worthwhile investment. Specifically, as I pointed out, the case of having bugs in the kernel which your group does not have the ability to fix easily.

Steven C.
Wednesday, March 26, 2003

Oh sorry -- the other thing is, of course a commercial OS is not bug free (see vxWorks and Windows for examples), but you DO have someone who is responsible (in theory) for fixing the bugs you discover.

In general, I believe some people decide to go with Linux because its "cheaper" -- all I'm saying is that if you don't have the skill to locally fix kernel problems with linux, it could very well end up NOT being cheaper. *shrug*

Steven C.
Wednesday, March 26, 2003

I'm sure you could hire Cygnus (now Red Hat Consulting?) to specifically fix a Linux bug for you.  Having an expert engineer who answers directly to you beats trying to cajole a commerical vendor into fixing your showstopping bug.

D. Rone
Tuesday, April 01, 2003

Sure, but if you have to hire someone to fix kernel bugs for you, then its entirely possible you might have been better off going with a commercial embedded OS.

Note that for my argument here, I'm considering Monta Vista's embedded linux and anything you buy from RedHat as both commercial OS's -- I'm just arguing that for a shop without in-house linux kernel knowledge, it may not be the best bet to go with free-as-in-beer linux.

Steven C.
Wednesday, April 02, 2003

*  Recent Topics

*  Fog Creek Home