For quite some time now there have been rumours about Windows Phone 8 (WP8) being based on the Windows NT kernel (WinNTk). More recently a blogger called MS Nerd made the case that this is not true. Well, I’m going to add fuel to the fire and make the case that Windows Phone 8 can and should be based on the Windows NT kernel.
The first thing that we need to get out-of-the-way is the difference between saying WP8 will be based on Windows 8 (Win8) and saying it will be based on WinNTk. Saying WP8 is based on Win8 implies that it would bring along the Win8 user experience and legacy support. Microsoft has indicated that it wants the phone experience to stay optimized for phones, so the Win8 user experience is not going to make its way there anytime soon. But this has nothing to do with whether or not Windows Phone continues to use the Windows CE kernel or makes the switch to WinNTk. The kernel is focused on things like process structure, memory management, scheduling, device drivers, etc. It has little to do with the user experience. So when the rumors are circulating about WP8, Win8, and WinNTk it is important to keep in mind that the likely scenario is WP8 on WinNTk.
So why should Microsoft switch kernels? There are both technical reasons and practical reasons for the switch, and in the long-term doing so has one awesome benefit that I’ll save for the end. One important point is that when you do the same things twice it is almost impossible to have them both be completed at approximately the same time, be truly compatible with one another, and be of equivalent quality. Second is that the cost of staffing to repeatedly do the same thing twice is outrageous, even for a company the size of Microsoft. And third, the closer you get to wanting two things to be almost the same the less the justification for having two different things!
The history of Windows CE (and Windows Mobile) is that teams around Microsoft build things for the Windows NT-based operating systems and then either they or the Windows CE team itself takes that code and ports it (or hacks it into a subset) for the CE environment. This is done with small numbers of people, and the results are often left to languish a number of versions behind the mainstream product. Take the Common Language Runtime (CLR) as an example. The .NET Compact Framework (CF) was spun off from the original CLR a long time ago. It eventually was left in maintenance mode with just a small team in Microsoft’s India Development Center (IDC) handling bug fixing and minor tweaks. Issues, such as a garbage collection algorithm that was tuned for very small memory footprints and caused applications with large memory footprints to stall, were never intended to be addressed. However, once Windows Phone 7 came along Microsoft found itself having to try to recreate many of the optimizations it already had done for the full CLR in the Compact Framework. It had to add resources, and more senior resources at that, to the team. And that wasn’t to get new functionality, it was just to make CF perform closer to what the full CLR already was capable of. More on this story in a moment.
The Windows CE kernel itself has also been lacking many modern OS features such as SMP. While the latest version of Windows CE added SMP support, those who have been involved in operating system development for quite some time know that it takes multiple versions to really get this tuned up and running well. I’ve seen this on operating systems from TOPS-10 to VMS to Unix to Windows NT to Linux and a few others. Also no doubt the Windows CE SMP support was optimized for dual-core situations, but we know that multi-core (already the norm on x86) is coming to the ARM world too. WinNTk already has the most well tuned SMP support of any operating system kernel, and the resources and time required to bring Windows CE up to snuff (and keep it there) is high.
The same is true here in many other areas. Think about all the security work that has gone into WinNTk. Windows CE is designed for embedded systems that allow for a tightly controlled environment, and although they have added security features in recent releases a lot of work will be required to continue to track evolving requirements for general purpose devices such as Phones. Sure it can be done, but at what cost in resources to Microsoft?
You see Windows Phone without full drive encryption, a problem for enterprises, even though Windows has Bitlocker. Is the full-drive encryption you want on your Phone sufficiently different from the full-drive encryption you want on your Tablet to justify two different implementations? I don’t think so. You see Windows Phone without support for document encryption/decryption, even though Windows has RMS. You might want the management benefits of being able to join a domain. Sure these are possible to add to a Windows CE-based Windows Phone, but that takes resources and time. If Windows Phone were based on WinNTk this would take a lot fewer resources and a lot less time.
I bring up these resource issues both because its been obvious over the years that resources allocated to CE have been far lower than those allocated to Windows, but also because Microsoft has made dramatic personnel cuts in traditional businesses since 2008 and continues to look for ways to cut costs. Funding Windows CE development to support specific low-memory embedded scenarios makes sense. Increasing the funding for it to chase Windows in the general purpose OS market does not.
Now let’s go back to the .NET Compact Framework. When the Windows Phone 7 effort began we realized that CF was going to require a lot of work to make it meet their requirements. Garbage Collection was going to need significant rework, and performance work was needed across the board. At the same time Microsoft Research had a prototype of the full CLR ported to ARM and we were urged to use that for Windows Phone 7 rather than increase the investment in CF. Our analysis (and that of the CLR’s architect) was that there wasn’t enough time to meet Windows Phone 7’s aggressive schedule with a full CLR port (i.e., productization of MSR’s work plus a port to Windows CE) and so we added resources to the CF team and went to work on Windows Phone 7’s requirements. Windows Phone 7.5 continued with improvements in CF garbage collection, improvements that would not have been necessary with the full CLR since it has had them for years. At the same time Microsoft’s layoffs were taking hold, and Developer Division was hit hard. So now you have a much smaller organization devoting a larger percentage of its resources to doing little but duplicating work that it had done years earlier. It makes no sense. Porting the full CLR to Windows CE wouldn’t maximize the resource savings because you’d still need a porting team. However, if you had a Windows Phone 8 based on WinNTk you get full CLR for free. The .NET CF investment can shrink to cover maintenance. Lets take the new WInRT introduced in Windows 8. Does Microsoft really want to invest in porting the WinRT to Windows CE, and maintaining that port, when switching to WinNTk would allow WP8 to have WinRT at little or no cost?
Now let me go into two things missing from Windows Phone that will hopefully be addressed in WP8. The first is dual-core support. Yes Windows CE added dual-core (SMP) support, but apparently not before Windows Phone 7 took a snapshot. So why didn’t Microsoft just upgrade to the newer CE kernel for its Mango release? I can think of three reasons. One is that the dual-core support in CE just wasn’t up to snuff and so the Windows Phone team decided they weren’t going to introduce something that was non-competitive with IOS or Android. Another is that the kernel upgrade was too disruptive (which is why major kernel changes usually cause things at Microsoft to be labeled “.0” releases) relative to the benefits that would have been accrued. But I believe the most likely reason was that what was the point of putting a lot of effort into supporting a newer Windows CE kernel when you were already putting that effort into a WinNTk port?
Perhaps the biggest overall complaint about Windows Phone, starting with Windows Phone 7 and continuing through NoDo and Mango, is the lack of 3rd-party native mode application support. Originally some of this was schedule (for the first Windows Phone 7 release) and some of it was philosophical (the phone could be made more reliable by just having managed applications). But some of it, and I think the continuing reason, is that no one wants to embed Windows CE’s idiosyncracies in new apps. Again some of that is reliability (e.g., scenarios where a native mode application’s shared memory is not freed when the process is killed) and some is a desire to make apps portable across the three-screens (PC, Phone, TV) and a cloud world. Moving to WinNTk eliminates the CE idiosyncrasy problem and makes native mode applications (and particularly WinRT-based ones) more of a no-brainer.
I think that lays out most of the case of why Windows Phone should move away from Windows CE to the Windows NT kernel. So let me address a key objection to the move, “size”. Windows CE has a reputation for being small and modular, Windows has a reputation for being big and bloated. But Windows itself is about 6 years into an effort to completely restructure and clean up the code base, its resource requirements have actually shrunk over the last two releases (Win7 and Win8), and Windows 8 is very much focused on the low power/constrained resources environment that characterize both tablet and phone devices. Indeed I am running the Windows 8 developer preview on a tablet that is less powerful and has no more memory than the current generation of smartphones and even at this early stage it is as responsive as those devices. In some regards, such as boot time, it is actually faster! So could a WinNTk-based Windows Phone 8 run well on a 1Ghz CPU with 512MB of RAM? Of course it could. What about 800Mhz? Almost certainly. 256MB? Well, now I start to wonder. It is pretty clear that Microsoft is focusing on enabling low-cost smartphones from Nokia and others as a key part of its strategy. The question is, what does a low-cost smartphone’s specs look like in the fall of 2012? And how big a target is RAM for cost reduction? And how much savings can you really get using Windows CE over WinNTk.
The two biggest cost areas on a smartphone bill-of-materials is are the logic complex (processor, GPU, radio) and the screen. Memory is the third largest, but is composed of both RAM and FLASH memory so those represent two different discussions from a kernel decision standpoint. Mechanical aspects (packaging, buttons) are fourth, and cameras are fifth. Moore’s Law allows for two things to occur over time, either increased performance at constant cost or constant performance at lower cost. High-end smartphones absorb the electronics following the increased performance at constant cost track. Low-end smartphones can either try to go for reduced specs, purely follow the constant performance/lower cost track, or a mixture of both. The most likely path is to follow the constant performance/lower cost track on pure electronics and go for reduced specs in areas that don’t fully benefit from Moore’s Law. So, for example, stick to the 1Ghz processor/512MB RAM that is characteristic of first generation Windows Phone 7 devices because this will be dirt cheap in late 2012 but use cheaper materials in packaging and really focus on reducing display costs. The latter might occur from lower-quality displays, different resolutions, or both. A different resolution is the change that would require the most work in Windows Phone and is completely orthogonal to the Windows CE vs WinNTk decision. I would also expect cameras to either be eliminated or very low-cost/low-resolution. And some sensors (e.g., gyroscope) avoided. But the main point here is that spec changes that would make adoption of WinNTk undesirable are very unlikely.
Ok, so I think that is about it. Oh, there is one more thing! You might know about the Motorola Atrix. It’s an Android Smartphone that you can plug into a PC-like notebook body and it becomes an Android PC. It isn’t very interesting because of course no one really wants an Android PC (e.g., no apps for it) and so had little success. Someone else made an Android smartphone that plugs into a tablet body and turns your phone into a tablet. But without real support from Google for this it seems to have gone nowhere. Well, at least as early as 2006 Microsoft envisioned that you would carry around a phone that morphed into a full PC when attached to PC peripherals (large screen, keyboard, mouse). It just didn’t have the ducks lined up to pull it off (unless you wanted a dock that converted your Windows Mobile phone to a Windows CE PC, which a third-party did indeed create, and have about as much luck with as the Atrix). The move to WinNTk is a prerequisite for ever bringing this vision to reality. If you have the common kernel then you could have high-end smartphones that shipped with both the Windows 8+ user experience and Windows Phone 8+ user experiences and swap between them based on what peripherals were available. Maybe this is a “Windows 9” thing, or maybe it is a “Windows 10” thing, but the point is that going to a common kernel clears the path for a lot of innovative possibilities. Sticking with two different kernels will always make these scenarios difficult or impractical.
So I think I’ve laid out the case for Windows Phone 8 to be based on the Windows NT kernel. There is lots of upside and very little downside for Microsoft. Will it happen? I really don’t know. There are definitely a lot of Microsoft people, both current and former, who want it to happen. I could point out that a chunk of the WinNTk team moved over to the Windows Phone organization a couple of years ago, and while that proves nothing it certainly shows that the expertise to pull off the kernel switch is in place. If this is going to happen we shouldn’t have long to wait to find out. For Windows Phone 8 to release in 2012 Microsoft would need to hold a developers conference for it (e.g., Mix12) this coming spring. So we are likely within 4 or 5 months of knowing the answer.