4 ms·

From an application developers point of view working with WinCE (and the automotive variants) was absolutely no pleasant experience. When you want to implement

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.

com2kid 12y ago
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.

com2kid 12y ago

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.