Last month I received an e-mail message from a reader who wanted to know why most of the articles in this series have focused on Windows. It was not so much that the person who sent me the message hated Microsoft, or preferred Linux, or anything like that, but wondered why Windows was necessary. As he correctly pointed out, networking has been around since long before Windows. To make a long story short, I thought that the message made a good point, so I wanted to take the opportunity to talk about the role that Windows plays in networking.
Before I Begin
Before I get started, there are a couple of things that I need to say up front. First, I am going to be spending some time talking about the early days of Windows. There are a lot of rumors alleging that Microsoft “borrowed” parts of the Windows Operating System from companies like IBM and Apple. Personally, I do not know if these rumors are true or not, and to be perfectly frank, I do not really care. I just wanted to acknowledge the point up front in an effort to reduce the number of e-mail messages that I receive in response to this article.
The other thing that I want to clarify up front is that today, every operating system implements networking in roughly the same way. Although one operating system might be more efficient than another, the end result is basically the same. After all, it is no coincidence that Windows, Macintosh, Linux, and UNIX can all communicate across the same Internet, using the same protocols.
By writing about Windows, I am not trying to start an operating system war, as I seem to have inadvertently done so many times in the past. I just choose to write about Windows because it is the most commonly used operating system, and articles about Windows would therefore theoretically benefit the largest number of people, and this is primarily a Windows focused website.
What Windows did for the World?
Now that I have hopefully appeased most of the haters, let us get down to business. The reason why Windows became such a dominant operating system was because it solved two major problems that plagued the IT industry.
The first of these problems is that prior to the creation of Windows, PCs were relatively difficult to use (at least for the lay person anyway). Prior to Windows 3.x, most PCs ran a Microsoft operating system known as MS-DOS. DOS was an acronym that stood for Disk Operating System.
The DOS operating system actually worked pretty well, but it did have some serious shortcomings. For starters, the operating system was text based. This meant that if you wanted to launch an application, you could not just point and click on an icon, you had to know the command or commands needed to launch that application. If you wanted to know how much free disk space you had, you could not just right click on a disk icon, you had to use the CHKDSK or DIR command.
The average person was intimidated by DOS. After all, using DOS even for the basics required learning quite a few commands. Many of those commands could do significant damage to your data if you accidentally used them incorrectly, so that added to the problem.
There is no denying that PC use was already becoming widespread before Microsoft introduced the graphical operating system, but Windows helped to make PCs much easier to use.
The second thing that Windows accomplished was far more important. Windows provided a level of abstraction that allowed device drivers to be separated from applications.
In the days of DOS, it was an application developer’s responsibility to include device drivers as a part of an application. For example, when I was in high school, the best word processor on the market was a now defunct product known as PFS Write. One of the things that made PFS Write such a good product was that it supported numerous printers. Even so, I recall purchasing a copy and installing it onto my computer, only to find out that it did not include a driver for my printer. As a result, I had to buy a new printer, just to be able to use a word processor.
Keep in mind that my previous printer was not junk. The problem was that most applications at the time shipped on floppy disks, which had an extremely limited capacity. As a result, application developers would typically only include drivers for the most commonly available hardware. At the time, it was not at all uncommon to find that some applications (especially video games) did not support particular video cards, sound cards, etc.
The way that drivers were tied to applications was bad for both application developers and for consumers. It was bad for application developers, because they had to spend time writing a zillion device drivers, which increased development cost and increased the amount of time that it took to get their product to market. Because an application could only support a limited set of hardware, the developer inevitably alienated some would be customers by not supporting their hardware.
Having device drivers tied to applications was bad for consumers as well. Typically, older hardware was not supported, often forcing consumers to purchase new hardware along with their new application. At the same time though, cutting edge hardware was not usually supported either. Application developers needed to create drivers that would work for the largest number of people possible, so it was rare for an application to contain drivers for the latest hardware. Often the new hardware was backward compatible with device drivers for older hardware, but it might take years for the cutting edge hardware’s full potential to be widely utilized by applications.
When Microsoft created Windows, they created an environment in which any application can interact with any hardware. Sure, applications still have minimum hardware requirements, but hardware brands and models do not really matter anymore. For example, if I wanted to print this document, it would not really matter what kind of printer I have, as long as I have a printer driver installed.
Windows is built in layers. Every Windows application generates print jobs in exactly the same way, regardless of what the application is, or what type of printer the job is being sent to. The Windows operating system then uses the specified print driver to translate the job into something that the printer can understand. The actual process is a little bit more complicated than this, but I wanted to convey the basic idea rather than going into a lot of boring architectural details.
The point is that abstracting applications from device drivers helps everyone. Application developers no longer suffer the burden of writing device drivers, and consumers are now free to use any hardware they want (so long as it meets minimum standards) without having to worry about whether or not it will work with a particular application.
As you can see, Microsoft was able to design Windows in a way that allowed applications to be abstracted from device drivers. In the next part of this article series, I will continue the discussion by showing you how this architecture assists with networking.
No comments:
Post a Comment