To answer this question, it might be better to say what the .NET Micro Framework is not: the .NET Micro Framework is not a traditional operating system with a managed code runtime (or virtual machine) layered on top. Instead, the SPOT team took the approach of coalescing the traditional functionality of an operating system-resource management, execution control, input/ output (I/O)-with the traditional functionality of a runtime, which, not surprisingly, involves resource management, execution control, and I/O. What resulted was a bootable runtime. A basic architectural overview in Figure 1-2 shows the components that make up the runtime.
Figure 1-2: The basic architecture for .NET Micro Framework.
The .NET Micro Framework provides a subset of full operating system features, so it does not require an operating system, and as explained earlier, is referred to as a bootable runtime. Making the runtime bootable means that bootstrap support, interrupt handling, threading and process management, heap management, and other environmental support functions that are typically provided by the operating system have been added to the .NET Micro Framework so that it can run directly on hardware. Runtimes such as the .NET Framework run on top of a general and fully featured operating system and utilize the support of that operating system but provide a more protected, and in some cases constrained, application development environment. The operating system services that are needed by the application are provided up through the runtime and Framework Libraries. In creating a bootable runtime, the .NET Micro Framework provides a subset of the full operating system features directly to the application, rather than relying on some underlying operating system. (Internally, we refer to this level of system abstraction as the Platform Adaptation Layer, or PAL.) This means that in place of a full (traditional) operating system, the .NET Micro Framework runs on top of an optimized, small footprint (20–30K of core) hardware abstraction layer (HAL). The services provided by the .NET Micro Framework are a subset of what would typically be provided by a fully generalized operating system (such as Windows CE or Windows XP Embedded), with this subset being selected by Microsoft in order to provide most services that are required to build and run embedded applications on such small devices. Of course, you are always free to build, share, or reuse class libraries from the development community that have been built on top of the .NET Micro Framework.
The core of this platform is the .NET Micro Framework common language runtime (CLR); a small, optimized managed code runtime based on industry-standard European Computer Manufacturers Association (ECMA) specifications. Every incarnation of .NET includes its own tailored runtime implementation. This implementation is a requisite part of fulfilling the standards, whether the effort is to target the full server edition or desktop CLR, or it is the version of the CLR that ships with Windows CE, or it is provided by third parties such as Mono.
Managed code is different from native code because it runs within the context of the CLR, which provides an environment where the execution is safe from common execution errors and the code executes against a virtual machine abstraction, thus insulating the developer from the intricate details of a particular machine architecture. When native code executes, the operating system really doesn't know anything about the code and therefore can execute it only blindly. Managed code includes a great deal of information about the code so that the CLR can prevent errors. 
By supporting managed code, the .NET Micro Framework CLR allows for rapid development and safe execution of application code using modern programming languages and tools, namely C# and Visual Studio .NET, allowing development teams to more effectively focus their resources on delivering customer value.
The .NET Micro Framework CLR serves the same purpose as its larger cousins (.NET Framework and .NET Compact Framework): to load and execute managed code. The benefits of managed code are many, but the main advantage is that the runtime environment can provide safety-for example, security, protected resources, validation, recovery, and isolation. Through the Base Class Library (BCL) and language features, developers become more productive by not having to worry about infrastructure issues, as is typical in native code development.
The .NET Micro Framework CLR brings these desirable characteristics to resource-constrained embedded devices. The key implementation distinctions can be found in the design goals of the .NET Micro Framework CLR:
Minimize software footprint
Run without a traditional operating system by integrating functionality directly into the runtime engine
Have selective inclusion of runtime and library functionality appropriate to application/ device
Be executable from ROM or flash memory
Optimize for energy efficiency (that is, for battery-powered devices)
There are two potential approaches to implementing the Micro Framework on a specific hardware platform. The platform can be ported to an existing operating system and function as a normal run time. Alternatively, the platform includes a Platform Adaptation Layer (PAL) and a HAL that support the runtime directly on the hardware. Deciding which approach is appropriate depends entirely on the specifics of the application. The PAL and HAL provide two layers at which the integration of the platform can be made. The PAL supports higher-level integration, including asynchronous communication calls, high-level timers, and list and data structures. The PAL is implemented on the HAL, which supports all the low-level interfaces and works directly with the hardware. The HAL provides generic access to all peripherals and drivers. Drivers are common across all platforms and operate through opaque queued I/O. This design shields the driver from interrupt service routine (ISR) and queue-locking details.
The porting process requires changes at primarily the HAL level to either adapt the drivers to new hardware or implement the equivalent support through the underlying operating system. The Porting Kit includes the HAL and PAL source for a default reference platform. Currently, the platform is built using the ARM toolset (versions 1.2 and 3.0 are supported) with support for ARM7 and ARM9 as well as Win32 through simulated drives for the emulation story.
When no underlying operating system is present, the .NET Micro Framework HAL provides the necessary infrastructure for booting and interfacing with the hardware and peripherals. The functionality of a traditional operating system has been factored between the .NET Micro Framework HAL and CLR, forming what could be considered an embedded operating system. The .NET Micro Framework HAL provides the critical interface to hardware (IRQs, timers, I/O), but does not have a full kernel to manage processes and threads or any heaps of its own; it defers these functions to the .NET Micro Framework CLR.
The .NET Micro Framework HAL kernel supports two execution modes: single-threaded application and ISR. Each has its own set of unique rules that must be followed.
There is no traditional kernel mode thread scheduler to speak of because, in the .NET Micro Framework environment, there is only ever a single application thread (that is, the application, from the HAL's perspective, is the .NET Micro Framework CLR). Your applications, however, will never know the difference and are free to have many threads. The .NET Micro Framework CLR provides a fully multithreaded scheduler for all of your application-level facilities (such as your user interface "shell," network protocols, alerting mechanisms, I/O processing, and games), making it appear as if you were running within a traditional .NET environment. Internally, having a single application thread also removes locking overhead (that is, the runtime and HAL objects do not worry about traditional concurrency issues requiring critical sections, mutexes, and the like). However, this means that the application running on .NET Micro Framework's HAL (the .NET Micro Framework CLR itself) must explicitly yield execution periodically (idle time) in order for continuations to be processed (cooperative multitasking).
Another key design decision relates to the expectation of low CPU utilization to reduce power consumption. This has resulted in simpler code, lower power consumption, deferred service routines (DSR) versus "do it now" versus "sleep in place" approaches, reducing clock speed while doing short spins, and other tricks.
The majority of functionality that a developer has access to in any of the managed runtimes comes from Framework Libraries. The approach taken by both the Compact Framework and the .NET Micro Framework is that of selective subsetting of the desktop/server Framework Libraries and providing domain-specific extensions. Where possible, the entire functionality of the BCL is maintained intact. If there is significant deviation, the functionality is moved to a new namespace. Figure 1-3 illustrates the key differences among the various .NET Framework Libraries in their support for the major feature areas.
Figure 1-3: Framework Library support provided by the .NET Micro Framework.
Extensive support has been provided for developing user interfaces for these small devices, which has traditionally been a nontrivial and unpleasant undertaking. This support includes input (buttons), layout (content-sizing, text flow, controls), fonts, images (bitmaps, GIFs), pens, brushes, colors, drawing primitives (such as rectangles and circles), window management, and popups/alerts, all following a familiar and easy-to-use .NET model. Examples can be seen in Figure 1-4.
Figure 1-4: Sample UI produced by the .NET Micro Framework.
The application model loosely follows that of the Windows Presentation Foundation (WPF), the model used by Windows Vista and .NET 3.0, though without the declarative markup features (eXtensible Application Markup Language, or XAML). This means that developers familiar with applications development in Windows Vista will be comfortable writing UIs for applications running on these small, .NET Micro Framework devices.
One of the key features of this UI model is the layout system, which refers to the protocol and associated classes that enable sizes and positions to be allotted for user interface elements to render in. This has been particularly challenging in the past for pixel-oriented displays (such as LCDs) and differs from Windows Vista's dots-per-inch (dpi) model. As with everything else in the .NET Micro Framework, the platform is optimized for embedded devices and the needs of embedded developers.
The primary architectural difference between the .NET Micro Framework model and its bigger cousins is the lack of division between so-called core operating system services (that functionality which is provided by the "underlying system") and so-called "Framework" services (oftentimes just managed code wrappers for the core services). There are two main reasons for this distinction:
Size and performance: by adding additional layers, the cost to run on the small form factors becomes excessive.
Due to the smaller form factors and the tying to a device release, the interoperability and lifetime/upgrade scenarios for software built on this stack are greatly reduced.
The layout system adds support for user-specified sizing, positioning, margins, and so on, of specific layout elements. The primary focus of this system has been the following:
Size to content To allow controls to size themselves, according to the content they present, dynamically at run time (as opposed to statically at authoring time)
Universal properties To allow developers to programmatically control the behavior and appearance of layout elements in a consistent, intuitive, and succinct manner
Globalization support To allow products developed for different languages and cultures to easily be adapted without programming overhead
Multiple device support To allow products with different display capabilities to share a common mechanism, reducing development time and complexity
In short, the user interface capabilities of the .NET Micro Framework are extensive and have been well thought out. Several large-scale projects have been built using the capabilities provided here. Later chapters will fully explore these capabilities to show you how to build your own optimized user interfaces, either directly or using the Windows Vista SideShow shell (itself built upon these facilities).
Development for the .NET Micro Framework platform is done using Visual Studio. This integration supports full emulation of your device on the PC, building and deploying the assemblies to the device, and debugging the code running on the device through USB or serial connections. Initial development can be done on the PC through an emulation/ simulation environment that is provided as part of the SDK, which allows you, the application developers, to write much of your code without worrying about the hardware details of the device. This emulation environment, shown in Figure 1-5, is designed to be extensible so that any device that you are using in your project can be emulated on the PC, allowing you to write all the interface and application logic code that is necessary. Development at this level offers extensive utilities, such as logging, heap analyzers, and profilers, to assist you in understanding and gaining insight into the resource utilization and performance of your (managed) code as it is interpreted by the .NET Micro Framework runtime.
Figure 1-5: Extensible emulation in Visual Studio 2005.
Although PC emulation has lots of advantages, it is not a perfect substitute for running the code on the device. So, we have extended the project system of Visual Studio 2005 to specifically target development on these devices, including flashing and interactive code-level debugging. Using a serial or USB connection, the remote procedure call (RPC) subsystem provides a live communication channel to the device, allowing the downloading of the application to the device within Visual Studio, runtime variable inspection, breakpoints, and all the expected features found in visual debugging. For example, if you have a device that communicates with the PC over Bluetooth, you could be debugging both sides of the communications in that same session of Visual Studio, stepping through code running on the PC and then following breakpoints right into code running on the device.
When it is time for you to move your code to the target device, the assemblies (binaries) generated by Visual Studio for each of your libraries and for the main application are not usable directly. A post-processing step is performed from within Visual Studio, the so-called Metadata Processor, which converts the standard .NET assembly into the format required by the .NET Micro Framework CLR. This post-processing further reduces the size of the assemblies. This step is fully automated in the Visual Studio integration and occurs as a seamless part of deploying the assemblies to the device. In Chapter 9, "Developing with the Emulator," you will learn how to customize every aspect of emulation and deployment for your project. Figure 1-6 illustrates the typical development cycle.
Figure 1-6: Build, deploy, and debug on the target device from Visual Studio 2005.
The .NET Micro Framework has the following system requirements.
Currently the .NET Micro Framework runs on several ARM7 and ARM9 processors. The suggested minimal memory configurations at present are 300 KB RAM and 1 MB of Flash. The devices also must have serial or USB ports to support downloading and debugging the applications during development. At the time of this writing, a number of products are available to use for development, including the following:
Porting independent software vendors (ISVs)
Chapter 11, "From Prototype to Product: Case Studies," will dive into the details of several of these efforts to give you an idea for how real-world products get built using the .NET Micro Framework.
The development environment requires Visual Studio 2005 to support full integration with the devices. The .NET Micro Framework SDK installs several add-ins to Visual Studio and fails unless Visual Studio is already present. These add-ins support on-device debugging. In addition, project templates are installed for .NET Micro Framework projects. A serial or USB connection between the PC and the device is also required.
This is a high-level description of managed code. There are a number of other differences such as the use of a common Microsoft intermediate language (MSIL) as well as the language differences found in C# and other managed code languages.