WinHECNETCompactFrameworkwhitepaper2003

Real-time Behavior of the Microsoft .NET Compact Framework Abstract This paper provides information about real-time behavior of the Microsoft® .NET Compact Framework for the Microsoft Windows® family of operating systems. It provides guidelines for embedded systems developers to realize hard real-time solutions using a combination of both managed and unmanaged code. Contents Introduction ..................................................................................................................................................... 3 A Managed and an Unmanaged World ........................................................................................................... 3 Platform Invoke at Work ............................................................................................................................ 3 A Real-time Scenario ...................................................................................................................................... 6 The Actual Test ............................................................................................................................................... 7 The Results ................................................................................................................................................... 12 Pitfalls ...................................................................................................................................................... 18 Proof of Results ...................................................................................................................................... 18 Conclusion .................................................................................................................................................... 20 Acknowledgments .................................................................................................................................... 20 About the Authors .................................................................................................................................... 21 Call to Action and Resources........................................................................................................................ 21 Acronyms and Terms .................................................................................................................................... 21 Real-time Behavior of the Microsoft .NET Compact Framework - 2 Windows Hardware Engineering Conference Author's Disclaimer and Copyright: © Copyright 2003 Maarten Struys, PTS Software bv. All rights reserved. WinHEC Sponsors’ Disclaimer: The contents of this document have not been authored or confirmed by Microsoft or the WinHEC conference co-sponsors (hereinafter “WinHEC Sponsors”). Accordingly, the information contained in this document does not necessarily represent the views of the WinHEC Sponsors and the WinHEC Sponsors cannot make any representation concerning its accuracy. THE WinHEC SPONSORS MAKE NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THIS INFORMATION. Microsoft, Windows, Windows NT, Visual Basic, Visual C#, Visual C++, Visual Studio, and Win32 are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 3 Introduction With the arrival of Microsoft Visual Studio® .NET 2003 with integrated support for Smart Device Applications it is possible to develop applications for a broad range of devices using managed code. Software developers can now use new exciting languages like Microsoft Visual Basic® .NET and Microsoft Visual C#® for device development. Although this sounds promising one question is still to be answered. Is it possible to make use of the real time capabilities of Windows CE .NET while using managed code to write applications for an embedded device? In this paper we will answer that question and we suggest a possible scenario in which real-time behavior can be combined with .NET functionality. A Managed and an Unmanaged World Some of the advantages of a managed environment like Microsoft’s Common Language Runtime such as writing safer and platform independent software might turn out to be a disadvantage in a real-time environment. Typically, we cannot afford to wait for a just-in-time compiler to compile a method prior to using it, and we cannot wait on a garbage collector to perform its duty, clearing previously allocated memory by removing unused resources. Both these features might interfere with deterministic system behavior. It is possible to force the garbage collector to do its duty, calling GC.Collect(). However, we want the GC to perform its task by itself, since it is highly optimized. To allow hard real-time behavior, it would be great if there was a way in which we could distinguish between hard real-time functionality, written in native or unmanaged Microsoft Win32® code and other functionality, written in managed code. Making use of Platform Invoke or P/Invoke, we can just do that. Platform Invoke at Work The simple definition in MSDN help states that P/Invoke is the functionality provided by the common language runtime to enable managed code to call unmanaged native DLL entry points. In other words, P/Invoke gives us an escape route from managed .NET code to unmanaged Win32 code. To be able to use this mechanism within Windows CE .NET, native Win32 functions that we want to call must be defined extern public within a dynamic link library. Since the managed .NET environment does not know anything about Microsoft Visual C++® name mangling, the functions to be called from within a managed application should have C naming conventions as well. To be able to use functionality from within a DLL, we need to build a wrapper class around the function entry points from within our managed application. Listing 1 shows an example of a small, unmanaged DLL and a wrapper class in managed code. // Wrapper class to be able to P/Invoke into a DLL. // Exported functions in the DLL are imported by this // wrapper. Note the use of compiler attributes to identify // the physical DLL that hosts the exported functions. using System; using System.Runtime.InteropServices; WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 4 namespace CFinRT { public class WCEThreadIntf { [DllImport("RTCF.dll")] public static extern bool Init(); [DllImport("RTCF.dll")] public static extern bool DeInit(); [DllImport("RTCF.Dll")] public static extern uint GetTimingInfo( ref uint perfAvg, ref uint perfMax, ref uint perfMin, ref uint perfTickMax, ref uint perfTickMin); } } // Call an unmanaged function from within managed code public void CollectValue() { if (WCEThreadIntf.GetTimingInfo(ref aveSleepTime, ref maxSleepTime, ref minSleepTime, ref curMaxSleepTime, ref curMinSleepTime) != 0) { curMaxSleepTime = (uint)(float)((curMaxSleepTime * scaleValue) / 1.19318); curMinSleepTime = (uint)(float)((curMinSleepTime * scaleValue) / 1.19318); aveSleepTime = (uint)(float)((aveSleepTime * scaleValue) / 1.19318); maxSleepTime = (uint)(float)((maxSleepTime * WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 5 scaleValue) / 1.19318); minSleepTime = (uint)(float)((minSleepTime * scaleValue) / 1.19318); } StoreValue(); counter = (counter + 1) % samplesInMinute; } Listing 1a: Calling into unmanaged code // This is the function GetTimingInfo that exists in the // unmanaged Win32 DLL. The function is fed with information, // originating in an Interrupt Service Thread in the same // DLL. On request of the managed application, timing // information is copied using a double buffering mechanism. RTCF_API DWORD GetTimingInfo(LPDWORD lpdwAvgPerfTicks, LPDWORD lpdwMax, LPDWORD lpdwMin, LPDWORD lpdwDeltaMax, LPDWORD lpdwDeltaMin) { g_bRequestData = TRUE; if (WaitForSingleObject(g_hNewDataEvent, 1000)==WAIT_OBJECT_0) { *lpdwAvgPerfTicks = g_dwBufferedAvgPerfTicks; *lpdwMax = g_dwBufferedMax; *lpdwMin = g_dwBufferedMin; *lpdwDeltaMax = g_dwBufferedDeltaMax; *lpdwDeltaMin = g_dwBufferedDeltaMin; return 1; } else return 0; WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 6 } // GetTimingInfo prototype #ifdef RTCF_EXPORTS #define RTCF_API __declspec(dllexport) #else #define RTCF_API __declspec(dllimport) #endif extern "C" { RTCF_API BOOL Init(); RTCF_API BOOL DeInit(); RTCF_API DWORD GetTimingInfo(LPDWORD lpdwAvgPerfTicks, LPDWORD lpdwMax, LPDWORD lpdwMin, LPDWORD lpdwDeltaMax, LPDWORD lpdwDeltaMin); } Listing 1b: Win32 DLL to be called from within managed code Using the wrapper class, it is possible to call functions that exist inside the DLL. Since this mechanism works for all exported DLL functions and since almost all Win32 APIs are exported in coredll.dll, this mechanism also provides a way to call into almost any Win32 API. P/Invoke is used in our test to have a managed application calling into an unmanaged real-time thread. A Real-time Scenario Imagine the following scenario: A system needs hard real-time functionality to retrieve information from an external source. The information is stored in the system and will be presented to the user in some graphical way. Figure 1 shows a possible scenario for this problem. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 7 Figure 1 - A real-time scenario We see a real-time thread receiving an interrupt from an external source. The thread processes the interrupt and stores relevant information to be presented to the user. On the right-hand side, a separate UI thread, written in managed code, reads information that was previously stored by the real-time thread. Given the fact that context switches between processes are expensive, we want the entire system to live within the same process. If we separate real-time functionality from user interface functionality by putting real-time functionality in a dynamic link library and providing an interface between that DLL and the other parts of the system, we have achieved our goal of having one single process dealing with all parts of the system. Communication between the UI thread and the RT thread is possible by means of P/Invoking into the native Win32 code. The Actual Test We want to make the test representative, yet as simple as possible so it can be repeated easily on other systems as well. For that purpose, the source code to run the experiment yourself is available for download. Our test requires a way to feed interrupts into the system and a possibility to output probes to be able to measure the performance of the system. We feed the system using a block wave, generated by a signal generator. Of course the Windows CE .NET platform should be capable of hosting the .NET CF. Paul Yao has written an article indicating which Windows CE .NET modules and components should be present to run managed applications (see “Microsoft .NET Compact Framework for Windows CE .NET” on msdn.microsoft.com). The aim of the test is not only to be representative and reproducible. Just find a suitable interrupt source for input. Listing 2 shows how to hook a physical interrupt to an interrupt service thread (IST). RTCF_API BOOL Init() { BOOL bRet = FALSE; DWORD dwIRQ = IRQ; // in our case IRQ = 5 // Get a SysIntr for the specified IRQ if (KernelIoControl(IOCTL_HAL_TRANSLATE_IRQ, WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 8 &dwIRQ, sizeof(DWORD), &g_dwSysIntr, sizeof(DWORD), NULL)) { // create an event that will activate our IST g_hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); if (g_hEvent) { // Connect the interrupt to our event and // create our Interrupt Service Thread. // The actual IST is shown in listing 4 InterruptDisable(g_dwSysIntr); if (InterruptInitialize(g_dwSysIntr, g_hEvent, NULL, 0)) { g_bFinish = FALSE; g_hThread = CreateThread(NULL, 0, IST, NULL, 0, NULL); if (g_hThread) { bRet = TRUE; } else { InterruptDisable(g_dwSysIntr); CloseHandle(g_hEvent); WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 9 g_hEvent = NULL; } } } } return bRet; } Listing 2: Connecting a physical interrupt to an interrupt service thread To test the real-time behavior of an application making use of managed code and the .NET Compact Framework we have created a Windows CE platform, based on Standard SDK. We also included the RTM version of the .NET Compact Framework in the platform. The operating system runs on a Geode GX1 at 300 MHz. We feed the system with a block wave, immediately connected to the IRQ5 line on the PC104 bus (pin 23). Figure 2 shows the system used for the experiment. The frequency of the block wave is 10 kHz. On uprising flanks, an interrupt is generated. The interrupt is processed by an interrupt service thread (IST). In the IST we send out probe pulses to the parallel port to be able to view an output signal. We also store the time at which the IST was activated making use of the high resolution QueryPerformanceCounter API. To be able to measure timing information over a long period of time, we also store maximum and minimum time as well as average time. The time from interrupt occurrence to probe output is an indication of IRQ – IST latency. The timing information acquired by the high resolution timer indicates when the IST is activated. Ideally this value should be 100 µ sec. for an interrupt rate of 10 kHz. All timing information is passed to the graphical user interface on regular intervals. Figure 2 - The actual test system As the .NET CF itself can not be used in hard real-time situations as explained earlier, we decided to use it for presentation purposes only and to use a DLL, written in eVC++ 4.0 for all real-time functionality. For communication between the WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 10 DLL and the .NET CF GUI a double buffering mechanism is used in combination with P/Invoke. The GUI requests new timing information on regular intervals, making use of a System.Threading.Timer object. The DLL decides when it has time available to pass information to the GUI. Until data is ready, the GUI is blocked. The refresh rate of the information presented in the GUI is user selectable. For our test we used a refresh rate of 50 msec. The following pseudocode explains the operation of the IST and the mechanism by which the GUI retrieves information, stored in the native Win32 DLL. Interrupt Service Thread: Wait On IRQ 5 send probe pulse to the parallel port Measure time with QueryPerformanceCounter Store measured time (min, max, current, average) locally if (userInterfaceRequestsData) { copy measured time information reset statistic measure values set dataReady event userInterfaceRequestsData = false } Managed code periodical update of display data: disable timer // See pitfalls call with P/Invoke into the DLL // The following code is implemented in the DLL userInterfaceRequestsData = true wait for dataReady event return measured values draw measured values on the display, each time using new graphics objects update marker enable timer During the test we hooked up an oscilloscope and made printouts of both the scope and the Windows CE graphical display 10 minutes into the experiment. In figure 3 the interrupt latency, measured with an oscilloscope is displayed. Best case, the latency is 14.0 µ sec., worst case the latency is 54.4 µ sec, meaning a jitter of 40.4 µ sec. In figure 4 the periodic time is displayed when the IST is activated. This figure is a screen shot of the actual user interface. Ideally the IST should run every 100 µ sec, which is also the average time during our measurement (the blue line in the middle). We also measured overall minimum (green) and maximum (red) times, as well as minimum and maximum times over the sample period of 50 msec (the white block). The deviation we found during the test period is limited to ± 40 µ sec. // A running vertical bar on the display WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 11 Figure 3 - Managed application: IRQ - IST latency Figure 4 – Managed application: IST activation times after running 10 minutes WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 12 The Results We measured over a longer period of time to make sure that both the Garbage Collector and the JIT compiler were frequently active. Thanks to the folks at Microsoft, we were able to monitor the behavior of the .NET CF because they provided us with a performance counters registry key. Using this key, a number of performance counters within the .NET CF are activated. We mainly used this performance information to verify that JITter and Garbage Collector actually ran. It also gave a nice indication about the number of objects used during the cause of the test. // Our periodic timer method in which we want to collect new // data and refresh the screen private void OnTimer(object source) { // Temporarily stop the timer, to prevent against // a whole bunch of OnTimer calls to be invoked if (theTimer != null) { theTimer.Change(Timeout.Infinite, dp.Interval); } Pen blackPen = new Pen(Color.Black); Pen yellowPen = new Pen(Color.Yellow); Graphics gfx = CreateGraphics(); td.SetTimePointer(dp.CurrentSample, gfx, blackPen); for (int i = 0; i < dp.SamplesPerMeasure; i++) { td.ShowValue(dp.CurrentSample, dp[i], gfx, i); } dp.CollectValue(); td.SetTimePointer(dp.CurrentSample, gfx, yellowPen); gfx.Dispose(); yellowPen.Dispose(); blackPen.Dispose(); WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 13 // Restart the timer again for the next update if (theTimer != null) { theTimer.Change(dp.Interval, dp.Interval); } } Listing 3: Handling timer messages in a managed world As you can see in listing 3, we instantiate a number of objects each time we periodically update the screen. These objects, 2 pens and a graphics object are created during each screen update. Both functions td.ShowValue and td.SetTimerPointer also create brushes. Since td.SetTimerPointer is called twice per screen update, a total of 6 objects are created during each update of the screen. Since we update the screen every 50 msec. a total number of 120 objects are created per second. Over 10 minutes of execution, 72000 objects are created. All these objects are potentially subject to garbage collection. In table 1, the number of allocated objects roughly corresponds to these theoretical values. We have included performance counter results for both a 10 minute and a 100 minute run. This data was recorded during our actual test. As you can see, after running 10 minutes, garbage collection occurred without noticeable fallbacks in performance. Table 2 shows the performance counters for a run of approx. 100 minutes. In this run full garbage collection occurred. During this run, only 461499 objects were created instead of the 720000 expected objects. This is approximately 35% less than expected. The difference is likely to be caused by the performance counters which, according to Microsoft result in a performance penalty of about 30% within the managed application. However, real-time behavior of the system was not influenced as you can see in figure 5. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 14 Figure 5 - Managed application: IST activation times after running 100 minutes Extra proof for the fact that the garbage collector and the JITter did not influence real-time behavior can be found in the remote process viewer. In figure 6 you can see a screen dump of the remote process viewer for the managed application. All threads in the application (except the real-time thread with priority 0) run at normal priorities (251). During our measurements we did not find that the JITter or garbage collector needed kernel blocking to perform their tasks. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 15 Figure 6 - Remote process viewer showing the managed application WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 16 Table 1: .NET CF performance results after running the test for ten minutes Counter Execution Engine Startup Time Total Program Run Time Peak Bytes Allocated Number Of Objects Allocated Bytes Allocated Number Of Simple Collections Bytes Collected By Simple Collection Bytes In Use After Simple Collection Time In Simple Collect Number Of Compact Collections Bytes Collected By Compact Collections Bytes In Use After Compact Collection Time In Compact Collect Number Of Full Collections Bytes Collected By Full Collection Bytes In Use After Full Collection Time In Full Collection GC Number Of Application Induced Collections GC Latency Time Bytes Jitted Native Bytes Jitted Number of Methods Jitted Bytes Pitched Number of Methods Pitched Number of Exceptions Number of Calls Number of Virtual Calls Number Of Virtual Call Cache Hits Number of PInvoke Calls Total Bytes In Use After Collection Value 492 603752 1115238 66898 1418216 0 0 0 0 1 652420 134020 357 0 0 0 0 0 357 14046 70636 259 0 0 0 3058607 1409 1376 176790 421462 n 0 0 0 0 66898 0 0 0 0 0 1 1 1 0 0 0 0 0 1 259 259 0 0 0 0 0 0 0 0 1 Mean 0 0 0 0 21 0 0 0 0 0 652420 134020 357 0 0 0 0 0 357 54 272 0 0 0 0 0 0 0 0 421462 min 0 0 0 0 8 0 0 0 0 0 652420 134020 357 0 0 0 0 0 357 1 35 0 0 0 0 0 0 0 0 421462 max 0 0 0 0 24020 0 0 0 0 0 652420 134020 357 0 0 0 0 0 357 929 3758 0 0 0 0 0 0 0 0 421462 WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 17 Table 2: .NET CF performance results after running the test for hundred minutes Counter Execution Engine Startup Time Total Program Run Time Peak Bytes Allocated Number Of Objects Allocated Bytes Allocated Number Of Simple Collections Bytes Collected By Simple Collection Bytes In Use After Simple Collection Time In Simple Collect Number Of Compact Collections Bytes Collected By Compact Collections Bytes In Use After Compact Collection Time In Compact Collect Number Of Full Collections Bytes Collected By Full Collection Bytes In Use After Full Collection Time In Full Collection GC Number Of Application Induced Collections GC Latency Time Bytes Jitted Native Bytes Jitted Number of Methods Jitted Bytes Pitched Number of Methods Pitched Number of Exceptions Number of Calls Number of Virtual Calls Number Of Virtual Call Cache Hits Number of PInvoke Calls Total Bytes In Use After Collection Value 478 5844946 1279678 461499 8975584 0 0 0 0 11 8514912 1679656 5395 2 397428 79924 65 0 5460 19143 95684 356 85304 385 0 21778124 1067 1029 1996991 5632119 n 0 0 0 0 461499 0 0 0 0 0 11 11 11 0 2 2 2 0 13 356 356 0 326 0 0 0 0 0 0 13 mean 0 0 0 0 19 0 0 0 0 0 774082 152696 490 0 198714 39962 32 0 420 53 268 0 261 0 0 0 0 0 0 433239 min 0 0 0 0 8 0 0 0 0 0 656456 147320 436 0 1916 17328 2 0 2 1 35 0 35 0 0 0 0 0 0 84637 max 0 0 0 0 24020 0 0 0 0 0 786476 153256 542 0 395512 62596 63 0 542 929 3758 0 3758 0 0 0 0 0 0 493054 WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 18 Pitfalls During the test, increasing the frequency of the block wave led to unexpected results in the managed application. Especially in the situation where the screen needed frequent repaints (because areas of the screen were invalid), the application randomly hung up the system. Investigation of this problem showed unexpected behavior for experienced Win32 programmers. In a Win32 application, using a timer results in a WM_TIMER message each time a timer expires. However, in the message queue WM_TIMER messages are low priority messages, only posted when there are no other higher priority messages to be processed. This behavior can possibly lead to missing timer ticks, but since CreateTimer does not give us an accurate timer to begin with. This is no problem, especially if the timer is used to update a graphical user interface. However, in the managed application, we use a System.Threading.Timer object to create a timer. This timer calls a delegate every time the timer expires. The delegate is called from within a separate thread that exists in a thread pool. If the system is too busy with other activities, like repainting an entire screen, more timer delegates, each in separate threads, are activated before previously activated delegates are finished. This might lead to consuming all available threads from the thread pool, causing the system to hang. The solution to prevent this behavior is found in listing 3. Each time a timer delegate is activated, we stop the timer object by invoking the Change method of the Timer object, to indicate that we do not want the next timer message until we have processed the current one. Proof of Results To be able to compare the results of our experiment with typical results in the same setting, we also wrote a Win32 application that invoked the same DLL with real-time functionality. The Win32 application is functionally identical to the managed application. It provides the system with a graphical user interface in which timing information is displayed in a window. This application paints timing results upon reception of WM_TIMER messages, solely making use of Win32 APIs. The update rate of the screen for both applications is user selectable, but for both applications we chose an update rate of 50 milliseconds. Basically we did not find any difference in performance, as figures 6 and 7 show. In figure 6 the interrupt latency is again measured with an oscilloscope. For the Win32 application, the latency is 14.4 µ sec. Worst case the latency is 55.2 µ sec, meaning a jitter of 40.8 µ sec. These results are identical to the test run with a .NET CF managed application. In figure 7 the periodic time is displayed when the IST is activated, again for the Win32 application. Again, the results are identical to the results of a .NET CF managed application. The source for the Win32 application is also downloadable so you can compare the behavior of the two different applications yourself. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 19 Figure 7 - Win32 application: IST activation times after running 10 minutes WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 20 Figure 8 - Win32 application: IST activation times after running 10 minutes Conclusion First we need to make absolutely sure that you understand that we are not suggesting the .NET CF for any real-time work by itself. We suggest that it can be used advantage as a presentation layer. In such a system, the .NET CF can "peacefully co-exist" with real-time functionality, not affecting the real time behavior of Windows CE .NET. In this article we have not benchmarked the graphics capabilities of the .NET CF. In our situation we did not find any significant difference in an application, written entirely in Win32 or an application, partly written in a managed environment with Visual C#. Given the higher programmer productivity and the richness of the .NET Compact Framework, there are many advantages in writing presentation layers in managed code and writing hard real-time functionality in unmanaged code. The clear distinction between these different types of functionality is something you will get for free, using this approach. Acknowledgments We have been thinking quite a while about testing the usability of the .NET Compact Framework in real-time scenarios. This test was only possible by cooperating with people and companies that could provide us with the proper hardware and measuring equipment. Therefore we like to thank Willem Haring of Getronics for his support, ideas and hospitality during this project. We also like to thank the folks at Delem for their hospitality and for providing us with the necessary equipment to execute our tests. WinHEC 2003 Microsoft Windows Hardware Engineering Conference Real-time Behavior of the Microsoft .NET Compact Framework - 21 About the Authors Michel Verhagen works at PTS Software bv in the Netherlands. Michel is a Windows CE consultant, has 4 years experience with Windows CE. His main expertise lies in the area of Platform Builder. Maarten Struys also works at PTS Software bv. There he is responsible for the realtime and embedded competence center. Maarten is an experienced Windows (CE) developer, having worked with Windows CE since its introduction. Since 2000, Maarten is working with managed code in .NET environments. He is also a freelance journalist for the two leading magazines on embedded systems development in The Netherlands. He recently opened a website with information about .NET in the embedded world. Call to Action and Resources Resources: www.pts.nl www.getronics.nl www.delem.nl www.dotnetfordevices.com www.microsoft.com/embedded Acronyms and Terms          DLL GC GUI IST P/Invoke RT RTM SDK UI Dynamic Link Library Garbage Collector Graphical User Interface Interrupt Service Thread Platform Invoke Real-time Ready to Manufacture Software Development Kit User Interface WinHEC 2003 Microsoft Windows Hardware Engineering Conference