“What is .NET programming?" : Object Trek: The Wrath of COM"
A Brief History of .NET Programming
The Adventure Continues -->
To best use .NET, one needs to understand how it came to be, the niche that it filled and replaced, and the purpose that it currently serves today. Computer coding styles and languages are constantly evolving. Most of the evolution is driven by user demand and one upmanship among software vendors, but a significant portion of it is driven by necessity.
"Object Trek: The Wrath of COM"
During the height of the PC Clone Wars in the late 1980s, there were manufacturers who attempted to clone one or the other of the industry leaders, the IBM PC and the Apple Mac. Each system offered something the other did not, but Apple initially offered something that seemed that the PC could not have at all. Apple had introduced the GUI. As discussed in the “History” blogs, a GUI required new software architecture, one that was able to perform true multi-tasking. This was implemented in the OS through the use of internal messaging, which in turn invoked interrupt handlers. PC-DOS was not a multi-tasking OS.
Microsoft added a Messaging Layer to PC-DOS with Windows 1.0 to implement the required vectored interrupts needed when it was introduced in 1985. The first version of Windows was not as slick and smooth as the MAC. It didn’t look as good, but you could run more than one program at a time. Integrating a true Messaging Layer into MS Windows did not come until much later when the move away from a DOS towards a true GUI began in the mid-90s.
One thing the MAC could do that MS Windows could not was integrating one application with another. This means importing a spreadsheet into a word processor document only once so that if the spreadsheet updated then so would the word processor document. We take this luxury for granted today, but it was not always the case. The MAC had the edge of using software written by Apple to specifically do so. Lotus 123 and WordPerfect running on the PC could not do it quite as well, as neither of which was written by Microsoft.
1987’s Windows 2.0 saw the introduction of DDE, Dynamic Data Exchange. This breakthrough introduced the technology to allow Windows applications to exchange data dynamically. The introduction of interprocess communication coincided with new releases of Word and Excel that allowed for the dynamic exchange of data just like a MAC. Almost. The active windows were tiled, no overlapping was allowed. Legally speaking, that feature was supposed to be unique to a MAC.
At the heart of DDE was something known as OLE, Object Linking and Embedding. DDE technology can still be found in use in recent releases of Windows. Windows 2.0 still ran under DOS, and most applications of the time ran under DOS. Most software written for Windows came from Microsoft. It seemed that most other folks didn’t know how, nor wished to bother with re-writing major applications. Especially when it looked like Apple would win its’ copyright infringement suit against Microsoft. “Bye, bye, MS Windows. A MAC can overlap windows and Apple copyrights prevent you from doing so.” Wait, not so fast. Microsoft eventually won. Though they lost 4 years; Marketing would make up for it.
The year 1991 was a landmark year in computing. A newer politician to Washington named Sen. Al Gore, Jr. set up the legal stage for an Information Super Highway that introduced technology that was to be “in the public domain forever”, as the legislation read. Microsoft introduced Windows 3.0, which was a dramatic improvement over any predecessors. Microsoft introduced Visual Basic 1.0, which was a dramatic change of direction over BASIC. Both of these products relied heavily on a newly introduced software technology known as OLE, Object Linking and Embedding. But, Windows 3 was not exactly perfect.
1991 saw Visual Basic 1.0 introduced to provide a development environment for true Windows based programs so that a transition away from DOS could begin. Most existing applications ran under DOS. Many simulated a GUI with “windows” created from common text characters. The applications were developed during the heat of the legal battle with Apple, so folks did their own thing. No one wanted to write against code that had a real possibility of being yanked from hard drives and sent to the old obsolete code home. Many of those applications looked rather crude and pitiful compared to a MAC, which made many of them seem grossly overpriced. Visual Basic also introduced the concept of a DLL, a Dynamic Link Library, to the developer.
At the same time, Microsoft released an Application Framework Extension, nicknamed “afx”, but it was better known as MFC, Microsoft Foundation Classes, for C programmers. MFC was an object-oriented wrapper for the Windows API, and required C developers to use the newer extended version of the C language known as C++.
Just when C developers were getting used to the extensions to run under MS-DOS--- which introduced the name change to C+ ---Microsoft added more to their plate with an entire host of new extensions to use with MS Windows and renamed it all C++. Good name that “++” part. It was quite literal. It was huge. Some folks didn’t have enough space on their already crowded hard drives for it. Marketing.
The most annoying change introduced by C++ was the renaming of the most basic and sacred of the C library files from “std.h” to “stdafx.h”. They broke your code base! Now you had to go back in and fix everything just to use C++ with your existing code base. Some folks wanted to drop writing for the PC. Problem was they couldn’t, because there were too many potential customers to sell to.
1993 saw the introduction of Windows 3.1 and Windows for Workgroups, which reduced the number of crashes because of improvements upon OLE. OLE 2 incorporated a new abstraction in the form of a new concept, an object model known as COM, Component Object Model. 1993 also saw the introduction of Visual Basic 3, VB3, which had a big improvement over VB2 introduced a year earlier because it included the Microsoft Jet Database Engine that could read Access database files. When asked about the “2” designation, Microsoft dropped it saying it was still the same technology. Marketing.
The majority of PCs in use were beginning to shift from 16-bit designs to the newer 32-bit designs by the mid 1990s. VB4 was released in 16-bit and 32-bit versions and neither version was exactly 100% compatible with the other. Really. VB4 marked a significant change in the controls used on windows forms. Changing from DOS rooted VBX, Visual Basic Extensions, to OLE enabled controls that used the “ocx” file extension. The Windows Operating System was evolving, as was the development software. Windows applications were coming out that actually had a UI driven by the hi-res graphics instead of a cheesy-clever arrangement of text characters running under DOS.
Microsoft made up for the VB4 debacle by introducing VB5, which produced 32-bit code exclusively. VB5 could import code produced by either version of VB4, 16-bit or 32-bit. VB5 saw user created custom controls based upon OCX, but created through a separate application. Even though custom controls retained the same technology and file extension, you now had to call them ActiveX Controls.
I think they introduced something called Active Desktop around this time, too. Names must have been a marketing thing, not my cup of tea, and thus not for me to understand or question. Windows 95 was original, so I thought. That was better than the 1.0, 2.0, 3.0, 3.1 stuff, which they had been doing. Windows 7, anyone?
Active Desktop added dynamic HTML content from the Web to your desktop. It also consumed too many resources and provided an excellent pipeline for viruses. It was a failure. Turn it off. But, it also made a good argument in defense of Internet Explorer being an integral part of Windows when the U.S. government had sued Microsoft for monopoly violations concerning bundling IE with the OS. See? It was a marketing thing, just like I said.
Microsoft’s response to the explosive growth of the World Wide Web during the 1990s for developers was with the introduction of VB6, which added the ability to create web-based applications. VB6 was considered by some to be the pinnacle VB programming. It could do it all. You could do anything that a C programmer could do. There was nothing to hold you back except a nightmare something or other known as DLL Hell.
The introduction of the dynamically linked libraries had proven to be a rather mixed blessing. Those wishing to write applications that specifically ran under Windows were able to access some of the same binary assemblies that the OS used. Windows 1 and 2 saw a lot of “windows-based” applications that were not true GUI applications. The applications did not use graphics and ran under DOS, just like MS Windows. As result, there was an across the board lack of consistency with the appearance of a “window” from app to app to OS.
Granting access to the same GUI software to generate true graphics instead of text, gave commercial developers a means to create applications with a consistent look and feel. The MAC had been doing this properly for quite some time. But, this access and privilege also created a new problem that had numerous causes. Applications could no longer find the correct DLL from time to time. PCs began crashing to the floor like drunken sailors. The cynically accurate expression “the blue screen of death” came into being.
Commercial applications were written against a specific version of a DLL, and would install a copy of it when the application was installed. If the OS had been updated, the newly installed DLL would “roll back” the OS and cause it to crash. The problem also worked the other way. A DLL could be installed that was newer than what your installed software used. The new DLL may not even contain the methods anymore! The OS was not able to allow for multiple copies of the same DLL, either. This was a problem in more ways than one. It was grave security risk that hackers took advantage of all too easily.
There were numerous hacks and work-arounds, some sanctioned by Microsoft. Others were not, but were inspired by a near desperate sense of self-preservation. One semi-permanent solution that was immediately apparent could be seen in the success of the JAVA “virtual machine” model. The JAVA VM provided a much-needed layer of abstraction and management between the application software and the actual hardware. Folks call this layer in an OS a Kernel. Microsoft implemented this solution in the form of .NET.
Providing a layer of abstraction that was managed by the “OS” was what Microsoft had decided to go for. This would require that developers write code against some form of a “virtual machine” as JAVA did. The end result was the .NET Framework Class Library, FCL, and all of its’ associated components, most important of which is the CLR, Common Language Runtime, that ran the whole show when it came time to run an application.
.NET also introduced a new language that had a lot of the look and feel of C++. The new language was C#, which is pronounced as “C Sharp”. C# bore an even stronger resemblance to JAVA, however. C# was designed to force developers to be explicit in code. One controversial aspect of VB is how user friendly and helpful it can be. The help is a mixed blessing. Everything comes with a price. That and other differences come at a price that some are avidly eager and willing to pay, and some are vehemently against. It’s touchy subject to say the least. Who would have thought that ideological politics and religious fervor could creep into something as benign as programming? I decided long ago to blame it on Marketing again and call it day. It works for me. Blame the sales people because I already know that they are totally innocent. Just ask one.
In the years since its’ first introduction, the FCL has become commonly referred to as the Base Class Library, or BCL. Consider the two terms to be entirely interchangeable. .NET and the FCL/BCL did not really change how Windows worked, but rather it changed how programs worked with Windows. The FCL is just a rather large collection of assemblies, which could be selectively referenced, that is essentially a set of wrapper classes for the most used content found in the older MFC and COM libraries used in the past.
In fact, .NET code can bypass the FCL entirely, through a process known as Interop, and call the old unmanaged libraries and assemblies directly. Most of the older libraries still ship with the latest versions of Windows. But, that will not continue forever. At some point in the future we will find those assemblies being dropped from Windows one by one until they are all gone, or at the very least no longer accessible for Interop in their present form. At least, that’s the way I would do it moving forward.
Rudy =$^(
I dedicate this blog entry in memory of Jeff Spacek, on this day, Aug. 31, 2010. (edit: Dec. 29, 2010 at the new blog web site.)
I had originally intended to include this installment in my “Brief History of Code” series of code blogs as the final chapter, but quickly decided against it for a couple of reasons. I thought this was just a bit to far off-topic from the more generalized commentary in that series of blogs. This discussion was a topic that is more platform, computer language, and OS specific. It didn't seem to really fit the broader view.
The “History” blogs are intended to be an informative and entertaining commentary that masks their true purpose of being a well-disguised glossary. I also realized that I was having so much fun writing it, that it was quickly becoming quite long. Many people have often suggested to me that I should have been a novelist and it was showing. I really tried to be brief. So on that note, I wrote a new "Part 12", which is itself quite brief that you can now see posted.
The final and main reason rings on a more serious note. I was inspired to start a blog because of the meticulous effort put in by an individual in his own blog whom I had only known superficially through the MSDN forums. I never met the individual in person, although I had traded a couple of emails. His goal was similar to mine, which was to help absolute beginners in programming to get up and running.
Jeff made an impact on all who read his blog no matter your level of programming expertise. At least I know it made a significant difference in me. It spurred my mind to imagine the possibilities. Jeff made me realize that I had had a venue to continue my love of teaching in a whole new way. I was writing and editing this installment when I learned of his tragic passing. Within a day or two I realized that it was time to move on from the History blogs. and continue Jeff's goal.
Rudy =$^(
I had originally intended to include this installment in my “Brief History of Code” series of code blogs as the final chapter, but quickly decided against it for a couple of reasons. I thought this was just a bit to far off-topic from the more generalized commentary in that series of blogs. This discussion was a topic that is more platform, computer language, and OS specific. It didn't seem to really fit the broader view.
The “History” blogs are intended to be an informative and entertaining commentary that masks their true purpose of being a well-disguised glossary. I also realized that I was having so much fun writing it, that it was quickly becoming quite long. Many people have often suggested to me that I should have been a novelist and it was showing. I really tried to be brief. So on that note, I wrote a new "Part 12", which is itself quite brief that you can now see posted.
The final and main reason rings on a more serious note. I was inspired to start a blog because of the meticulous effort put in by an individual in his own blog whom I had only known superficially through the MSDN forums. I never met the individual in person, although I had traded a couple of emails. His goal was similar to mine, which was to help absolute beginners in programming to get up and running.
Jeff made an impact on all who read his blog no matter your level of programming expertise. At least I know it made a significant difference in me. It spurred my mind to imagine the possibilities. Jeff made me realize that I had had a venue to continue my love of teaching in a whole new way. I was writing and editing this installment when I learned of his tragic passing. Within a day or two I realized that it was time to move on from the History blogs. and continue Jeff's goal.
Rudy =$^(