In the beginning there was DOS. And lo DOS was crippled by the 640K limitation and the segmented architecture of the 8086/80286 real mode. To address this problem Microsoft said “let there be int 21h, function 40h. Let there be overlay support”.
But Microsoft saw that this was difficult for programmers to grasp (meaning Lotus had already incorporated this into their flagship spreadsheet product) and said “we need a way to give programmers a way to write overlay code without mucking with interrupt tables.” They proceeded to incorporate overlay support into Interface Manager, which in 1985 was launched as Windows 1.0. And they said, “let us name this overlay support Dynamic Link Libraries so that no one will confuse them with UNIX loadable libraries.”
It was evening, it was morning, the first version of Windows.
But trouble soon began as these DLL files shared the extension of “.exe” with their process counterparts. Worse, these DLLs could not take advantage of the “new” memory addressing capabilities of EMS and XMS. They proceeded to release Windows 2.x and renamed these DLLs with the extension “.dll”. Windows 2.1 recognized EMS and XMS memory, and would wipe clean any attempt by Lotus 123 to utilize that memory space. And Microsoft saw it was good.
It was evening, it was morning, the Windows 2.x version of Windows.
Microsoft continued to utilize DLL technology to expand Windows bloat. But the developers were plagued by the lack of version control as they could not distinguish one version of a DLL from another. And the users named this plague “DLL Hell”.
But Microsoft cared not as they had solved the Intel segmented architecture problem, and implemented “Protect Mode” in Windows. They could now double and triple up the amount of memory Windows could consume, and they saw it was good!
It was evening, it was morning, the Windows 3.x/386 version of Windows.
As Microsoft pondered this “DLL Hell” problem their application team said “Lo! We have this new technology called Object Linking and Embedding (OLE), and we need to specify where Windows might find the correct DLL to load. Lets add to the registry bloat and specify the location of these DLLs.” And Microsoft saw it was good.
It was evening, it was morning, the Windows 95 version of Windows.
But developers still bemoaned the huge learning curve to write OLE support, and clamored for a solution to DLL hell which basically allowed the last OLE DLL registered to win, surprising application vendors with overwhelming calls to technical support. So Microsoft introduced the “new OLE” dubbed Component Object Model (COM) and its versioning scheme. Developers could specify a specific version to load, or a version independent request to load the latest DLL. Since Windows wasn’t slow enough, they added DCOM to allow calls to flood the network and slow by a factor of 10. And Microsoft saw it was good.
It was evening, it was morning, the Windows 98 SE version of Windows.
But Dave Cutler was brooding that developers were largely ignoring his Windows “New Technology” (Windows NT) OS in favor of “those toy OS’s”. Worse, corporate America was slow to adopt NT 3.5, 3.51 and 4.0. So Dave and his boys set out to increase the bloat and memory footprint by orders of magnitude, and to give NT the same look and feel as Windows 95/98, allowing employees to waste time and CPU power playing .wav files and MineSweeper. So DLL hell increased, and developers were forced to use undocumented methods for checking versions of DLLs and COM components.
It was evening, it was morning, the Windows 2000 version of Windows.
Now Microsoft had been sleeping at the switch, and allowed the internet to pass them by. So they declared “behold let us take back the internet and force everyone to switch from Netscape to Internet Explorer. Further, let us solve DLL hell once and for all by allowing websites to send COM DLLs across the wire without regard for security. Let’s also rename these DLLs from COM to ActiveX, and called this new paradigm Distributed interNet Architecture (DNA).” And Microsoft saw it was good.
It was evening, it was morning, the Windows XP version of Windows.
The Microsoft said “Let’s leave our developer base in the dust and introduce a new programming paradigm. Let’s call that new paradigm .NET, and let’s solve DLL hell once and for all by introducing assemblies. Since the registry is already over bloated, let’s create a new bloated database call the Global Assembly Cache (GAC). This will truly solve DLL hell, and allow different versions of DLLs to live in peace and harmony. Let's further make the lives of our developers miserable by introducing new security restrictions which should address the press reports of security holes in our beloved OS.” And Microsoft saw it was good.
It was evening, it was morning, the Windows XP SP2 version of Windows.
But the developers continued to wail about DLL hell. Raw DLLs were blindly overwritten. COM support defaulted to the “version independent” calls for loading DLLs. Assemblies were strewn all about the hard drive or competed for precious space in the GAC. DCOM “local servers” became process shells such as ConHost, SvcHost and RunDLL loading yet more DLLs. Yet security was breached on a daily basis. The most offensive parasites were the myriad versions of slipstreamed DLLs for the C/C++ Runtime (CRT), Microsoft Foundation Class (MFC), Active Template Library (ATL), and other quasi-OS DLLs. And Microsoft saw it was not good…
So Microsoft declared “Behold, we now give you Side by Side (SxS) DLL support, which will definitely absolutely solve DLL hell once and for all. Further, we will introduce and enforce user access control in our newest and spiffiest version of Windows which we will call… Vista. You will cease to use Windows XP, which also supports SxS DLL technology, nudge nudge wink wink.” And Microsoft saw it was good, and pulled OEM support for XP.
It was evening, it was morning, the Vista version of Windows.
But there was a hue and cry from the developer community as they now faced infinite combinations of DLL hell… legacy DLLs, legacy and “new” COM (on which the .NET foundation is built), assemblies, side by side DLL versions, downloaded ActiveX controls, and the inability to control the most simple of tasks without the dreaded UAC message box rearing its ugly head. And Microsoft saw it was not good…
So they went back to the drawing board one more time. This time they had the solution to DLL hell once and for all. This time they could not fail. They decided that declarative programming was the new old thing. Developers could write code in XML which would give developers triggers, setters, properties, events, and commands. They dubbed this new savior eXtensible Application Markup Language (XAML). Any of that “dirty C# code” could be tucked away in code behind files. DLLs would be managed for developers. The end of DLL hell.. and while they were at it, quietly fix all that was wrong with Vista and release it as… Windows 7.
It was evening… a very long evening. Windows 7 is here.
Please wake me up when the morning comes… maybe Microsoft will finally have a solution to DLL hell.
<sigh>
