(Translation of an article that appeared in Bits & Chips 2, 2003)
Introduction
About one year ago Microsoft introduced a new version of Windows CE, the operating system for embedded - and mobile applications. In Bits & Chips number 5, 2002 we already wrote an article about the history of Windows CE and you about our first practical experiments with this new version. Over a year after the release of Windows CE.NET it is possible to use the operating system for .NET application development because of the availability of the .NET Compact Framework. In this article we inform you about specific .NET aspects of Windows CE and we look at the possibilities to combine .NET with existing functionality.
What is .NET?
Prior to talking about .NET in combination with Windows CE, we have to take a look at .NET itself. Today many products of Microsoft carry those three magical characters, preceded by a point. But what actually is .NET? It is not easy to give a uniform answer to that question. Depending on the context .NET has a different meaning for several people. The simplest I can think off is that .NET is a brand name, invented by the marketing department of Microsoft. Important in the .NET philosophy is a client-server model, in which standard IP protocols are used for communication. Data is exchanged by means of XML. XML is frequently used in combination with XML Web Services. The latter is surrounded by magic and hype, but essentially is a possibility for different applications running on different machines to exchange data and execute remote functionality, making use of Internet technology. Please note though that .NET is not limited to web services and Internet technology. It is perfectly possible to develop stand-alone (Windows) applications with the .NET technology.
What is the .NET Framework?
To be able to develop .NET applications it is necessary to use a .NET programming language. Microsoft offers languages like Visual Basic.NET, C#, Managed C++ and J# within the Visual Studio.NET development environment. Besides that, there are over twenty other .NET languages available, varying from Cobol.NET to Delphi for .NET. In contrast to traditional programming languages, .NET languages do not translate source files to machine code for a specific processor, but they translate them to Intermediate Language (IL), a processor independent assembly language. Because all .NET languages translate to IL, cross language development within a single application is very easy to achieve.
Al .NET languages use functionality of the .NET Framework, the infrastructure of the .NET platform. An important component of the .NET Framework is the Common Language Runtime (CLR). The CLR can be considered as a protected environment in which .NET applications are executed. The CLR understands Intermediate Language and translates IL code to processor specific code, ready for execution. This is known as just-in-time compilation (JIT). Furthermore the CLR verifies if applications are allowed to execute certain instructions, for example to dynamically create objects and to remove them again after they have been used (Garbage Collection).
The CLR contains numerous classes for use by application developers from within all .NET languages. These classes are stored in a number of hierarchical classified libraries. The classes offer a collection of extendible functionality to allow developers to realize a high productivity. Classes are available to represent fundamental data types, to perform input / output and to execute operating system services. This vast collection of classes offers complete support for almost every desired application.
Of course there is a price to pay to be able to use all this functionality. The memory footprint of the .NET Framework on a PC is about 32 Megabyte. Besides footprint, the behavior of the application is influenced by necessary JITting and garbage collecting. Memory footprint and non deterministic behavior justify the question if .NET is usable for embedded solutions.
What is the .NET Compact Framework?
Because smart devices (in Microsoft terms all non-PC appliances) become more important in the future and because of the fact that .NET is the architecture model for today and tomorrow in the philosophy of Microsoft, it is important to have .NET also available on these devices. Microsoft was capable of creating a miniature version of the .NET Framework, the .NET Compact Framework. The .NET CF, just like the bigger .NET Framework, consists of different parts, among which a CLR and a less vast collection of classes. Besides all kinds of functionality for graphic user interfaces, the .NET CF also contains support for database management and Web Service clients. The .NET CF also contains a JIT compiler and a garbage collector. Memory footprint of this lightweight alternative of the .NET Framework is only a small part of the complete version, approximately 1.5 MByte. Of course there are situations in which this is still too much for embedded appliances, but for devices in which footprint is less important, it is definitely worth while to take a look at the .NET CF. Each appliance running Windows CE.NET, with the exception of headless equipment, can execute .NET applications. The .NET CF can be installed during platform development or can be added later, whenever a .NET application is available for the device. Unfortunately the .NET CF is not divided in several separate components to allow further reduction of footprint.
Software development for devices
Now that we roughly know what .NET is we can take a closer look at software development aimed specifically towards devices. An important question remains: “Why do we want to develop .NET applications for devices?” Besides the fact that it is easy to consume Web Services, .NET applications also have advantages for stand-alone use. The productivity of programmers is higher because of the richness of the .NET Compact Framework. Thanks to .NET’s platform independence it is very easy to deploy applications for the different processors supported by Windows CE. Instead of several executables for each individual processor, only one executable exists, because the CLR translates IL code on the actual device to machine specific code. Whenever identical applications for PC’s and for devices are developed, .NET is also very beneficial. Especially when development is started using the .NET Compact Framework, it is very easy to get the same application running on PC’s, but also on devices that use Windows XP Embedded. It is important to know that .NET CF applications can only be written in C# and Visual Basic.NET.
Visual Studio.NET 2003 is used to develop applications for the .NET CF. This newest version of Microsoft’s development suite will be released in April of this year, according to expectations. Right now the final Beta version is downloadable by all MSDN subscribers. The .NET Compact Framework itself is no longer in beta. The version of the .NET CF that is part of Visual Studio.NET 2003 Final Beta is promoted to RTM version 1.0. Applications can be developed for PocketPC (2002) and for devices that run with Windows CE.NET, version 4.1.
Figure 1: The “New Project Wizard” in Visual Studio.NET
To develop applications under .NET, the following approach can be taken. Figure 1 shows the “New Project Wizard” which we use to create a new smart device project. Our language of choice is C#. Because of the fact that different devices with all specific characteristics are supported by the .NET CF, in the next step we select a particular platform. In Microsoft terminology a platform is a combination of target hardware together with an operating system.
Figure 2: Device options of Visual Studio.NET
In figure 2 we can see that current choices are limited to PocketPC or a generic Windows CE.NET platform. We can test our application on the real target device or on a Windows CE.NET emulator on the development machine. The emulator makes use of a “real” version of the Windows CE.NET operating system and thus is a realistic but somewhat slow test environment to verify functionality. For time critical tests the emulator can not be used. After platform- and application selection we enter the main screen of our development environment.
Figure 3: Form driven graphical user interface
In figure 3 it becomes clear that the graphical user interface of a managed Windows CE.NET application is form driven. All kinds of controls can be dragged to the form. Within Visual Studio.NET 2003 around 20 standard components are available. The developer gets continuous support of the development environment. Intellisense, a mechanism to show context sensitive information to developers, is everywhere available. The finished application, running in the emulator, is shown in figure 4.
Figure 4: Running application in the Windows CE.NET emulator
To realize the shown functionality we only entered 1 line of C# code. All other necessary code has been generated by the development environment. The only code of interest is that part that is executed when we click the button. This code looks like:
private void btnHello_Click(object sender, System.EventArgs e)
{
label1.Text = "Hello, Bits and Chips readers!";
}
Combining real-time behavior with the .NET CF?
The .NET CF contains a JIT compiler to compiler IL code to processor specific code. The JIT compiler is only invoked when a particular function needs to be translated. This results in non-deterministic behavior of applications. Functions that have been translated to processor specific code will be stored in a cache. However, because of the limited amount of memory usually available in embedded devices, the cache will be limited in size as well, meaning there is always a chance that JITting is necessary more than once. Besides JITting, Garbage Collection leads to unpredictable timing as well. Both JIT compilation and Garbage Collection make the .NET CF unusable for hard real-time behavior. To be able to use the .NET CF in combination with hard real-time functionality an alternative approach should be taken. Managed .NET applications can “escape” from their own managed world and they can call into unmanaged functions that exist in DLL’s. Functions that can be called must be defined public and they must make use of the C calling convention. Most functions inside DLL’s fulfill this requirement already. All Win32 API’s are available in DLL’s and thus available to be called from within managed applications. To be able to do so, look at the following example where we want to call the Win32 API MessageBox from within a managed application.
Using compiler attributes we specify that we want to use a function that resides within a DLL. The attribute also specifies the name of the DLL in which the function to be used can be found. We declare the function being static and external after which we can call the function from within a C# application. The previously shown example can be extended with a call to the Win32 API MessageBoxW:
[System.Runtime.InteropServices.DllImport("coredll.dll")]
public static extern int MessageBoxW(int hWnd,
String text,
String caption,
uint type);
private void btnHello_Click(object sender, System.EventArgs e)
{
label1.Text = "Hello, Bits and Chips readers!";
MessageBoxW(0, "Called from C#", "Win32 MessageBox", 0);
}
This escape possibility out of .NET results in lots of opportunities to create applications that combine hard real-time functionality with modern graphical user interfaces written in a .NET language. Figure 5 shows a possible scenario to this approach.
Figure 5: A real-time application scenario mixing Win32 and managed code
In this scenario we loose platform independence, because of the fact that the real-time functionality exists within a DLL that is platform dependent. Because of the fact that real-time systems are always based upon a specific combination of hardware and software this is not really a problem.
The exact performance costs of using the .NET CF in combination with Win32 DLL’s by means of P/Invoke is not entirely clear yet. We are looking into this subject right now. The first experiments are promising, because JIT compilation and Garbage Collection seem to not block the kernel. Both seem to run at the same priority as the .NET application itself. During JITting and GCing is the .NET application itself blocked, but usually that will not be a problem. In a later article we take a closer look to real-time behavior in combination with managed application code.
Conclusion
As from today, Windows CE developers can finally make use of .NET because the .NET Compact Framework has been released. Right now it is still necessary to us a beta version of Visual Studio.NET 2003 for software development. The combination of using managed .NET code for graphical user interfaces and unmanaged Win32 code for real-time functionality is flexible, creates a high productivity and seems very promising.
Maarten Struys | 
