Windows CE is an unbelievable pile of crap under the hood, easily some of the worst code I've ever seen. It should never have been shipped; it was certainly never made better, at least at a level that mattered. Instead, Microsoft kept adding features. CE speaks volumes about the lack of caring about quality and good design from Microsoft's upper management.
Yes, it was killed a few years ago. But it lasted way too long, and did untold amounts of damage to Microsoft's ability to execute in mobile. They spent a lot of time recovering from many bad decisions, mostly politically driven nonsense having nothing to do with making CE any good.
Considering every sysadmin spent yesterday uninstalling rollup 8 for Exchange 2010 and KB3004394, I'm very worried that MS, as an organization, has fallen from grace on a level never before seen. On top of a million other issues like the failure of Office 2013 and Windows 8 in general.
I imagine the politics at Microsoft still remain at, "Catch up to Apple, make our own iPad, iPhone, etc" instead of delivering a good product in the dozen other realms they compete in. Of course the automakers were going to ditch the MS product. Its substandard.
I really wish MS would find a way to up their game. Nadella's tenure isn't looking so bright 8 months in. Not sure if MS is salvageable, to be honest. I sometimes think how much better the products would be if Clinton actually tried to split up the enterprise stuff from the home stuff during the anti-trust settlement, instead of allowing MS to continue as-is and continue to force IE6 on the web for 4 or 5 more years than it deserved to.
>Nadella's tenure isn't looking so bright 8 months in.
I think many here would disagree with that, as shown by the last... 8 months of news about open source this, Linux that, iOS/Android apps, web standards, and GitHub.
I've never heard any complaints about Office 2013, and I haven't heard any complaints about Windows 8 that haven't been solved by Windows 8.1 or Windows 10.
I have heard complaints that it was not a major enough upgrade from 2010, but I certainly appreciate it. The new interface is great, and there are a handful of features that have really made a difference for me. Having decent ODF support, having used OO.o since 2.0 betas made the switch to Office much easier. Editing PDFs has also come in handy quite a few times.
Office 2013 apps are incredibly slow to start and run. Outlook, in particular, will lock up for minutes at a time with no network or CPU activity. Some people in my office use OWA instead of Outlook to get around the lockups.
I don't use Outlook, but all the other Office 2013 apps run fine on my Windows tablet, with a dual core Atom and 1GB of RAM. I've had a 20-slide Powerpoint open and being edited at the same time as a several hundred row Excel document. It wasn't fast, but it wasn't painful.
> I'm very worried that MS, as an organization, has fallen from grace on a level never before seen
That's what happens when a company refuses to pay market rate to its top people. Other Seattle-area tech companies have been poaching from Microsoft for years, and Microsoft hasn't bothered to even try to stop it.
The target markets are pretty limited: obviously not smartphones, not automotive infotainment, really just vertical devices (industrial control panels, portable inventory/barcode scanners)
WinCE 6 is still used widely for car radios, especially by the cost-sensitive Asian suppliers (but not as much by OEs/tier-1s who are all going QNX/Linux).
Unfortunately MS hasn't kept supporting it with new toolchains, VS2008 is the newest version that can target CE5/CE6.
Microsoft was once dominant in high-end infotainment, now they're not even trying to compete.
IMHO WinCE 6.0+ were pretty nice to work with. It could scale down to a system image that was just a couple of MB in size, and scale up to a full blown miniature version of Windows.
Prior versions of CE were a bit janky sure, but remember the sort of hardware it was meant to run on. Having a limited number of process slots isn't the worst idea in the world if you are targeting just a couple MB of RAM!
I'd say that just like any other large legacy code base, CE had some good parts and some bad parts. Everyone on the (6.0+ at least) kernel team knew their stuff, as did the media codec team. I know the C Run Time for 6.0+ was good (I was on the test team for it ;) ).
The lack of a concept of a current working directory was interesting though, of course no smart phone today has such a thing (and we'd think people to be crazy if they requested it!) but the idea was so baked into parts of the Win32 API that it was a fair bit of a porting pain for developers.
Drivers were always a problem for Windows Mobile devices. I actually owned some rock solid high performing WinMo phones, but they were few and far in-between. My Motorola Q9h is still the best smartphone experience I have ever had, it felt /natural/ for me to use, I cannot say that of any other phone I've used since. Also it was lightening fast on just 96MB of RAM. WinMo crawled at 64MB, but it flew at 96MB!
As an example of what it was like from the inside trying to make everything work, when working on WinMo6.5, we couldn't get our OEM partners to give us source access to their keyboard driver for us to make fixes for them to our test devices! (You ever try testing software when you cannot get hardware that it runs on? Ugh) They considered their keyboard driver to be "secret".
These types of problems were a large part of the reason behind the decisions for MS to write the majority of drivers for Windows Phone. When they wiped all the code, and started out with a brand new kernel, the decision was made to limit SoC support to ensure platform stability.
And that there is the kicker about mobile development. Every single new platform is a whole new adventure when it comes to software stability. Because so much changes when platforms iterate, you have a lot of drivers that need to be written.
Traditionally on PC we've only had a handful of chipset manufacturers, and the field has shrunk considerably. But in the late 90s I remember certain VIA AMD chipsets having known stability issues (a large part of the reason why AMD went to making all their own chipsets and not relying on 3rd parties anymore), and more recently even Intel has not been immune to bugs in their chipset drivers.
Now that the mobile field has consolidated to just a few chipset vendors (although this is changing with a flood of Chinese chipsets finally reaching awareness amongst western companies) that iterate on a good schedule, well at least phones don't just randomly reboot.
GPU drivers are still crap though, I'm not sure if the Windows Phone team still writes their own, but they sure as heck did for WinPhone7, there've been multiple posts on HN about Smartphone GPU driver bugs, I wish someone would test out WinPhone for those same issues! :)
tl;dr Aging embedded OS kernels don't behave well when scaled to 15x what they were intended to do. Just when WinCE started to get really good (involving a complete kernel rewrite) it was de-emphasized by the company.
- The WinCE driver model was pretty hopeless; you could write a simple interrupt handler, but a thread was supposed to do most of the work. There was a ton of context switching involved in any I/O, and the drivers tended to have many useless layers of abstraction, which was probably half architectural and half bad practices followed by the CE culture. (We managed to get about 8 Mbits/second of bulk traffic through USB on WinCE, using 100% of the CPU of our 800Mhz ARM, while a later bare-bones embedded system with a gutted but more functional version of the same driver got 40 Mbits/second with about 5% CPU).
- You could choose what features to build in (this was really baroque and complicated, to say the least). I remember getting WinCE down to 6MB, and this got you an empty app with some drivers. It took 45+ minutes to build (we never got incremental builds working reliably), maybe 20-30 seconds to boot, and did nothing. For 6MB. Yike.
- The BSP (Board Support Package) drivers from vendors were miseries. We found so many bugs in them that we just gave up and wrote our own, which wound up being smaller and way more reliable. Our feedback to the BSP folks was usually ignored (I'm hedging "usually" because I don't know a single case of a bug we reported ever being fixed).
Our decision (inside of MS!) to punt WinCE 6 and do our own thing was one of the best we ever made. It was politically rocky for a while, but if we hadn't done it, we would not have shipped.
> - You could choose what features to build in (this was really baroque and complicated, to say the least). I remember getting WinCE down to 6MB, and this got you an empty app with some drivers. It took 45+ minutes to build (we never got incremental builds working reliably), maybe 20-30 seconds to boot, and did nothing. For 6MB. Yike.
Platform Builder wasn't nice. With full interal source access there were esoteric sets of build parameters that worked much better.
That said, the 6MB image got you a complete OS Kernel and Runtime, as well as the full working C Run time, and also a remoting system that allowed for debugging from halfway across the campus.
Not saying you cannot do better with less, but the OS image scaled pretty far down all things considered.
> The BSP (Board Support Package) drivers from vendors were miseries. We found so many bugs in them that we just gave up and wrote our own, which wound up being smaller and way more reliable. Our feedback to the BSP folks was usually ignored (I'm hedging "usually" because I don't know a single case of a bug we reported ever being fixed).
Many of the BSPs were bad. :(
I don't know much about the driver model, I never touched it!
> Our decision (inside of MS!) to punt WinCE 6 and do our own thing was one of the best we ever made. It was politically rocky for a while, but if we hadn't done it, we would not have shipped.
From an application developers point of view working with WinCE (and the automotive variants) was absolutely no pleasant experience.
When you want to implement entertainment stuff you want to reuse software and have it running on CE as well as your development platform. However the the compiler and library support is very limited. Don't even discuss about C++11 - you don't even get a normal standard template library :(
Even for all windows APIs you first have to look up if they are also supported for CE. Then there are kernel features that are so different that you also need extra code for it. E.g. normal Windows supports IOCP, CE does not and Linux does it completely different.
Maybe it's different when you build applications that only target CE. But when you want to have code-sharing between embedded target and normal PCs then working with embedded linux is here a much more pleasent experience where you can run the same code on the target and have state-of-the-art tooling.
Sadly, a lot of CE stuff was deemphasized years ago.
> However the the compiler and library support is very limited. Don't even discuss about C++11
Back when I was on the compiler team, it was a bit before the revitalization of Native had happened at MS, so there wasn't the huge push that there is now. I am sad to hear that CE never got the same compiler love that Windows on ARM got. (All that happened well after I had left.)
> Maybe it's different when you build applications that only target CE. But when you want to have code-sharing between embedded target and normal PCs then working with embedded linux is here a much more pleasent experience where you can run the same code on the target and have state-of-the-art tooling.
Back in the glory days, you did have the same tooling, for anything non-kernel related you got VS support! (If you were doing kernel work you instead dealt with Platform Builder.)
One advantage of One Core at Microsoft is that everyone gets the same tooling now. There was an entire team who had to support a debugging platform for WinCE, but Visual Studio at the time (and to a much lesser extent now) was not designed to support plugging in new debugging frameworks. Thankfully it is now /possible/, back then it required that the WinCE team fork all of VS!
Suffice to say this was a huge headache and it was responsible for a large part of why WinCE's dev story was so unpleasant.
Yes, it was killed a few years ago. But it lasted way too long, and did untold amounts of damage to Microsoft's ability to execute in mobile. They spent a lot of time recovering from many bad decisions, mostly politically driven nonsense having nothing to do with making CE any good.