The document discusses programming before and during the early .NET framework era. It describes the complexities of developing Windows applications in C/C++ using Win32 APIs and MFC. It also discusses Visual Basic 6, Java, COM, and Windows DNA programming which each had their own limitations. The document introduces .NET as providing a unified development framework across languages, platforms and devices using common runtime, type system and class libraries.

2. Before .NET
 Windows GUI development: Win32 API, MFC, Visual
Basic, COM
 Web development: ASP
 Java – “Write once, run anywhere.”
 Embrace and extend: Visual J++

3. Life As a C/Win32 API Programmer
 Traditional software development for the Windows.
 C developers are forced to contend with complex memory
management and pointer arithmetic.
 It lacks the benefits provided by the object-oriented approach
 When you combine the thousands of global functions
and data types defined by the Win32 API to an already
formidable language, it is little wonder that there are
so many buggy applications floating around today.

4. Life As a C++/MFC Programmer
 C++ is an object-oriented layer on top of C.
 Programmers benefit from the famed “pillars of OOP”
(encapsulation, inheritance, and polymorphism).
 Microsoft Foundation Classes (MFC) provides a set of C++
classes that facilitate the construction of Win32
applications.
 It wraps a “sane subset” of the raw Win32 API behind a number of
classes, magic macros, and numerous code-generation tools
(wizards).
 Regardless of the helpful MFC, programming for Windows
using C++ remains a difficult and error-prone experience

5. Visual Basic 6.0 Programmer
 Ability to build complex user interfaces, code libraries,
and data access logic with minimal fuss and bother.
 VB6 hides the complexities of the raw Win32 API from view
using integrated code wizards, intrinsic data types, classes,
and VB-specific functions.
 Not fully object-oriented
 No “is-a” relationships between types (i.e., no classical
inheritance)
 No multithreaded applications unless you are willing to drop
down to low-level Win32 API calls (which is complex at best
and dangerous at worst).

6. Life As a Java/J2EE Programmer
 Object oriented with syntactic roots in C++.
 Java cleans up many unsavory syntactical aspects of C++.
 Java provides programmers with a large number of predefined
“packages” that contain various type definitions.
 Limited ability to access non-Java APIs.
 Little support for true cross-language integration.
 Not appropriate for many graphically or numerically intensive
applications.
 A better approach for such programs would be to use a
language such as C++ where appropriate.

7. Life As a COM Programmer
 Microsoft’s previous application development framework.
 reusable binary code.
 C++ programmers can build COM classes that can be
used by VB6. Delphi programmers can use COM classes
built using C.
 COM’s language independence is limited.
 COM has no support for classical inheritance).
 COM is extremely complex under the hood.
 The Active Template Library (ATL) provides a set of C++
classes, templates, and macros to ease the creation of
COM types.

8. Windows DNA Programmer
 Microsoft has been adding more Internet-aware
features into its family of operating systems and
products.
 COM-based Windows Distributed interNet
Applications Architecture (DNA) is quite complex.
 Due to the simple fact that Windows DNA requires
the use of numerous technologies and languages
(ASP, HTML, XML, JavaScript, VBScript, COM(+),
and data access API like ADO).

9. The complete maze…
 Completely unrelated syntaxes.
 JavaScript has a syntax much like C, while VBScript is a
subset of VB6. The result is a highly confused
mishmash of technologies.
 Each language and/or technology has its own type
system:
An “int” in JavaScript is not quite the same as an
“Integer” in VB6.

10. .Net, the Rescuer
.NET
OOP JVM
GUI
Web
component-based
design n-tier design

11. .Net, the Rescuer

12. .Net provides
 Integrated environment
 Internet, Desktop , Mobile devices
 consistent object-oriented
 To provide a portable environment
 A managed environment

13. What Is .NET
 .NET is a framework
 New programming methodology
 .NET is platform independent / cross platform
 .NET is language-insensitive

14. .NET is cross-platform
APP.exe
?
Win64 Win32
(XP,2K,98)
WinCE

15. Narrow view of .Net applications
Operating System + Hardware
.NET Framework
.NET Application

16. .Net Framework

17. .Net Architecture
 .NET architecture is:
 multi-language
 cross-platform
 based on the CLR, FCL, and JIT technology
 .NET components are packaged as assemblies

18. .Net Architecture

19. .Net Technical Architecture
Base Class Library
Common Language Specification
Common Language Runtime
ADO.NET: Data and XML
VB C++ C#
VisualStudio.NET
ASP.NET: Web Services
and Web Forms
JScript …
Windows
Forms
Windows
Forms

20. Common Language Runtime
 A common runtime for all .NET languages
 Common type system
 Common metadata
 Intermediate Language (IL) to native code compilers
 Memory allocation and garbage collection
 Code execution and security
 Over 15 languages supported today
 C#, VB, Jscript, Visual C++ from Microsoft
 Perl, Python, Smalltalk, Cobol, Haskell, Mercury, Eiffel, Oberon,
Oz, Pascal, APL, CAML, Scheme, etc.
 Rational is working on Java compiler for CLR

21. The CLR Architecture
Class Loader
MSIL to Native
Compilers (JIT)
Code
Manager
Garbage
Collector (GC)
Security Engine Debug Engine
Type Checker Exception Manager
Thread Support COM Marshaler
Base Class Library Support

22. CLR Execution Model (Narrow)
Code in VB.NET Code in C#
Code in another
.NET Language
VB.NET compiler C# compiler
Appropriate
Compiler
IL(Intermediate
Language) code
CLR just-in-time
execution

