Net architecture
1 / 77

.Net Architecture - PowerPoint PPT Presentation

  • Updated On :

.Net Architecture. Jon Shemitz Midnight Beach. Introduction. Why people are excited about .Net Three main sections 10% Why .Net? 10% A quick run through the acronyms 80% A more detailed walk up the stack Heavy on machinery, light on code you actually call.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '.Net Architecture' - emile

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Net architecture l.jpg
.Net Architecture

Jon Shemitz

Midnight Beach

Introduction l.jpg

  • Why people are excited about .Net

  • Three main sections

    • 10% Why .Net?

    • 10% A quick run through the acronyms

    • 80% A more detailed walk up the stack

      • Heavy on machinery, light on code you actually call

Why net microsoft s perspective l.jpg
Why .Net? Microsoft’s perspective

  • The Java threat

    • .Net is the managed code environment Microsoft needs to compete against Sun in the enterprise arena

    • Microsoft needs you, the programmer

      • Network effects give their OS franchise its value

      • Java has had great success with “Learn once, work anywhere”

Why net developer s perspective l.jpg
Why .Net? Developer’s perspective

  • Managed code

    • Makes Other Peoples’ Code more reliable

  • The run time library is really good

    • Objects all the way down

  • Exciting programming environment

    • Little penalty for very light-weight objects

  • Deep language neutrality

    • Where Microsoft adds most value to Java

Why net delphi perspective l.jpg
Why .Net? Delphi perspective

  • .Net has a lot of the Delphi feel

    • There are some new ways to code

      • Garbage collection turns objects into values

    • Easy for a Delphi developer to learn .Net

      • Skills transfer, expectations tend to be right

  • Delphi experience gives you an edge in the .Net world

Java s good points l.jpg
Java’s good points

  • The API is object oriented from bottom to top

    • No alphabetized lists of hundreds of flat function names

  • Managed code means some common programming mistakes are not possible

    • This is a security feature, not a Lazy Programmer Convenience - a system without buffer overruns is a safer system

Java is a tough target l.jpg
Java is a tough target

  • Microsoft can’t beat Java with FUD

  • Embrace And Extend won’t work, either

  • They had to fall back on Plan C:

    • Lots of hard work by lots of bright people

Java s achilles heel is java itself l.jpg
Java’s Achilles’ heel is Java itself

  • The environment is great but you can’t simply port legacy code to Java – you have to rewrite it

    • Many companies have decades worth of legacy systems

    • They might port their legacy code to a managed code system, but they won’t rewrite all their legacy code

Language neutrality l.jpg
Language neutrality

  • .Net offers all the advantages of Java, plus language neutrality.

  • All .Net languages use the same object-oriented runtime library, the Framework Class Library [FCL]

    • You’ll have to learn the FCL

    • Once you know the FCL, you can easily work in whatever language the legacy code du jour was written in

Java language neutrality l.jpg
Java + language neutrality

  • Java and .Net have the same two compelling features:

    • An object oriented API

    • A managed code environment

      • No loose pointers

      • No memory leaks

  • .Net adds language neutrality

End of introduction l.jpg
End of introduction

  • Key features

    • Object-oriented API

    • Managed code

    • Language neutrality

  • Next

    • A bottom-up tour of the architecture

    • Watch for these features, emerging from the details

Common abbreviated names l.jpg
Common Abbreviated Names


Framework Class Library


Common Type System


Common Language Specification


Common Language Runtime

Clr common language runtime l.jpg
CLR = Common Language Runtime

  • Garbage collection

  • Just-in-time compilation

    • .Net isneverinterpreted

    • The jitter [the JIT compiler] compiles about as fast as Delphi

    • The object code that the jitter puts out is a lot like Delphi’s object code

      • Only better, because the jitter can do function inlining

Cts common type system l.jpg
CTS = Common Type System

  • Basic value types

  • Type composition

  • Type safety

  • Objects

  • Interfaces

  • Delegates

    • Delegates are a multi-cast version of Delphi’s events

Cls common language specification l.jpg
CLS = Common Language Specification

  • Subset of the Common Type System

  • All 1st class .Net languages need to support CLS

  • You can have non-CLS type - like unsigned integers - but some .Net languages won’t understand them

    • For example, Visual Basic doesn’t have unsigned integers

