Transcript www.midnightbeach.com

.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
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 objectoriented 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
FCL
Framework Class Library
CTS
Common Type System
(CLS)
CLR
Common Language Specification
Common Language Runtime
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
• .Net has two main parts
•
Runtime
•
•
Written in C++
Framework classes
•
Written in C#
• Components and applications
•
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
• ISO standardization
•
Coming this month
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
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
Before JIT
After JIT
Stub
code
CIL
Object
code
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
• 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
• 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
• 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
• 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 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
• 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?”
•
•
“But, what about that JIT overhead?”
•
•
Language neutrality
It’s just not that bad
“Garbage collection sucks.”
Garbage collection doesn’t suck
• Many nice features
•
Fast allocation
•
•
Better cache performance
•
•
Consecutive allocations are adjacent
Smaller, simpler, and more reliable code
•
•
Just advancing a pointer, not updating a linked list
More object-oriented, without ownership issues
No dangling pointers
•
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 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
• Get moved and promoted
•
The next collection at old level won’t look at them
Before generation 0 garbage collection
Generation 0
Generation 1
A
B C D
E
F
G H
I
J
After generation 0 garbage collection
Generation 1
A
B C D
F
G
J
free
K
free
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
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
• 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
• 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
•
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
• 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
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
• 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 You
You can contact me at
www.midnightbeach.com
Consulting · Contracting · Analysis