Windows CE is a giant testimony to how out of touch Microsoft is with reality.
I skipped the first generation entirely on basic principles. When Windows CE 2.0 became available, I bought a Sharp Mobilon. I wasn't especially impressed with the hardware - the chicklet keyboard was difficult to work with, and the grayscale screen seemed very dull (especially after the vibrant green backlight that I had become accustomed to on my Newton MP2k). Nonetheless, I found it fairly easy to start developing for CE, because the API is based on the traditional Win32 API, which has had some time to mature.
While on a business trip, the cleaning staff in the hotel broke the Mobilon. They replaced it (after an incredible amount of arguing) with the only similar device that I could find in the area - a Compaq HPC. I have to say that the Compaq is probably the worst piece of supposed consumer electronic gear that I've ever seen. The screen's quality is just bad. There's a dark spot in the middle where the backlight just isn't powerful enough to reach. The development tools regularly drop the link to this device when trying to debug anything (probably due to the customizations made to the OS by the manufacturer, since recent patches have made it only fail about 40% of the time, instead of 100%). The keyboard is even worse than the Mobilon. One of the display hinges has broken apart on the seam. The battery life is really feeble, and the OS regularly warns you that you're out of power (which you can fix by turning it off and on again, which makes it realize that it's got plenty of juice left). All in all, I got the short end of the stick in this bargain, but it made me realize just how much better Sharp's product was.
But these are just implementation details: they have nothing to do with what Microsoft set forth as the Windows CE specification. The real problem, as I see it, is that they haven't learned from their own mistakes (surprise!). When Windows NT came out, it was supported on three processors: x86 (Intel), PPC (Motorola), and Alpha (DEC). Within a few years, they realized that nobody wanted PPC support, because x86 was so readily available (and cheap, by comparison). Now, Microsoft has dropped Alpha support from future NT releases (presumably because the cost of maintaining it doesn't exceed the number of sales for the product). I would have thought that this would show Microsoft that it's silly to support an operating system on multiple hardware architectures.
But did they learn? No! The original CE devices were supported in two hardware flavors: MIPS and SH/3. Since then, they've added support for MIPSFP, SH/4, PPC, ARM, and x86. To further complicate matters, there are different versions of the operating system which are nearly identical - 2.0, 2.01, 2.10, 2.11. Lastly, there are different hardware types - the H/PC (a handheld device, the original form factor), the PsPC (Palm-style PC, based on the success of the Palm), and the H/PC Pro devices (which are H/PCs with larger screens, running later OS versions). I'm not even going to discuss the AutoPC.
Okay, so they've left lots of options for the consumer and hardware manufacturer. Have they considered that having one architecture would bring down the cost of the devices due to bulk purchasing of one chipset? Not that I'm aware of. Did they consider the cost for the software developer to develop software for these devices? Not that I can see - their tools assume that you're developing for one of the many devices.
It's the software that makes the platform attractive to the customer, so I would think this is important. Let me demonstrate the complexity with a product that my company has written: Ink Spot CE, a usenet news reader for Windows CE devices.
We have one source tree for all of these devices. With very few exceptions, one source fits all. The exceptions almost invariably fall around the screen size of the target device. In this regard, the development environment is fine. But wait: what about all of these processors? Well, in order to release Ink Spot CE, we have to build the archive (MANUALLY, because the automation tools are incomplete) for each of the following configurations (as of 2003):
- Windows H/PC 2.0 MIPS
- Windows H/PC 2.0 SH/3
- Windows PsPC 2.01 MIPS
- Windows PsPC 2.01 SH/3
- Windows PsPC 2.10 MIPS
- Windows PsPC 2.10 SH/3
- Windows H/PC Pro 2.11 MIPS
- Windows H/PC Pro 2.11 SH/3
- Windows H/PC Pro 2.11 SH/4
- Windows H/PC Pro 2.11 ARM
- Windows H/PC 2000 3.x MIPS
- Windows H/PC 2000 3.x ARM
- Windows PocketPC 2000 3.x MIPS
- Windows PocketPC 2000 3.x ARM
- Windows PocketPC 2002 3.x ARM
- Windows PocketPC 2003 3.x ARM
We're not currently building for MIPSFP or x86, because there aren't (yet) any CE devices that support these processors. Thank God. With the advent of Windows CE 3.0, we had to add the last four configurations as the binaries aren't compatible. Not to mention that we have to support separate installers for each OS revision because the installer isn't aware of the OS versions. There's no excuse for this: the customer shouldn't need to know what version of Windows CE they run.
Lastly, let me rant about "Windows Powered." Microsoft has announced that they're going to rename Windows CE to "Windows Powered," presumably so that people won't realize that they're the same thing. Boy, isn't this going to be fabulous? Every new "Windows Powered" device owner is going to think, as the name implies, that it should run Windows 95/98/NT/2000 software! "Yes sir, we know that our software says that it requires Windows 95, but your devices isn't running that, no matter what it says." What's next? Will they rename the computer to "television-like device?"