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.
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.