A Programmer’s Introduction to C# 2.0(Third Edition)

A Programmer’s Introduction to C# 2.0(Third Edition)


ERIC GUNNERSON AND NICK WIENHOLT


The .NET Runtime Environment

In the past, writing modules that could be  called from multiple languages was difficult. Code 
that’s written in Visual Basic can’t be called from Visual C++. Code that’s written in Visual C++ 
can sometimes be called from Visual Basic, but it’s not easy  to do. Visual C++ uses the C and 
C++ runtimes, which have specific behavior, and Visual Basic uses its own execution engine, 
also with its own  specific—and different—behavior.
And so the Component Object Model (COM) was created, and it has been pretty successful 
as a way of writing component -based software. Unfortunately, it’s fairly difficult to use from 
the Visual C++ world, and  it’s not fully featured  in the Visual Basic world. And therefore, it was 
used extensively when writing COM components but was  used less often  when writing native 
applications. So, if one programmer wrote some ni ce code in C++ and another wrote some in 
Visual Basic, there really wasn’t an easy way to work together.
Further, the world was tough for library providers, as no one choice would work in all 
markets. If the writer thought the library was targeted toward  the Visual Basic crowd, it’d be easy 
to use from Visual Basic, but that choice might either constrain access from the C++ perspec-
tive or come with an unacceptable performance penalty.  Or, a library could be written for C++ 
users for good performance and low-level access, but it’d ignore the Visual Basic programmers.
Sometimes a library would be written for both types of users, but this usually meant some 
compromises had to happen. To send e-mail on a Windows system, for example, you have a