Fcl framework class library l.jpg
FCL = Framework Class Library

  • FCL is new ‘universal’ run-time library

    • Object-oriented API

    • Roughly the same size as the Delphi BPL’s

  • Thousands of CLS-compliant C# classes

    • Everything from GUI programming to file IO to web services

And now the details l.jpg
And now, the details

  • Any CEOs can leave the room now

  • .Net has two main parts

    • Runtime

      • Written in C++

    • Framework classes

      • Written in C#

  • Components and applications

    • Any language

Clr the net engine l.jpg
CLR: the .Net engine

  • Gets threads and memory from the underlying OS, and not much else

  • Four major components:

    • Just In Time compilation of CIL [Common Intermediate Language] to native object code

    • Garbage collection

    • Common Type System [CTS]

    • Exception handling machinery

The clr manages your code l.jpg
The CLR manages your code

  • No “tombstoned” pointers; no miscasting

    • You can never accidentally treat a TFont as a TStringList

  • Managed code is not interpreted code

    • .Net maintains type safety and memory safety while running compiled object code

Net portability l.jpg
.Net portability?

  • Porting .Net means porting the CLR

    • You’d also have to port the WinForms library before desktop (GUI) programs will work

  • ECMA-335

    • 2000 pages that describe core functionality

    • A very large, multi-year task

  • ISO standardization

    • Coming this month

Os x and linux l.jpg
OS/X and Linux

  • At the May 2002 BorCon, Borland R&D suggested that we’re likelier to see Delphi for .Net running on .Net on OS/X than a native Delphi for OS/X

  • They also mentioned .Net on Linux as a possible future home for Kylix developers

Slide22 l.jpg

  • All .Net languages compile to CIL

    • CIL was once known as Microsoft Intermediate Language, or MSIL

  • A compiled .Net program is called an assembly

    • An assembly is a standard PE [Portable Executable] exe or dll

    • Assemblies contain a special header that says that the PE file contains CIL and .Net metadata instead of normal object code

Stub code l.jpg
Stub code

  • Each entry point in the PE file points to stub code

    • Executing the stub code compiles the CIL to actual object code on an as-needed basis

Before JIT

After JIT






Jit overhead l.jpg
JIT overhead

  • First call is slower than subsequent calls, but not much

    • CIL is close to machine language

    • Jitter doesn’t have to handle parsing, linking, or macro expansion.

  • JIT cost is a relatively modest ‘tax’ on top of demand-load cost

Jit benefits l.jpg
JIT benefits

  • The jitter can generate object code optimized for the machine it’s running on

  • In a sense, the jitter is a smart linker

    • Unused code is not jitted, may not be loaded

    • So it doesn’t cost time or memory at runtime

A little about cil l.jpg
A little about CIL

  • CIL is a sort of p-code

  • Assemblies store CIL as byte codes

    • Tokenized assembler that the jitter can compile quickly

  • The (free) .Net SDK includes the ILASM assembler and the ILDASM disassembler

Cil is a high level assembly language l.jpg
CIL is a high-level assembly language

  • Not a Lowest Common Denominator language

  • No one language uses all CIL features

    • Has features, like tail recursion, that are used by languages that aren’t even supported yet

  • CIL is an intermediate language

    • Compiled at runtime

    • Not executed directly

Cil is strongly typed l.jpg
CIL is strongly typed

  • CIL is verbose and strongly-typed - yet CIL is also stack-based and generic

    • Push Integer and Push Float instructions will fail if the value to be pushed is of the wrong type

    • Add instruction operates on the two values on the top of the stack and does type conversion as necessary

Cil is easy to write l.jpg
CIL is easy to write

  • It’s easier to emit CIL than it is to generate x86 object code

    • Great for things like spreadsheets, query engines, and script languages

  • Stack model means that you never have to worry about register allocation

  • RPN [Reverse Polish Notation] syntax is easy to generate mechanically

System reflection emit l.jpg

  • Applications can use the “reflection” API to emit CIL at runtime

  • Generated code will be jitted when called, just like any other CIL code

What about garbage collection l.jpg
What about garbage collection?

  • Typical programmer reactions to .Net

    • “What makes this any better than Java?”

      • Language neutrality

    • “But, what about that JIT overhead?”

      • It’s just not that bad

    • “Garbage collection sucks.”

