Re: Windows CE != Windows Mobile
Sorry, as a former insider, I must (as Bernie Sanders is fond of saying), respectfully disagree.
Point 1: Saying that WinMo is the same as WinCE is like saying Windows Server Edition is the same as XBox (or, more appropriately, that RedHat is the same as Debian). Yes, at some point, the kernels go back to a common branch. Yes, many of the system services share common versions. But the API sets were different (for example, from CE4 on, you could use .NET Compact on both, but until Embedded Compact 7 and Windows Phone 8, you could not use full-on .NET on any of the compact Windows variants). Talk to someone who spent years building code for these platforms. They'll tell you, for example, that in general .NET Compact was cr*p and bore only passing resemblance to full-on .NET. Don't let the monikers fool you - they were NOT the same code. Compact was mostly written in India, in an attempt to make something that looked like full .NET but would run in smaller environments. It did not succeed well, and that's one of the reasons why most old-school CE builders tended to stick to native code for a lot of their work (Win32 remained about 85% the same on all the platforms where it existed).
I used to work with the WinMo team on and off for about 3 years, as a contractor SDE. Part of that time, I worked with the build and config management teams. I took branches that were dropped from CE (and originally, from Windows NT Kernel group) and prepared them for use by both the WinMo and Automotive teams and drop them for the build team. The branches diverged considerably from their progenitors.
Point 2: Your version number sequence is off. There were MANY versions of what, for lack of a better bucket, I call the "Compact Versions" (and the children - Auto, Mobile and Handheld). Every time there was a new CE kernel or mainline build, we would snap the tree for modification and dissemination to the SDEs in Embedded, WinMo and Auto -- until WinMo 6. A nice view of the first 10+ years of the Compact Editions timeline is on Wikipedia - it's pretty much correct. Sorry, but you all must look it up yourselves - InfoWeek won't let me put the URL in my post anymore [thanks for nothing, spammers!]. Just search for Windows CE.
And no, I'm not talking about Pink. Pink was an orphan child from the beginning (beKinning?). It first ran Java and then a forked branch of CE 4. Cloud-based system, way ahead of it's time. Very cool idea, ugly implementation (destroyed by inter-group politics, mostly).
With WinMo 6, MSFT management realized that the cellular market was on the ascendant. It was decided that a new release needed to be done; but CE wasn't ready to release yet, so the branch was forked and WinMo 6 was developed on its own special fork (including some kernel changes, with the reluctant blessing of the Kernel Team). This proved to be a problem later, when CE 6 was merged back into the main WinMo line, just prior to WinMo 6.5 (also known as the last WinMo release). Quite a bit of time was wasted while the two lines were merged. I consider it the biggest headache I have ever had to face, in a config mgmt. role.
WP7 was again based on the CE 7 kernel, with, as you say, a borrowed UE (from a hybrid of Xbox and Zune). You had to build apps in Silverlight paradigm; it was not popular because all the former WinMo ISVs were being asked to re-write their apps from ground-zero.
Windows Phone 8+ was a big deal, because they decided to go back to the root Kernel line that was the progenitor of all of these (Windows, XBox and Compact). It was also a big deal, because it allowed the return of native-mode code. That was important because a lot of ISVs had bailed on Windows Phone, due to the fact that one was forced to use Silverlight as the UE. Yuck.
But Win10 is an even bigger deal. Finally, for once and all, Microsoft has figured out how to consolidate all the Windows lineages under one roof. Part of this is because, at last, the Windows team is in charge of ALL Windows releases on any platform - it's amazing what you can accomplish if you're all actually on the same team. Especially at MSFT, where inter-team rivalry is legendary.
And, before anyone starts, NO, I'm NOT talking about ABIs. I just assumed that everyone knew that ARM, x86, Itanium, MIPS etc. do not use the same binaries. When I say "codebase", I'm not talking about the binary, I'm talking about COMMON SOURCE TREES, compiled with the same VERSION of the same COMPILER. I'm also talking COMMON APIs (again, at the same REV LEVEL). If all of Windows-land can use 95%+ the same version of the same APIs (and, by extension, UEs) and just recompile for different targets, and if the release cadences are synchronized in similar fashion, that is a huge accomplishment and deserves recognition. Of course, history will tell if they can continue to pull it off - but for now, it should be noted.
As of this writing, Apple can't do it - OSX and iOS are very different animals. Google can't do it - Android != Chrome != Glass (etc.). Even Linux-land can't do it. Take a look at the "make piles" for any commonly-used Linux software - there's a make variant for each platform you build on, and you have to decide if you're going to use GNU compilers or someone else's compiler, and which UE you're targeting, etc. etc. etc. Open source is cool, but it's a lot of work.
Now, that's not to say "they" (the ever-popular "them") :-) won't be able to do this someday. Given that common-platform-portability is the holy grail of config management, I suspect every popular OS and SV will try for this eventually. It's just not possible now.