How does Windows Embedded CE 6.0 Start? one, understand, comparison, structured

Operating system code, as one of my colleague developers recently realized, is "just code". It's not voodoo and it does not exist on a higher plane of knowledge. In fact, an operating system kernel is usually remarkably well structured and well designed in comparison to other pieces of software. When you think about it, it has to be. More than one person needs to understand and maintain a core set of code that must work and must support debugging of all other software that runs upon it. People move on, and change jobs to look for new challenges to keep learning. If only one person understood the way an operating system worked, then there is a huge amount of risk.
One of the most interesting facets to Operating Systems that I've followed in my career is how they start. Initialization is the last step in design, but at the same time it uncovers the most fundamental bedrock of the principles used. You start with literally nothing but a CPU which can execute instructions (sometimes not even with memory to use), and must take a platform from that point to a fully functioning system - one that not only utilizes available hardware, but abstracts it to a common understanding.
What I'm going to do in this article is discuss the details of how the Windows CE 6.0 kernel starts, and the association of the 'Microsoft' kernel code with the code that comes from an Original Equipment Manufacturer (OEM). It is hoped that by relating this understanding more people will have a better idea of the 'hows' and 'whys' of the Microsoft design.
To start, let's quickly review how the operating system software is built. The Microsoft tool chain emits .EXE and/or .DLL program files. Files of both these types of extension are "Portable Executable" format, or "PE" format. They are practically identical in every aspect:

• They are extended Common Object File Format (COFF) format files
  
• They have import tables and export tables (EXE export tables are usually blank)
  
• They have an entry point defined in their headers for where execution should start
  

There is nothing extraordinary about the operating system kernel program - it is compiled using the standard compiler and with a minimal set of definitions for that compiler. An EXE file is produced (called NK.EXE). It does not link to any external library or DLL - it can't. When this code starts there is nothing in the system, or even a system for that matter. Since the EXE is in a known format (PE COFF), you can determine the entry point from looking at the EXE header. This means we know where to set the CPU's instruction pointer to so that the program can start.
One additional property is that a PE file can be arranged so that it may "execute in place". This means that if the file data is placed at a particular virtual address, no changes need to be made to the program code in the file in order for it to address other code and data at the correct addresses. For example, I can tell the Microsoft linker program to place the kernel program file at the virtual address 0x80000000. Then references to code (function entry points) will be placed in the EXE file such that other code can jump to them by address. If function foo() is at address 0x80001000 and inside its body it calls a function bar() which sits at address 0x80005000, there will be an instruction stored directly in the program code for 'foo()' that calls to 0x80005000. The dotted lines are just the delineation of function code start or end.