Overview

Microsoft just generated a huge amount of buzz in the press & developer community when Microsoft’s Paul Thurrott confirmed a leak that Windows Phone 8 (WP8) codename “Apollo” will use Windows 8 kernel.

This is a big deal, bigger than what most people realise, because it means that Microsoft can have a standard integrated development environment (IDE) to target Windows 8 (for Intel x86/64 – Wintel), Windows on Arm (WoA) & WP8 (now a WoA)!

So when a developer wrote an app for Windows 8, he can automatically target both Wintel, WoA & with some tweaks for screen dimension, WP8!

What’s the big deal anyway?

Let’s me start by saying I’ve been a software developer for many years since C++ & Visual Basic 6. Unlike many developers these days, I’m what was called a system programmer, meaning I do low-level, machine interface stuff, including Assembler on embedded systems. I stopped coding professionally 8 years ago but I still do some projects here & there. So I’m aware of the going on in the development of Wintel, WP7 world.

Software is created by writing code in a language not unlike English. In order for the code to be recognised, you need the other party to also speak the same language.

Unfortunately, Intel Core i7 or nVidia Tegra-3 or Qualcomm Snapdragon CPU doesn’t speak English, so you need an intermediary. A translator that converts the code into machine language which is just a bunch of ones & zeros. This is the job of the compiler.

There are 2 ways to accomplish this. You can compile code directly into machine language or you can send your code into a translator that converts these code in realtime into machine language.

The advantage of the first approach is speed. The problem is you need to rewrite (port) code from one platform to another.

The second is the interpreter approach. A middleman will translate the code during software running time into machine code for the CPU to execute, hence the term, “runtime”.

The advantage is the ease of porting code from one platform to another. It still takes efforts & time to customise for the environment but at least there are less mundane chore to do/debug. The major problem is speed because the middleman also uses CPU resource. Multicore CPU mask some of the time but there’s still lag.

SO, where does Windows 8 fit into all these CPU discussion anyway?

Windows 8 is an Operating System. It’s job is to manage resources in CPU, memory, storage, network, graphics, user input, etc. The part that manage the hardware is called the kernel, which is itself a special software. The part that you see on the screen is the GUI, which is also software. All the apps that you use must interact with the kernel & GUI.

IIRC, the kernel of Windows Phone 7 is based on Windows CE, which is itself a branch of Windows 95 or earlier. It’s a very mature & stable kernel but doesn’t support multi-core CPU or pre-emptive multi-threading which is why multi-tasking on PocketPC/Windows Mobile always seem to hang or slow the phone with no way to recover but a soft reset. Surprisingly, Android 2/3 seem to share the same problems! But is mitigated somewhat by having multicore CPU.

Windows Phone 7 bypass this limitation by following Apple’s iOS when it was initially launched. No app is allowed to run in the background, except for a few that strictly follows certain parameters. Task switching was minimum, restricted to 5 open screens, not 5 open apps. This severely limited many enterprise apps which required ongoing background processing.

Now unlike Apple, which keeps its iOS & Mac-OS separately. Microsoft seems to want to consolidate their OS as early as 2003 with the MinWin initiative. Windows 7 is based on the Windows NT kernel, which was super robust but very monolithic in that all the services were integrated into the kernel, making it big & hard to debug or extend. Performance was good though because all the services exist in the same memory space.

The problem was, every time a new service is needed, like IPv6, Microsoft had to change the kernel without affecting other components. The complexity gets too much to handle even for a software house as big as Microsoft. The only way was to compartmentalized the kernel. Performance suffered a bit but can be recovered when developers optimise the individual components that were separated from the kernel.

This initiative culminated in Windows 8 using just 600+MB of memory footprint compared to Windows 7 800+MB in a TabletPC configuration. The kernel itself is only tens of MB! Small enough to fit in the future 256MB of RAM on a Windows Phone 7.5.x upgrade called “Tango”.

For WoA, the memory footprint will probably be similar to Wintel because Windows Desktop will also appear in WoA. However, as mentioned, for any developer who needs speed in their desktop apps like Microsoft Office, they will have to port their code & recompile the entire app to work in WoA Desktop environment. Which is why Microsoft was very secretive about whether legacy Windows Apps can run on WoA. My answer is, No. (Unless MS includes VirtualPC on WoA.)

It’s very clear to me that since Microsoft wrote the compiler in Visual Studio IDE & can port the entire Windows to ARM, it’s no problem for them to port MS Office as well! However, legacy apps compiled for Intel CPU will not work on WoA. Developers need to port their code.

The good news is, the new Visual Studio will probably support compiling to both Intel x86/64 & ARM all in the same IDE! Devs may need to set certain parameters but they do not need to invest in another IDE or train/hire new developers. Visual Studio will handle the differences in platform like it handles the difference in Intel & AMD CPU.

This is excellent news for Enterprise customers because it simplifies managing their business by providing a single platform that can run on Intel PCs in the office & WoA laptops/tablets for their mobile workforce. Intel CPU is much more powerful but ARM CPU uses much less power so having Windows on both platform solves a dilemma that has dogged the industry for more than 10 years. This is the reason why the iPad is so successful because even though Bill Gates envisioned a tablet future, it was Steve Jobs who realised the vision!

However, Steve had to compromise on functionality on the iPad because Mac-OS wasn’t optimised for low-memory/CPU computing. On top of that, Mac-OS was compiled for Intel CPU & it will take them time to find a good compiler to recompile for ARM, plus all the engineering needed to port the OS.

What about WP8?

Most of the 60,000 apps on WP7 are written in Silverlight & XNA. Both are interpreted code which requires a Runtime. This Runtime is also an integral of Windows 8.

Now that we know WP8 Apollo uses the NT kernel, it automatically means that WP8 supports multicore CPU, full pre-emptive multi-threading, multi-GPU & multi-displays on-top of the other regular stuff you find on iPhones & Android phones.

Since Microsoft has to compile Silverlight/XNA to work on WoA & Windows Phone is actually an ARM computer with a small screen, it means that there is NO difference between WoA Silverlight/XNA & Silverlight/XNA on Windows Phone as well! Do I even need to mention Silverlight/XNA is already in Windows 8 for x86/64?

Ultimately, this means that developers can use Visual Studio to compile speedy Native apps like MS Office for Wintel, WoA & WP8. If the situation doesn’t require speed, they can more easily program in Silverlight/XNA & enjoy low power consumption for Wintel, WoA & WP8 as well. The only major work is to change the interface to fit the screen & that’s it!

Conclusion

Microsoft has announced a range of screen size for the next version of Windows 8/WP8 & the reason is very simple.

All Windows machines will share a common interface & work the same. After adjustment for screen size, Silverlight developers can also easily target WP8 & Windows 8.

Native App developers can also easily target Wintel or WoA allowing the new platforms to gain huge number of apps in a short time. Having tons of apps drive adoption which is what ensures the survival of the platform.

I can’t wait! 8)