Garbage collection doesn t suck l.jpg
Garbage collection doesn’t suck

  • Many nice features

    • Fast allocation

      • Just advancing a pointer, not updating a linked list

    • Better cache performance

      • Consecutive allocations are adjacent

    • Smaller, simpler, and more reliable code

      • More object-oriented, without ownership issues

    • No dangling pointers

      • Data structures never refer to memory that’s been freed

Better than reference counting l.jpg
Better than reference counting

  • Delphi’s strings, dynamic arrays, and interfaces use reference counting

  • Offers same simplicity and safety as garbage collection but:

    • Overhead of maintaining the reference counts

    • Reference counting can’t handle circular references

Garbage collection speed l.jpg
Garbage collection speed

  • ‘Old-school’ garbage collectors could lock the system unpredictably

    • Canceled advantages of garbage collection

    • Lead to bad reputation

  • A full .Net garbage collection takes less time than a page fault

    • Which you typically don’t even notice

Why so fast l.jpg
Why so fast?

  • Memory life spans are distributed according to a power law

    • Most memory is freed quite soon after it’s allocated

    • Most of what’s left is freed within seconds or minutes

    • And most of what lasts longer than that lasts until the program shuts down

3 generation garbage collector l.jpg
3 generation garbage collector

  • Garbage is collected after ‘enough’ allocations

    • Not only when heap is exhausted

    • Gen 0 defaults to size of the CPU’s Level 2 cache

  • Looks at recent allocations

    • Finds memory blocks that are still in use

  • “Garbage collection” is a bad name

    • Only have to do work on blocks that aren’t garbage

Live blocks l.jpg
Live blocks

  • Get moved and promoted

    • The next collection at old level won’t look at them

Before generation 0 garbage collection

Generation 0

Generation 1













After generation 0 garbage collection

Generation 1









Generations 1 and 2 l.jpg
Generations 1 and 2

  • Generation 1 collection after ‘enough’ more allocation

    • Finds blocks that not have become garbage since being promoted

    • Power law at work again – most have died

    • Survivors are moved and promoted - aren’t touched again until generation 2 garbage collection

  • Generation 2 garbage collection just moves survivors - does not promote

Generations save work l.jpg
Generations save work

  • Cuts times a long-lived object is detected and moved

  • Speeds live block detection

    • Walks reference chains down from “roots”

      • .Net has type data for every structure in the system. It knows every field of every structure.

    • Walk can stop on old objects: eg, most generation 1 objects only refer to generation 1 or 2 objects, which a generation 0 sweep doesn’t care about

      • JITter maintains a ‘dirty bit’

Resource protection l.jpg
Resource protection

  • Reference counting is slower than garbage collection

  • But reference counting is better at resource protection

    • Close file, or restore visual, at moment interface variable goes out of scope and object is freed

Finalization l.jpg

  • Finalization routine gets called when the block is scavenged

    • No control over when it happens

    • A whole class of “failsafe” Delphi techniques that rely on interface finalization are invalid under .Net

Weak references l.jpg
Weak references

  • Data you don’t currently need that’s relatively expensive to regenerate

    • Useful for browser cache, or singleton objects like the Printer or Clipboard

  • “Target” property contains valid reference or Nil

    • Casting non-Nil Target gives normal (strong) reference that will keep the data from being garbage collected

  • Just like Java

Safe code l.jpg
Safe code

  • .Net protects you from sloppy code

    • Managed code eliminates the risks from prematurely released memory and careless casts

    • Exceptions keep code from assuming a system state that it hasn’t actually attained

  • .Net also protects you from malicious code

    • Can peverify code before using it

Exceptions are builtin l.jpg
Exceptions are builtin

  • Very familiar to Delphi programmers

    • Lets you assume that each operation will succeed - chains of operations become simpler and clearer

    • Failed operations jump straight to error handlers, so there’s no risk of acting as if an operation succeeded when it actually failed

  • CLR supports exceptions

    • Can’t hose Windows by drawing on a DC that wasn’t really created - exception on canvas creation jumps around actual drawing code

Clr wrapup l.jpg
CLR wrapup

  • CLR manages memory and code

  • Also supports language neutrality

    • CTS [Common Type System] is part of the CLR

    • CTS is basis for language neutrality

Common type system l.jpg
Common Type System

  • Key to managed code, garbage collection, and language inter-op

  • All .Net languages understand each other’s data types

    • All use the same primitive types

    • Record and object definitions are part of the metadata in each assembly