23. CLR Execution Model
VBSource
code
Compiler
C++C#
CompilerCompiler
Assembly
IL Code
Assembly
IL Code
Assembly
IL Code
Operating System Services
Common Language Runtime
JIT Compiler
Native Code
Managed
code
Unmanaged
Component

24. How CLR works?

25. CLR based execution
APP.exe
other FCL
components
CLR
JIT Compiler
obj code
OS Process
Underlying OS and HW
Core
FCL

26. Common Language Runtime
 Execution Engine
 Compiles Microsoft Intermediate Language
(MSIL) into native code
 Handles garbage collection
 Handles exceptions
 Enforces code access security
 Handles verification
 Managed v. Unmanaged

27. Implications of CLR execution model
1. Clients need CLR & FCL to run .NET apps
 available via Redistributable .NET Framework
2. Design trade-off…
+ managed execution (memory protection,
verifiable code, etc.)
+ portability:
– slower execution?

28. CLR and JIT compiling.
 Indirect execution of .Net applications.
 All .NET languages compile to the same CIL.
 The CLR transforms the CIL to assembly instructions
for a particular hardware architecture.
 This is termed jit’ing or Just-in-time compiling.
 Some initial performance cost, but the jitted code is
cached for further execution.
 The CLR can target the specific architecture in which
the code is executing, so some performance gains are
possible.

29. Advantages of CLR
 Support for developer services (debugging)
 Interoperation between managed code and
unmanaged code (COM, DLLs).
 Managed code environment
 Improved memory handling
 Improved “garbage collection”

30. Advantages of CLR
 JIT allows code to run in a protected environment as
managed code.
 JIT allows the IL code to be hardware independent.
 CLR also allows for enforcement of code access
security.
 Verification of type safety.
 Access to Metadata (enhanced Type Information)

31. Common Language
Infrastructure

32. CLI

33. Common Language Infrastructure
 CLI allows for cross-language development.
 Four components:
 Common Type System (CTS)
 Meta-data in a language agnostic fashion.
 Common Language Specification – behaviors that all
languages need to follow.
 A Virtual Execution System (VES).

34. Common Type System (CTS)
A specification for how types are defined and
how they behave.
 no syntax specified
A type can contain zero or more members:
 Field
 Method
 Property
 Event

35. Common Type System (CTS)
String Array ValueType Exception Delegate Class1
Multicast
Delegate
Class2
Class3
Object
Enum1
Structure1Enum
Primitive types
Boolean
Byte
Int16
Int32
Int64
Char
Single
Double
Decimal
DateTime
System-defined types
User-defined types
Delegate1
TimeSpan
Guid

36. CTS Data Types

37. Common Data Types
CLR provides a set of primitive types that all languages
must support. The data types include:
 Integer—three types 16/32/64 bits
 Float—two types: 32/64 bits
 Boolean and Character
 Date/time and Time span
 The primitive types can be collected into
 Arrays
 Structures
 Combination of the two

38. Common Language Specification (CLS)
 Not all languages support all CTS types and
features
 C# is case sensitive, VB.NET is not
 C# supports pointer types (in unsafe mode), VB.NET
does not
 C# supports operator overloading, VB.NET does not
 CLS was drafted to promote language
interoperability
 vast majority of classes within FCL are CLS-compliant

39. Comparison to Java
Hello.java Hello.class JVM
compile execute
Hello.vb Hello.exe CLR
compile execute
Source code Byte code
CILSource code

40. Base Class Library @ FCL
Unified Classes
Web Classes (ASP.NET)
XML Classes
System Classes
Drawing Classes
Windows FormsData (ADO.NET)
Controls, Caching, Security, Session, Configuration etc
Collections, Diagnostics, Globalization, IO, Security,
Threading Serialization, Reflection, Messaging etc
ADO, SQL,Types etc
Drawing, Imaging, Text, etc
Design, Cmpnt Model etc
XSLT, Path, Serialization etc

41. Base Class Library
 Similar to Java’s System namespace.
 Used by all .NET applications
 Has classes for IO, threading, database, text, graphics,
console, sockets/web/mail, security, cryptography,
COM, run-time type discovery/invocation, assembly
generation

42. Framework Class Library @ BCL
 Single consistent set of object oriented class libraries
to enable building distributed web applications
(Unified Classes)
 Built using classes arranged across logical hierarchical
namespaces
 Work with all CLR languages
 No more “VBRun” or “MFC” divide

43. Example

44. Intermediate Language (IL)
 .NET languages are not compiled to machine code.
They are compiled to an Intermediate Language (IL).
 CLR accepts the IL code and recompiles it to machine
code. The recompilation is just-in-time (JIT) meaning
it is done as soon as a function or subroutine is called.
 The JIT code stays in memory for subsequent calls. In
cases where there is not enough memory it is
discarded thus making JIT process interpretive.

45. Queries?

46. Contact me via
Mail:
arunprasadnva@gmail.com
arun85prasad@gmail.com
Social network(s) / Services:
arunprasadvidhyaarthi – skype, slideshare.com
Arun85prasad – twitter, gmail, live, yahoo.com
Arun Prasad - facebook, orkut
Arunprasad – scribd.com
Mobile:
+91 93446 20159

47. Thank you !!!

48. Disclaimer
The names of Technologies, Product(s), Companies,
Application(s), Tool(s), Utilities, etc provided with this
material are intended to reference only. The name(s),
brand name(s), trademark(s), registered trademark(s),
logo(s), slogan(s) belong to their respective owners in
the respective countries.