2. Platform Architecture Mike Zintel Development Manager.NET Compact Framework Microsoft Corporation

3. Agenda  Design goals  Internals of the platform  Key features that enable applications

4. Platform Design Goals  Portable & small.NET Common Language Runtime  Leverage.NET tools  Run.EXEs generated by.NET tools  Cross-debug with VS.NET  Peacefully co-exist with host OS  Scheduling, UI display surface & input, resource contention  Enable rich client Web Services apps  GUI, local storage, networking

5. .NET Terminology  Execution Engine (EE)  Common Language Runtime (CLR) .NET Compact Framework  Programming Frameworks  Class Libraries  Native Code, Managed Code, IL  Common Language Runtime Applications  OEM Application

6. Developing A.NET App

7. .NET CLR Features  Verifiable typesafe execution  No unsafe casts, no uninitialized variables, no out of bounds array indexing, no bad pointer math  Garbage Collection  No ref-counting, no leaks  JIT compilation  Portable & fast  Common type system  Call, inherit, and source-level debug across different languages

8. .NET API Design  Code and data are expressed as classes  Described in metadata, no.h or idl files  Inheritance can be used to extend a class  APIs work across languages  APIs are organized in namespaces with strong naming conventions  Garbage Collection eliminates memory ownership issues

9. .NET Error Handling  Error handling through exceptions  Not bools or HRESULTS  Error handling is mandatory  Default isn’t to “muddle on”  Descriptive exception messages  Not cryptic HRESULTS

10. Language Support  Plans for…  C#  VB.NET  JScript (ECMAScript)  Will deliver in staggered fashion  Platform extensible to other languages  VS.NET packages planned for C#, VB

11. Different Types of Host O/S  Static address space  System image defined at manufacturing time  pSOS, OSE, many custom O/S  Boot loader only  No “application” loader or interactive shell  CLR adds app loader, makes system extensible  Apps run in “App Domains”  Dynamic address space  Boot loader & application loader  Windows, Unix  Shell is provided by the O/S

12. System Architecture

13. Execution Engine  Class loader, verifier, JIT, GC, exception handling, code access security, debugging  Provides hardware and O/S independent program execution  No MMU required on the target CPU  Garbage collection eliminates reference counting and leaks  JIT architecture for fast execution

14. Supported Data Types I1 (SByte)8-bit 2's complement signed value U1 (Boolean, Byte)8-bit unsigned binary value I2 (Int16)16-bit 2's complement signed value U2 (Uint16, Char)16-bit unsigned binary value I4 (Int32)32-bit 2’s complement signed value U4 (UInt32)32-bit unsigned binary value I8 (Int64)64-bit 2’s complement signed value U8 (UInt64)64-bit unsigned binary value R4 (Float)32-bit IEEE 754 floating point value R8 (Double)64-bit IEEE 754 floating point value Onatural size object reference to managed memory &natural size managed pointer (may point into managed memory) *Natural size unmanaged pointer Array StringUnicode string class Same as on the full.NET Framework

15. Native Code Interoperability  Issues  Calling conventions  Garbage collection  Security Vs. extensibility  Platform Invoke (P/Invoke)  Managed  Native  IL_CallDelegate  Native  Managed  Inter-App Domain Message Passing

16. App Domains  Runtime construct that supports a running application  Logical container of application threads  Provides memory isolation  Single execution engine instance can support multiple app domains  Execution engine ensures all resources are released on app termination

17. App Domain Hosts  Bootstrap the execution engine  Written in C, call C APIs to start, pause and stop CLR applications  Few constraints on execution models  Loader hooks on Windows & Windows CE  Web server in ASP.NET  SQL uses CLR for stored procedures  Graphical shell or browser as shell

18. Security  Type-safety  On-device verification for software isolation  Code Access Security with simple policy  Evidence determines access permission buckets  Evidence includes location, signing, banned list  Protocol for remote policy configuration  Add/remove apps from banned list  User Identity/authentication  Exposed through the PAL  Network security  SSL for Web Services, secure email, commerce  System quality

19. Remote Debugging, VS.NET  File copy and run (F5)  Source code breakpoints  Source code single-step  Stack trace  Variable inspection  Thread suspend/resume  Data watchpoints  Multiple device transports

20. Application Installation  Install  Copy files, perform configuration tasks  Uninstall  Deletes files  Dynamic dependency walk removes orphaned shared components  Perform configuration tasks  Shared class lib versioning  “Never break a functioning app”  Apps are written to specific class lib version or “latest”

21. GUI Architecture  Two flavors  Generic – provides cross-OS portability  Drawing primitives  Controls and Forms  OEM-customizable look and feel  Windows Forms  Supersets generic functionality  Available for Windows CE devices  Consistent with WinForms on.NET Framework  Drag n’ drop UI designer in Visual Studio

22. Drawing

23. Basic Networking

24. Network Threading  Apps can make synchronous (blocking) or asynchronous calls  Synchronous calls run on the caller’s thread  The system spins threads to support asynchronous calls  Threads terminate after a short no-use timeout

25. Web Services & Devices  Clean, protocol level separation of publishing and usage  Many producers, many consumers  Separation of data from presentation enables rich client applications  Client applications can aggregate web services from multiple sources  Client applications can control “chunkiness” of transfers .NET CF can execute VS.NET generated client proxy code

26. Performance  JIT compilation  Focus on resource constrained devices  Scalable to more capable devices  Tunable  Tradeoff different memory types

27. Memory Usage

28. Questions?