Slide47 l.jpg

  • Common Language Specification

  • A Visual Basic class can inherit from a C# class that inherits from a Delphi for .Net class

    • The equivalents of is and as will work just as they should, in all three code-bases

  • It’s like a cross-language version of packages

Objects are primitives l.jpg
Objects are primitives

  • The CTS provides value types - scalars and records - and objects, and the ability to form composite types from the primitives

  • Objects are primitives, built into the lowest levels of the system

    • There’s no sense in which they’re something layered onto a flat API

Net object model l.jpg
.Net object model

  • A lot like the Delphi object model

    • All objects descend via single-inheritance from a single root object, System.Object

    • Support for properties, events, and interfaces

  • Boxing and unboxing

    • A System.Object can hold any value

    • Great flexibility

      • Still type safe – just a lot less busy work

      • Like variants, but cleaner

Delphi objects l.jpg
Delphi objects

  • In Delphi for .Net, TObject will be an alias for System.Object

    • Otherwise, TComponent wouldn’t be a System.Component, and Delphi components couldn’t play in the common language space

  • But they are not equivalent

    • TObject has no ToString()

    • System.Object has no ClassName

Helper classes inject functionality l.jpg
Helper classes “inject” functionality

  • type

    TServer = helper class(TBaseServer) for TClient;

  • Helper classes can only add methods

    • Somewhat like interfaces, in this way

  • Added methods act as if they were declared in the client class

    • No special syntax to call them

    • Available to descendant classes

Helper classes in perspective l.jpg
Helper classes in perspective

  • They give Delphi code a superset view of the .Net object hierarchy

  • This is fine within Delphi code

    • But descendant classes written in other languages don’t automatically see the methods the helper classes add

      • Have to go out of their way to use them

Delphi interfaces and net l.jpg
Delphi interfaces and .Net

  • .Net interfaces are not reference counted

    • No need for reference counting

      • All .Net data is ‘freed’ by the garbage collector.

    • Makes interface code faster and simpler

      • No more maintaining reference counts on assignment

      • No more implicit finalization

    • Generally a change for the better

      • Does break code that uses interfaces for resource protection

Less interface use on net l.jpg
Less interface use on .Net?

  • Many programmers use interfaces primarily for their fail-safe nature

    • Objects that you don’t have to Free eliminate a whole large class of possible “failure points”

  • Then they start to appreciate the design ideas that interfaces promote

  • Fewer people may do this when raw objects are fail-safe

Interface design principle 1 l.jpg
Interface design principle #1

  • Using interfaces increases your code’s distance from implementation details

    • You only know that ‘this’ object can do ‘that’; you don’t know what type of object it is

    • You program to the interface, not the implementation.

Interface design principle 2 l.jpg
Interface design principle #2

  • Paradoxically, interfaces also ‘specificize’ your code

    • Passing an object reference passes a reference to all its fields and all its methods

    • Passing an interface reference passes a reference to only the abilities you are actually using

Interface design principle 3 l.jpg
Interface design principle #3

  • Getting the semantics right is part of building a clear, reliable program

    • Components and interfaces can be a better model of the semantics of a problem than inheritance

    • Inheritance is a strong, “is a” relationship, while supporting an interface is a weaker, “can do” relationship

    • In concrete terms, this means that you don’t have big, heterogeneous objects

      • Where this group of methods can inadvertently mess up the state that that group of methods depends on

Interface delegation l.jpg
Interface delegation

  • Delphi interfaces work well with components

    • An object like a form can claim to support an interface, and can delegate that interface to one of its object or interface properties via the implements keyword.

    • Among other things, this lets an object change - at runtime - the way it implements an interface.

Interface delegation on net l.jpg
Interface delegation on .Net

  • The CLR requires that all interfaces an objects supports be statically declared

    • It’s not possible to support implements on .Net without a measure of compiler magic

    • As I understand it, current plans are that Delphi for .Net may not do this, at least in the first release

    • Language geeks have lobbied Danny

Properties and events l.jpg
Properties and events

  • .Net supports properties and events much like Delphi does

    • Getters and setters must be methods

    • All events are multi-cast

      • Delphi for .Net will support both multi-cast event handlers and VCL-style singleton handlers

      • Delphi's procedure of object syntax mapped transparently to .Net delegates

More about the cls l.jpg
More about the CLS

  • Common Language Specification

  • CTS is ‘bigger’ than any one language

    • No language takes advantage of all of its features

  • CLS is a subset of the CTS

    • Lingua franca that lets different languages interact

  • CLS is what lets you do cross-language object inheritance

