Posted on 04/13/2004 8:17:52 AM PDT by amigatec
The Structural Failures of Windows
Not quite baling wire
By : Tuesday 13 April 2004, 08:44
It's unfair to make such an accusation without backing it up. Because I have some knowledge of the history of operating systems, I'll now take on the duty of demonstrating the architectural flaws, and a bit about how they got there. Before starting, I'll also state that there isn't a flawless operating system out there, just some that have poor or weak architectureâ??and some that given history, appear to the jaundiced eye as more potentially stable.
To know Windows, you must know history. History goes back in microcomputing to minicomputer operating systems, and Windows can trace its roots to the Mac, OS/2, CP/M, and prior to the CPM, DEC's RT-11â??which is where much of CP/M's thinking came from.
In the pre-graphical user interface days, Xerox's Palo Alto Research Center had come up with some brilliant ideas about the differences between textual interface use and iconized or metaphorized graphical imaging as a substitute for the legacy of the text-only computing world. This stuff was great in many ways, and the research became manifested in SmallTalk, an unreal world operating system that metaphorized and objectized many methods of relating to what had become a jumble in computing.
Windows was a contender in a race with other GUI-based systems. Many of the early GUI makers simply burned out. Gone are last-gasps such as VisiON, GEM, and later, DESQView. Twenty-years ago, in 1984, arrived the lowly Mac. The Mac had a closed environment, and users weren't to fool with the innards. There was a SCSI bus port on the Mac, and networking (albeit a 'phone-wire' net at a whopping 75kbaud) was built-in. Yet the Mac took on many of the ideals of PARC's research, after a disasterous undertaking its first carnation of the ideals as manifested in the Apple Lisa.
The Intel-based original IBM PC ruled the world in microcomputer architecture. This was a computer with a club jacket rather than the screwdriver fancier's Apple II. But IBM had foolishly published both a hardware (the IBM XT Hardware Reference) manual and full architectural standards for the PC, so that they could be copied after a fashion by anyone that knew the difference between a push, a pull, a JMP, and a live hand grenade.
So, summarizing so far: the IBM PC dictated hardware architecture because it could be easily copied (oh yeah: they forgot to copyright the artwork on the IBM PC motherboard), everyone struggled with GUIs and what they should meanâ??except for Apple, who closed their design and became the GUI standard to beat. Apple didn't have many hardware makers to accommodate, just themselves.
The Hardware Mosh Pit
Intel's 80286, 8088, and 8086 were nice, if somewhat crippled CPUs. Memory-wise, they required strange hardware and compromise to see the full memory address of the CPU. Until the advent of the 80386, it was impossible to do meaningful task switching. Pre-emptive multi-tasking would allow processes to run in parallel, and allow different applications to do different things simultaneously (within the confines of the Von Newman machine that all PCs are designed around). Intel found that extra money could be made by selling a math-coprocessor, too. It would take until the 80486 family before serious math could be done on a single CPU.
OS/2 was envisioned as the OS that could take advantage of multi-tasking and multi-threading to unite the worlds of Microsoft and IBM and Intel. This marriage didn't last very long, but it produced OS/2â??which for all of its madness, was unbelievably reliable. The problems was, that OS/2 would run on IBM hardware (which by this time was sporting a proprietary bus) and Microsoft would ostensibly port things to other hardware worlds where combinations were staggeringly wild and wooly (and full of equally proprietary buses, and so on).
Stacks of 5-1/4" floppy diskettes with OS/2 from Microsoft sit in the hallowed corner of my office in a stack that we call "the dead worlds". Microsoft and IBM would soon come to blows, and a divorce ensued. Microsoft then resurrected its Windows 2.0 for 'consumers' as a 'bridge' application for those that would wait for its version of OS/2 (that is to say Windows with the good OS/2 multi-tasking multi-threading bits) which was called Windows New Technology or Windows NT.
Two Windows branches were made, one with 'NT' and one with the extensions of Windows 2.0 that became Windows 3.0. Windows 3.0 really didn't work, but it did something phenomenal that hadn't been needed in the closed-hardware world of Macs: it produced a methodology where hardware vendors could glue their bits to Windows in an enhanced way via code snippets called drivers.
How driver code standards were made and how Windows connected drivers to the operating system is the first major flaw of Windows, because driver code, while developed in 'guidelines' and 'partner programs' and other ways, caused huge destabilizations because of the rapid pace by which Microsoft had to evolve Windows if Windows was going to continue to work. Drivers weren't entirely stable pieces of code, and there was great difficulty in integrating them.
The second summary: While Macs evolved slowly, the IBM-Microsoft divorce forced Microsoft to fork development of Windows into two areas, desktop and 'NT' Windows. IBM would carry on OS/2 development for years, but had perceived proprietary hardware sales goals in mind that would prevent OS/2 from garnering cross-platform hardware sales support. OS/2 profits weren't the goal for IBMâ??hardware profits were. Microsoft, by contrast, rarely sold much hardware and knew the business model behind licensing OS to diverse hardware makers.
Windows NT 3.1 differed from Windows 3.X in an important way: the NT kernel took over the entire machine, stem to stern. Windows 3.X, by contrast, ran as an application on top of DOS. DOS itself was the evolution of SB-86, a port by Tim Patterson of CP/M onto x86 platforms; some know it as Seattle DOS.
Windows-on-DOS was an application that was initially designed to run as an application on Intel hardware, and the benefit of Windows 3X was its ability to provide a common platform by which devices and applications could talk to each other in a mature way.
I say mature, because DOS applications were monolithic, and by their nature, couldn't talk to each other. Most every DOS vendor had to figure out how to talk to colour monitors, printers, and other devices. This development effort increased meteorically whenever a new batch of devices came onto the scene needing new drivers. Windows, ostensibly, should take care of the plumbing if an application were written to Microsoft's coding standards, which evolved as rapidly (sometimes more so) than the Windows version numbers and perhaps even the month. All the while, Windows had to continue to run DOS programs.
Microsoft gained more support for Windows because of its accidentally egalitarian method of encompassing hardware devices. Users who'd longed for less headaches (but couldn't part with $$ for Macsâ??that were also perceived as both application and hardware limited) and a GUI that might allow interapplication communication (via rudimentary cut-and-paste) took on Windows on the desktop in drovesâ??even though it really didn't work. Microsoft had also started to back a multimedia platform that consisted of sound, and even a CD-driveâ??both somewhat advanced for the era but well behind Macintosh.
The popularity of LANs increased during this era. Microsoft received little help from what was at the time, the network giant of Novell. Windows for Workgroups emerged, based on primitive, insecure standards of a prior decade (IBM/Systek's SMB). Novell (in my mind) purposefully ignored the NT version, forcing Microsoft to do their own network glue layer which would become a rudimentary authentication system based on Microsoft (with a bit of IBM's technology) LAN Manager.
The third summary: Microsoft's forked development gets populist backing, and Apple's Mac evolution stays at a slow pace, both in hardware and software development. Left to their own, Windows gets networking, but an immature Microsoft starts to make choices somewhat in vacuum due to competitive pressures. Hardware support climbs in Windows via driver glue code, and many vendors hop on the Microsoft bandwagonâ??sensing the parade.
Ah, The Flaws
Compatibility would prove to be the letter of the day for Microsoft. Various programs were developed to allow companies to take their latest peripheral widget and get instant recognition by use of "Windows Certified"-like marketing programs. Ostensibly, once connected to Windows, such a device should be able to play fair and mightily with Windows. Such standards were rarely enforced, and testing was rudimentary. Indeed, with the thousands of peripheral devices emerging in the '80s and early '90s, testing would become nearly impossible to do at any price.
Windows 95, purported prior to its release as a whole new Windows, was found to be just the same old Windows (a DOS application for compatibility reasons) with a whole new problem, and our second major architectural flawâ??the Registry.
The Registry was designed to take the place of what had become an uncontrollable mess-- initialization files or '.ini' files. These files were anarchistic at best, with what had once been the best of intentionsâ??a repository of common settings. The Registry was designed to take the place of these awful proliferation of ".ini" files (which remain to this day) because of the lack of rules concerning them. The .ini files were overwritten at will by the installation routines of applications, or worse, a vendor would cover their bets by placing their known-to-be-sychronized files in places that overwrote known-to-be-working system files. Rules about where files should be placed were ignored, and the ability to keep OS files in sync was confoundedâ??even by Microsoft's installation applications.
Worse, hardware vendors had to support increasing versions of Windows, and often had many different driver files, depending on what version of what was in which version of Windows. Sometimes, one driver would work with one version of Windows, but only with specific combinations of systems files. The mess was up to users (and their administrative help desk personnel, and vendors, and so on) to clean up. Thus began one of the first calcifications of Windowsâ??people became afraid to buy more stuff that might destabilize a working system. Vendors produced bundles of stuff that was known to work together. Change a piece or two, and you were on your own. You still are.
Microsoft included a huge amount of driver files with the operating system, so that the customer experience of adding new hardware would always be matched by having driver files available that were ostensibly suitable for the new hardware installed. But this meant that the driver files delivered with Windows 95 as an example, were already six months or more out of date with vendor driver file releases.
This bodes the third major problem with Windows architecture: Microsoft tried to make itself the repository for driver files for peripherals and did a terrible job of it. To this day, Windows comes with a huge number of unneeded and incredibly out of date driver files, patched to security levels of decades gone by. Internet-found driver updates at installation time are rare and often unused today. Instead, virtually every experienced Windows user knows to get to the Internet quickly after a new installation to get the latest driver updates, software patches and fixes, and whatever else is needed to keep the house of cards from collapsing.
Summary number four: Microsoft's anarchistic platform allowed drivers to go out of date easily, and Microsoft managed driver and system operating files miserably. The resulting combinations were destabilized platforms that were horrible to sort out. Worse, a systems database called the Registry was born in frustration to become the central bureau of Windows settings. The threat of the Registry was its accessibilityâ??just like the '.ini' files anyone and any application at any time could change something in the Registry to the user's benefit or to a horrible and final screeching halt.
What Was The Object?
Object programming was designed to make programming easier, and allow code to be developed, then re-used. Several different schools of thought emerged on object programming, and Microsoft came up with their own, in another departure from the rest of the computer industry at the time. In once sense, Microsoft's Common Object Module was an efficient method of wrapping code, data, and methods together; but this method wouldn't interact well with other methods, such as the Common Object Request Broker Architecture, or CORBA. The nature of other object-oriented methods, such as Enterprise Java Beans, is well known as part of the crux of the recently settled litigation between Microsoft and Sun.
The Distributed Common Object Model and its variants, objectify aggregations of components transcendent of Windows platforms. Because of DCOM's construction, the number and type of kernel and OS objects that have privileges that can be compromised has become a long, long listâ??mostly of hacks, compromises, and vulnerabilities.
Networking Made Difficult
Microsoft was caught with its pants down when the Internet arrived. Lacking but a primitive set of drivers for Internet connectivity made from packet drivers, Microsoft developed the Winsock then Winsock2 API set. This somewhat ingenious method of protocol stack interaction with applications initially confounded many when numerous versions of the protocol stack arrived. Microsoft grafted its own browser, rather than license the full deal from the University of Illinois. In doing so, numerous and rapid revisions were released. With major service releases and variants, it's believed that there are over twenty-one versions of Internet Explorer.
The legacy of LAN Manager also provoked the development of connectivity based on peer to peer models, rather than a hierarchical system based on authentication methodologies. LAN Manager was and is a hacker's paradise, and authentications made on LAN Manager can still be used in Microsoft's latest OSâ??although with work a network can be made LAN Man-free.
The Windows NT model of primary and backup domain controllers was equally rigid, and difficult to manage effectively for all but the smallest of enterprises. Some are still in use today, based on the principle of don't break what works.
Architecturally, the Windows NT model can actually work for small and with tonnes of work, larger organizations. Messaging traffic and naming convention problems cause large problems, as does the fact that there are numerous simple problems with the domain model. As an example, it's possible for inter-server process passwords to be accidentally lost, causing authentication problems, to this day in NT systems.
The Active Directory, introduced with Windows 2000 server editions, represented a huge undertaking for many organisations that were interested in collapsing their dicey domain models. This fork-lift upgrade required essentially revamping an entire enterprise's server software infrastructure to gain the benefits of what for some, was their first real directory service.
Novell, whose mature directory services had languished in the midst of severe internal organisational difficulties, threw mighty criticisms towards Microsoft. Some proved true, while others were off-target. Few organisations were ready to change to Microsoft's new server model, feeling as though they were beta-testing the software. Those who did were slowly rewarded.
Summary number five: Microsoft thought of networking as an afterthought. Provoked by competition, they invented their own way of thinking from grafted parts of what worked elsewhere. Focus was on the distributed desktop, and even Microsoft was caught unawares by their own networking growth. Industrial software partnerships were never their strength-- but hardware ones drove their market penetration.
The Converged Kernel
Promised early, was a way for developers to write code once to cover all Windows platforms. The DOS-versions of Windows (3.X, 95, 98, ME) would eventually be converged into NT. The trial balloon for the merger was Windows 2000 Professional, which with a few key feature increases, became Windows XP (with the crippled twin Windows XP Home).
This converged edition had a great deal of backward compatibility. XP runs a staggering amount of programs dating back twenty years. Various options allow a user to run truly arcane applications and games if desired. And that compatibility is also the crux of the architectural problem.
At each upgrade stage, Microsoft has needed sufficient amounts of new applications and features to make people and organizations want to purchase the upgrade. That also means not trashing investments in applications made over the yearsâ??and therefore legacy architectural deficiencies were compromised in a quest to make sure that the upgrade versions appealed to the largest common denominator of individuals that it could to maximize revenues. Maximizing revenues is what Microsoft is about.
And so, in the XP machine are .ini files, a Registry that's a breeze to hack into, and perhaps a copy of Microsoft Office, whose architecture became easily and constantly compromised (from macro viruses forward) Microsoft's forward compatibility became an additional crux of architectural malaise. Embedded into each new edition of Windows has been the sins of Microsoft's past mistakes, patched, soldered, and puttied with goo.
Gone, Just Gone
Windows NT was designed to be an egalitarian operating system, but it hadn't turned out that way. It would run on Intel hardware, and it would eventually also run on MIPS, the DEC Alpha, and the PowerPC chip. But not for many versions, all but the Intel family (and clones) fell away.
Microsoft would also try to seduce Unix developers onto Windows platforms by adding various components and analogs of Unix components onto and into Windows. Few Unix programmers would take the bait. Architecturally, Windows as a few roots from Unix, just as DOS did.
Windows added in features that were Mac-like, too. Directories became folders, and the parlance of Windows became Mac-like over time, as well.
But the deficiencies remain to this day. Until the dreaded XP SP2 arrives, most apps will be able to get charge of Windows and do with it what it will. Although the service pack is dreaded for the malformed apps that will break (and there are many), there's light at the end of the tunnel.
Microsoft won't stick its neck out and kill Windows with Longhorn, nor will they cannibalize their revenues making the world wait for Longhorn or a re-write of Windows. Instead, we'll all be using the prophylactics of a firewall system on both desktops, servers, mobiles/PDAs, and so on. The cure is the prophylactic, not the cure for the weaknesses themselves. Look for increasingly smarter prophylactics rather than core cures.
And so, we'll live with Windows legacy for a long time, perhaps, unless we change over to something else. My 'something else' is Darwin BSD running in disguise underneath the Macintosh's OS/X. Finally, someone had the guts to release a possible virus for OS/X. I eagerly look forward to moreâ??just to keep me on my toes. µ
Dr. Von Newman the world renowned arachnologist? Quite the expert this author.
Windows has an architecture? Bwahahahahaha! Last time I checked it was a bunch of crap descended from windows 3.1, glued to a bunch of other crap (api's) they either stole or borrowed. Then they tried to make it object-oriented. Then COM. Then .net/.not. It is the very definition of the word kludge.
Nuke it from orbit, start with a clean sheet of paper.
So?
Taking a narrow view of functionality, however, is rather ignorant.
Not to me -- I can use it without difficulty, which makes me happy, and Microsoft rich. Can you say the same for all of those OSs that were there prior to Microsoft's efforts?
I'll not dispute that there are design shortcomings in Microsoft's OS, just as there are design shortcomings in every OS. But again: aside from the ideological anti-MS stance (which seems to feed this sort of article), who cares?
Go to the SANS Institute's Reading Room and note the difference in list lengths between Windows Issues and Linux Issues.
When Linux is operating on as many millions of machines as Windows is, I'll be impressed if the Linux side of the ledger is as short. Until then, however, I'll chalk it up to Linux not having been through operational testing, as Windows has.
Macs are von Newman machines, PC's are Harvard Machines with Stacks!
Eh?
It is supposed to be von Neuman. John von Newman developed the theory for computer architecture in 1945.
"Oh, man, I just ride in 'em. I don't know what makes 'em work."
Oddball, "Kelly's Heroes"
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.