Dedication

 

Introduction

Many years ago, when I was just a shy junior programmer, I had a dream. I dreamt of a (perfect?) world in which I never had to figure out which messages to handle in my Microsoft Windows applications. I often caught myself longing for a time when programmers wouldn t have to search through the hefty Windows SDK tome looking for undocumented functions. I didn t want to research and refine the best way to export functions from Microsoft Visual C++ to accommodate incoming calls from Microsoft Visual Basic applications. As a first-year student at the Windows University, I found particularly hostile the different programming models that Windows tools featured. My discomfort was not a matter of preferring one language over another of course you naturally felt more comfortable with Visual Basic syntax or C++ syntax. The difficulty was more systemic. You had to think of applications in different ways, and then you had to code them to comply with the syntax of each language.

I understand that the most obvious response to this complaint is, OK, but what about using only one language and one tool for all of your development efforts? This suggestion is certainly fair, but unfortunately it only partially applies to the world of Windows programming. In Windows applications, you inevitably use diverse tools to build applications and multitier systems.

Each Windows programming tool is by nature different from the others, conceived in a different environment. The Windows operating system was developed with the C language in mind and ended up being a tough, somewhat dumbed-down model for only the bravest and most patient programmers. Along the way, and not especially quickly, Microsoft realized that there had to be a better way to perform the same functions. Enter Visual Basic, with its attractive object orientation and rapid development features.

Visual Basic, however, was probably ahead of its time. It was based on one of the best ideas in software, but the actual design wasn t as good as it should have been. Several versions of Visual Basic and Visual C++ repeatedly failed to offer a really unique programming model and, more importantly, a common set of objects callable by using the same semantic model. For a certain time, many programmers felt that COM+ could have been upgraded to the rank of Common Windows Run-time Engine. And in fact one of the very early names of what we now refer to as the .NET common language runtime was COM++.

A number of structural flaws in COM and COM+ suggested a complete redesign before the shipment of a run-time environment entirely based on them would be feasible. COM components are raw binaries with a rough model for exposing functionalities, handling events, registering, and versioning, to say the least. Also, COM leaves you responsible for managing the memory clean-up, which is a delicate task. The big picture of COM was great and timely, but it needed a radical makeover to be upgraded. So then came .NET.

.NET seems to fulfill the somewhat childish dream I had as the shy junior programmer in the early 90s. Recall that I dreamt of a common run time for all applications and development tools available under the Windows umbrella. I envisioned a world in which regardless of the language, the programming objects were the same. No more MFC or ATL C++ classes for the Visual C++ programmers and run time COM classes for outstanding Visual Basic programmers. Thanks to the .NET infrastructure, my dream came true.

.NET has cross-language integration and exception handling, debugging and profiling services, enhanced security, more effective versioning, and deployment. It supplies a brand new model for component interaction and the long-awaited common class library the .NET Framework. .NET unifies the programming model, making the language choice mostly a matter of personal preference. Individuals on the same team can use different languages without losing reusability and integration. Just one common, consistent, and elegant class library is available for all .NET applications, and it has nothing of the COM+ quirkiness. Finally, that ingenuous dream came true. I bet that shy junior programmer would have really enjoyed .NET!