Cls is not intrusive l.jpg
CLS is not intrusive

  • Delphi features like sets and unsigned integers are not CLS-compliant

    • Can still use them in your Delphi code

    • Can export them as part of your cross-language component’s public interface

  • Compiler will warn you

    • Using a non-CLS feature

    • You should provide CLS-compliant wrappers

Case in sensitive unicode l.jpg
Case-insensitive Unicode

  • CLS is case-insensitive

    • Any libraries that ‘natively’ rely on case differences to separate one identifier from another will have to include case-insensitive aliases

  • CLS requires Unicode

    • Good for programmers who don’t think in English

    • ‘Characters’ but not ‘ideographs’

      • No Chinese or Klingon characters in Pascal identifiers

Cts cls wrapup l.jpg
CTS / CLS wrapup

  • CTS is a feature of the CLR

  • CTS means all .Net languages can share data structures

    • CLS is CTS subset

  • CTS / CLS means all .Net languages can use the same runtime library

Framework class library l.jpg
Framework Class Library

  • Thousands of C# classes

    • Not as daunting as it may seem

      • Many are internal, or are only created as method results

      • You directly create only maybe 10% of the classes

  • I can’t cover what is in the library

    • The best I can do is why you should learn it

Learn once work anywhere l.jpg
Learn once, work anywhere”

  • Common runtime library

    • Shared by all .Net languages and applications

    • Delphi RTL wrappings will provide portability between Delphi for Windows and Delphi for .Net

  • Learn the framework classes

    • Useful in Delphi for .Net projects

    • Will also make you a .Net programmer, who can find work in any .Net shop on the planet

Much more than web services l.jpg
Much more than Web Services

  • You’ve seen the dog and pony shows

    • .Net turns all the complexity of XML, SOAP, and WSDL into straightforward remote calls that pass objects between systems

    • Great stuff - but there’s a lot more to the Framework classes than Web Services

  • Cryptography, regex, and more

    • Collection classes that are light years beyond TList

    • Perl functionality with your favorite syntax

You don t need to learn c l.jpg
You don't need to learn C#

  • C# is easy for Delphi programmers to read

  • But you don’t have to learn C# to learn the framework classes

    • Microsoft does not currently provide source to the library code

    • You can’t Ctrl+Click on (say) TObject.ToString and see the implementation

This is the future l.jpg
This is the future

  • Windows API is a set of ‘flat’ function calls

    • “Object like” - create, say, a window or a font and pass the Handle around

    • Learning the API was slow and frustrating

  • Most Windows code uses object-oriented wrappers

    • Mutually incompatible - knowing MFC didn’t help much with Delphi and vice versa

No implementation language bias l.jpg
No implementation language bias

  • Windows (and Linux) penalize you for not working in C or C++

  • Need header translations

    • Have to translate and wrap each new API or wait for someone else to do it

    • Always the danger that a translation might be wrong in some way

      • Pad bytes are wrong

      • Optional parameter might be required

      • Wrong calling convention &c

Net solves these problems l.jpg
.Net solves these problems

  • The framework is object-oriented from top to bottom

    • No more “handles” to pass to an endless set of flat functions

      • You work with a window or a font by setting properties and calling methods

    • Exceptions are built-in

  • Just like Delphi

    • But this is the native API, not a wrapper

Hierarchical namespaces l.jpg
Hierarchical namespaces

  • Framework uses hierarchical namespaces

  • Less searching through alphabetical lists of class or function names

    • System.IO has file functions

    • System.Collections has a better hash table than Perl

Future apis l.jpg
Future APIs

  • Microsoft promises that future APIs will be released as CLS-compliant parts of the FCL

    • Your Delphi for .Net programs can use a new API the day it’s released

    • No need for header translation

    • No danger that the header translation might be wrong

It won t last l.jpg
“It won't last”

  • You might still be skeptical

    • COM was once touted as Windows’ object-oriented future

    • COM made object orientation very complex

    • .Net is a lot better than COM ever was

      • Hard to believe this comes from the same company that gave us COM and the Windows API

Net is plan c l.jpg
.Net is Plan C

  • .Net is good

  • .Net will be with us for a while

Thank you l.jpg
Thank You

You can contact me at

Consulting · Contracting · Analysis