290 likes | 304 Views
This agenda covers design goals, internals of the platform, key features, and terminology of the .NET Compact Framework, a programming framework by Microsoft Corporation. It provides portable and small runtime, enables cross-debugging with Visual Studio, co-existence with the host OS, scheduling, UI, resource contention, and supports rich client web services apps with GUI, local storage, and networking.
E N D
Platform Architecture Mike ZintelDevelopment Manager.NET Compact FrameworkMicrosoft Corporation
Agenda • Design goals • Internals of the platform • Key features that enable applications
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
.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
.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
.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
.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
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
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
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
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 O natural size object reference to managed memory & natural size managed pointer (may point into managed memory) * Natural size unmanaged pointer Array String Unicode string class Supported Data Types Same as on the full .NET Framework
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
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
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
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
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
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”
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
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
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
Performance • JIT compilation • Focus on resource constrained devices • Scalable to more capable devices • Tunable • Tradeoff different memory types