CE 6 PQOAL

As I mentioned earlier, one of the design goals with the new kernel was to increase the robustness of the kernel. As you probably know, the kernel makes use of various hardware specific services to operate such as memory cache, hardware interrupts etc. With CE 5 something called the "Production Quality OEM Adaption Layer", PQOAL, a common framework for providing these functions was introduced in an effort to formalize the architecture for how the kernel interfaces these hardware specific functions. The OAL is linked with the generic kernel code to form the full kernel module. While Microsoft encouraged developers to adhere to PQOAL it was not a requirement to use it. In CE 5 PQOAL, the kernel is basically monolithic, so to utilize the different levels of debug and profiling support available in the kerne, the kernel comes in three flavours:

• "kern.exe": OAL + Kernel
• "kernkitl.exe": OAL + Kernel + KITL
• "kernkitlprof.exe": OAL + Kernel + KITL + Profiler

In CE6 PQOAL the kernel has instead been split into three main components:

• "oal.exe"
• "kernel.dll"
• "kitl.dll"

This split effectively separates the OAL specifics and development/debug specifics from the rest of the kernel. Also, with CE6, the kernel profiling feature no longer needs a specially instrumented version of the kernel, you can profile anyway. Using the PQOAL in CE 6 is still just a recommendation by Microsoft, but I think most device manufacturers will find it is a good idea to take the step and adapt to the PQOAL when porting their old designs to CE6.

By splitting up the OAL from the generic parts two interesting things happen. First, the foundation for a well defined interface between the OAL and the kernel module is laid. It is no longer possible to just "extern" some kernel specific function in the OAL, as in the old monolithic architecture where the OEM sometimes use undocumented kernel functions to "backdoor" its way around some OAL "quirks" -something that may affect stability and compatibility of the kernel. In CE 6, the kernel functions are exported to the "oal.exe" as a function table (NKGLOBAL) as part of an initial handshake procedure. In the same way, OAL functions that are needed to support the core kernel are exported to "kern.dll" in a similar function table (OEMGLOBAL).

The second benefit in splitting the kernel into separate modules is that by keeping the generic kernel parts in one module paves way for a slightly better kernel update path. Now, updates and fixes to the core kernel can be distributed directly to the OEM:s as pre-built libs, thoroughly tested by MS.

Separating KITL from the kernel also has a number of advantages such as improved debug zone support for the OAL and KITL. However, the probably most exciting advantage -to be able to dynamically load KITL support- is not yet implemented. The basic structure is there, but "on-demand KITL" will probably not be available in CE6 when it retails. Hopefully it will be wedged in to a future update of the OS. Fingers crossed!