Complicated Matters
It was around 1981 when I was first exposed to the internals of an operating system. I had just come back to my technical support job after attending Digital’s RSTS internals class, and I was working on an issue for somebody. I needed to understand how one of the subsystems worked. Since we had the source code on microfiche, I spent most of an afternoon following PDP-11 Macro Assembler code trying to understand the processing flow.
I’ll never forget how mad I got when I saw this instruction, right in the middle of an instruction stream, and just when I thought I was starting to understand what was going on: MOV R5,PC
For those unfamiliar with the finer points of PDP-11 Assembly Language, this instruction copied the contents of Register No. 5 into the Program Counter. The Program Counter is a special register that keeps track of the memory address where the next instruction should execute. Essentially, this instruction was the equivalent of a GOTO statement, except I had no way to tell where it was going. I didn’t know what was in R5 and the developers didn’t bother to enlighten me.
I ranted and raved for hours, and my coworkers spent much of that day trying to calm me down. It turns out I stumbled onto a technique called co-routines. Developers used this technique to save a couple bytes of memory. This was back in the days when 256KB was a big system and 1MB of memory was almost unheard of.
Later on, I learned about VMS and the VAX architecture. Suddenly PDP-11s didn’t seem so complicated. I can still remember projecting little Labelle films on my wall and listening to a narrator describe virtual memory concepts and paging algorithms.
Not only was the VAX architecture more complex, but also the environment in which many VMS systems operated dwarfed anything we ever saw with PDP-11s. We grew clusters that supported dozens of systems, hundreds of applications, and thousands of users. Through those years, I spent less time looking at operating system source code and more time and energy managing complex interactions among applications, operating systems, and politics.
When Windows NT hit the streets, it was time for another mind shift. This time, the central computer infrastructure was no longer the center of the world. We were no longer interested in the details of how an individual Intel box worked. Instead, we cared about domains and mysterious SIDs and the SAM. We upgraded our 10 Mb Ethernets to 100 Mb to accommodate all the network traffic we generated among hundreds of computers spread out all over the place.
Windows 2000 pushes the complexity level up another notch. As of this writing, I’m about half way through a self-paced, online Windows 2000 course. All I can say so far is, wow. It strikes me that what VAX brought to hardware architecture, Windows 2000 is bringing to operating system architecture. VAX tried to solve all the hardware architecture problems of its time, and included provisions for almost any operating system concept imaginable. It looks like Windows 2000 is trying to do the same thing with software. It has everything but the kitchen sink thrown in. I’m reeling trying to keep straight Active Directory, forests, trees, dynamic DNS, domains, sites, OUs, GPOs, groups, and all the other new and revised concepts.
I’ve read many reviews, listened to lots of speakers, and even attended some training over the past few years, but this is my first in-depth, organized tour. Here are a few early experiences. First, it all seems to work. I don’t need to reboot every time I change something, and I haven’t made any systems crash yet. One time I turned on something with DNS I shouldn’t have turned on -- I don’t remember what it was any more. When I tried to turn it off, the window hung. Instead of blindly rebooting, I stopped and restarted the DNS Service. Everything seemed to work fine.
One early caution: Despite Windows 2000’s well thought out application deployment technology, it is still possible for misbehaving applications to cause problems. I installed a version of Laplink on my new laptop and pretty much destroyed it. It refused to boot after that, and I had to rebuild it from scratch.
In Microsoft and Laplink’s defense, neither vendor claimed this application was supported with Windows 2000. I tried it anyway, just to see what would happen.
The training experience this time around is also new, because this is my first experience with online courses. I’ll go into more depth on Windows 2000, online training, and the lab I built to support it in upcoming columns as I get a chance to absorb it all a little more. --Greg Scott, Microsoft Certified Systems Engineer (MCSE), is Chief Technology Officer of Infrasupport Etc. Inc. (Eagan, Minn.). Contact him at gregscott@infrasupportetc.com.