Originally Published: Saturday, 27 May 2000 Author: Esko Woudenberg
Published to: featured_articles/Featured Articles Page: 1/1 - [Std View]

Fragmentation of an OS

They point out that even though Linux is a Unix-work-alike system that the GPL license requires improvements to be openly published. (The fragmentation of commercial Unix had no such licensing requirement.) They contend that this open publication results in something akin to the theory of evolution where the best ideas get propagated and the weaker ones abandoned.

There has been a lot written about the possible fragmentation of Linux over the past year.

Many Penguinistas (AKA: Linux enthusiasts) label these articles as FUD. (Communication intentionally created for the sole purpose of creating FEAR, UNCERTAINTY, and DOUBT about products that might otherwise have a fair chance at competing.)

These enthusiasts point at the very few times that "forks" of key open source projects have actually occurred. Invariably either one of the forks becomes dominant (and the other pretty much dies out) or the forks merge the best features of both into a new version somewhere further down the road. They point out that even though Linux is a Unix-work-alike system that the GPL license requires improvements to be openly published. (The fragmentation of commercial Unix had no such licensing requirement.) They contend that this open publication results in something akin to the theory of evolution where the best ideas get propagated and the weaker ones abandoned.

What I would like to do is point out examples of operating system fragmentation that are quite common but do not appear to disturb the mainstream IT press much. They have a different label for it, they call it "DLL Hell." But when you really stop to examine it, a very large part of the Windows family of operating systems is made up of these DLLs. (A DLL is a dynamic link library intended to allow multiple programs to share the same code without having to physically include the code multiple times. Theoretically this saves space in the executable files themselves and in memory in case more than one program that uses a particular DLL are running at the same time.)

So, what's the problem, you ask? It would seem that all you need to do is come up with a clearly defined set of DLL files and document the functions calls that are contained in those DLLs and refuse to let any programs touch or modify them. (Including "traditional" executables as well as macro viruses from documents that are "executing themselves," etc.)

As we all know, the company that published Windows also decided they were going to write applications. Every so often they would decide that in order for their applications to have a "richer" user experience they would need to "innovate," and make changes to the operating system. So when you install their application on your computer it also replaces key DLL files on the system. In marketing speak, they have "enhanced" the operating system for free, giving "added value" to the consumer. (According to Esko they have fragmented the OS.)

Why do I call this fragmentation? Because the operating system behaves slightly different with one set of DLLs than another. So what's the big deal? As long as each application clearly defines which versions of which DLLs it updates and which functions in the DLLs have been enhanced, you might be able to predict the behavior of the OS.... HEY - STOP laughing... It could happen. It might become a great new "innovation" in customer relations.

Examples of applications that do this are IE4, IE5, Office 97 and 2000, Outlook 97, Outlook 98, Project 98, etc. etc.

It isn't only applications that bring about this fragmentation. It is sometimes the design of the OS itself. The "new technology" version of Windows has occasional service updates. Their documentation states that all service updates need to be reapplied after a driver change. (Changing your video driver might "undo" the "service update' to the OS - Fortunately that is also the version of Windows that comes without "plug and pray" so that you're not forced to install "updated" drivers if you don't want to.)

Well, it doesn't stop with applications. This company also publishes development tools. They encourage other companies that write applications to use their development tools. Applications written with these development tools also replace OS DLLs quite frequently. On at least one occasion this company has accused these developers of causing problems with their OS. What did these horrible 3rd party developers do to the OS that was so wrong? (Simply released apps written with the big company's development tools without waiting for the first service update of the development tools to come out first... For details look up the info relating to the Windows "Library Update.")

You would think that the version numbers of the DLLs would help keep things straight. Unfortunately I've seen where a lower version number was released after a higher version number. (Both directly from the big company themselves.)

So next time you're about to accuse your computer support tech of not having a clue. Stop and ask yourself how many different applications have been installed on your system. (Each and every one of these has potentially altered your OS slightly from the "out of the box" behavior) Think of how many service updates, hot fixes, and security patches have been applied to it. Also think of how virus software may have been grafted into it. Each and every one of these can significantly alter the behavior of a particular aspect of the behavior of Windows. Furthermore; interactions between these various deviations from the "out of the box" setup can further complicate things. It's no wonder that computer techs often throw up their hands in frustration and say, "Let's just back up your data and reload..."

I was at a "Security Summit" in a certain rainy state on the West Coast of the United States in January of 1999. (I'd really like to hear from anyone who may have attended the January 2000 version if there was one) At this security summit MS proudly introduced new security profiles that could be applied to their "new technology" version of Windows. However; when the attendees asked them to provide a list of which of their applications would run under which security profiles they admitted they did not know. After repeated requests it became clear that they were unable to provide that information at that time and were unwilling to commit to ever providing that information.

What are you talking about when you have an entity that wrote the OS itself, wrote the applications itself, designed the "security profiles" itself, and still doesn't know which applications will run under which profiles? Furthermore; They refused to find out (even though they have billions of dollars in reserve)...

What do you call that? How about FRAGMENTATION!!! (If fragmentation bothers you, get a running head start and hope you don't get hit by too many of the fragments.)

Close to a year ago I left a position where I supported thousands of these monstrosities and learned more than any sane person should ever have to know about "DLL hell." We used custom-written software combined with incremental/staggered deployment procedures and real-time monitoring to update these workstations under software control with failure rates consistently lower than 2%. Over the years, due to our proficiency in accomplishing this almost every anomaly of every workstation that support technicians couldn't figure out was referred to us. (The others were probably just "reloaded.")

Esko Woudenberg lives in the Big Bear Lake area of the San Bernardino Mountains in Southern California with his wife and daughter. When he is not working on computer(s) he is probably skiing, mountain biking, off-roading, jet-skiing or relaxing. He has been working with computers for about 18 years and using Linux for less than 2 years.

This article is provided under the OpenContent License, and was first shown at osOpinion.