Douglas Boling President Boling Consulting Inc. WEM201

About Douglas Boling Independent consultant specializing in Windows Mobile and Windows Embedded CE On-site instruction Consulting and development Author Programming Embedded Windows CE Fourth Edition Regular speaker at industry conferences

Agenda Introduction to Windows Embedded CE Performance issues Development strategies

Rule #1: Write Good Code! “Desktop developers are paid to quickly write code.” “Embedded developers are paid to write quick code.”

Agenda Introduction to Windows Embedded CE Performance issues Development strategies

What is Windows Embedded CE? New kernel Not a “small XP/Vista/7” kernel Componentized The OS can change Unique Hardware Different CPUs Not WinTel

“But It Works On The Desktop!” Windows Embedded CE is written to the specification of Win32, not the implementation Often desktop code works in places it shouldn’t Read the docs; if it’s not guaranteed to work it probably won’t Driver and Services model completely different The CE driver/services model is much simpler

Memory Issues Check your memory allocations Memory allocations will fail No paging file Tolerate low memory conditions Expect fragmentation Applications can run for weeks or months

Security Issues The current versions of Windows Embedded CE don’t use ACLs If security is needed Module load security can be implemented Modules (.DLLs/.EXEs) are checked on first load Can be prevented from loaded by OEM code Vetting implementation dependent, typically embedded certificates

Porting to Unicode Windows CE apps are Unicode (UTF16) ANSI only supported in the C runtime libs Unicode characters are 16 bits string length + 1 != buffer size Know what the function wants Port to Unicode on desktop first Allows use of better debug tools

Agenda Introduction to Windows Embedded CE Performance issues Development strategies

Performance Fundamentals Embedded hardware is slow It’s designed that way intentionally Slower hardware means Smaller Better battery life Cooler (temperature wise) Less expensive

Embedded Performance Software performance impacts hardware design Users expect a level of performance With slow software, hardware has to be made faster “It’s okay, just wait a year and the hardware will catch up!”

Moore’s Law Will Save Us… …Wrong! What does Moore’s law say? It’s not that CPUs double in speed every 2 years…

Moore’s Law Is Different… Moore’s law states that transistor counts will double every 2 years… PCs Transistors are added to improve performance Embedded Transistor count increases much slower, with the extra efficiency going to power and component cost

Speed Limiters Devices are “bus limited” Performance of device limited by memory bandwidth Embedded CPUs fast in the core Computation ability fairly good Typically, no floating point Except x86 and some ARM

General Performance Tips Copy pointers, not memory Copying memory is quite slow Use DMA where possible Developers need to know the hardware Performance issues on specific busses Cache size vs. locality issues If you have lots of RAM, use it

Don’t Be Wasteful Know your “expensive” calls Avoid multiple calls Expensive calls Database Volume load Named Handle creation Opening and closing registry keys Don’t create needless DLLs

General Tips Most systems have very slow video systems Some don’t The disk is slow Flash performs differently from disk drives Think “Chunky” not “Chatty” A few big calls vs. lots of little ones

Performance Is a Safety Issue! Every second the user is waiting is a second they’re not aware of their environment Working Walking Driving Performance is a required feature Design in performance Test for performance

Agenda Introduction to Windows Embedded CE Performance issues Development strategies

Develop On Target Hardware Don’t develop code on PCs or Virtual PCs They are far too fast Embedded systems are slow Developers need the instant feedback of knowing their code is too slow Otherwise code is too big and slow for final hardware

Leaks… …are deadly on embedded systems Application Verifier can detect Memory leaks GDI Object leaks Handle leaks Sometimes you need to extend App Verifier Write your own “shims”

Defensive Programming All entry points to modules should verify parameters Never let an exception leave a module Use __try __except blocks to vet pointers Vet parameters before starting new threads

Provide a Logging Service Embedded devices typically run unattended Often in remote or restricted areas Collect data Driver loads/unloads Process starts/terminations Log thread start entry points and thread IDs Necessary for matching exception info with threads

Use “Windows Embedded CE Error Reporting” This is “Dr. Watson” Exceptions produce dump files Dump files can be opened in Platform Builder kernel debugger Great for finding intermittent problems

Managed Code.NET Compact Framework a great “Small.NET” Supports C# and VB.NET languages only Base Class Library significantly smaller Great client support Very little server support CF runtime tuned for small memory systems This may not match your system profile

Managed Code Tips IDisposable Classes that hold system resources must be disposable Dispose, dispose, dispose!!! Avoid unnecessary boxing Templates vs. generic collections Take care with parameter passing

Managed Code Tips Garbage Don’t generate it! Take care with… Strings Generic collections Classes where structures will do Realtime routines must be implemented in native code GCs happen at the worst possible times

COM – Just Say No The Component Object Model is bad Its overly complex Its hard to use Windows Embeded CE avoided the COM curse for the most part Don’t start now! Use.NET CF for reusable objects

MFC – Don’t Do It MFC is great for writing Word Is that what you’re doing? Often MFC used for CString The rest of the time is spent overriding the default functionality of MFC Use.NET CF for Forms based apps

Testing Do it… NOW! Test early Test every day Track results If you wait, your customers will too

Summary Your current Windows knowledge valuable Same API, just different The difference is attitude YOU are responsible for performance not the HW Respect the hardware Its designed that way for a reason

Sessions On-Demand & Community Resources for IT Professionals Resources for Developers Microsoft Certification and Training Resources Microsoft Certification & Training Resources Resources

Complete an evaluation on CommNet and enter to win!

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. Required Slide