BorCon wishes to thank the following sponsors:

122.Net Architecture

Jon ShemitzMidnight Beach

Introduction• Why people are excited about .Net• Three main sections

• 15% Why .Net?

• 5% A quick run through the acronyms

• 80% A more detailed walk up the stack• Heavy on machinery, no code you can actually use

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

• 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

• .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• 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• 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• 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• .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• 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

• 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

Common Language RuntimeCLR

CTS

(CLS)

FCL

Common Type System

Framework Class Library

Common Language Specification

CLR = Common Language Runtime

• Garbage collection

• Just-in-time compilation• .Net is never interpreted

• 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

• Basic value types

• Type composition

• Type safety

• Objects

• Interfaces

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

events

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

• 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

• Any CEOs can leave the room now

• Two main parts by Microsoft• Runtime

• Written in C++

• Framework classes• Written in C#

• Components and applications by us• Any language

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

• 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?

• 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

OS/X and Linux

• At the US BorCon in May, 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

CIL

• 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

• 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

Stubcode

Before JIT

Objectcode

After JIT

CIL

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

• The jitter can generate object code optimized for the machine it’s running on• Doesn't actually do this, yet

• 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

Industrial strength 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

• 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 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

• It’s easier to emit CIL than it is to generate x86 object code• Great for apps like spreadsheets 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

• 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?

• 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

• 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 memory leaks• Data structures never refer to memory that’s been freed

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

• ‘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?

• 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

• 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 ones that are still in use

• “Garbage collection” is a bad name• Only have to do work on blocks that aren’t garbage

Live blocks

• Get moved and promoted • The next collection at old level won’t look at them

A B C D E F G H I J K free

Generation 0Generation 1

A B C D F G J free

Generation 1

Before generation 0 garbage collection

After generation 0 garbage collection

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

• 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

• 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

• 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

• 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

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

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

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

• 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

CLS

• 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

• 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

• A lot like the Delphi object model• All objects descend via single-inheritance from a

single root object, System.Object• Even strings and arrays

• Support for properties, events, and interfaces

• Boxing and unboxing• An object can hold any value

• Great flexibility• Still type safe – just a lot less busy work

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• 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

• 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

• .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?

• 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

• 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

• 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

• 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

• 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

• 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

• .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

• 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

• 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-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

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”

• 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

• 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#

• 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

• 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

• 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

• 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

• 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

• 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”

• 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

• .Net is good

• .Net will be with us for a while

1.Questions?

Thank YouThis was my first ever

conference presentation –I hope you liked it.

Please fill out the speaker evaluation.

You can contact me at www.midnightbeach.com

BorCon wishes to thank the following sponsors: