| (2/3) I sputter a bit as I look at the clock on Cutler's desk, smile, and take a seat. To begin the interview, I want to set the context. What was the team's initial vision for an operating system? "We had five or six major goals," says Cutler. He pulls a copy of Helen Custer's book Inside Windows NT from his bookshelf and flips through the pages. Portability, reliability, extensibility, compatibility, performance. I think that's right. Let me see." He goes back to the bookshelf to retrieve a thick black binder. The label on its spine says "NT OS/2 Design Workbook." He flips through some pages. "Here," says Cutler, casually handing me the volume. "Why don't you borrow this? As long as I get it back," he continues. "I think it's one of the only copies left." Four inches of spec Inside the binder, separated by a dozen neatly arranged tabs, are 4 inches of documents that make up the original specification. Dated 1989 and 1990, they bear names like Kernel Chapter, Virtual Memory, I/O Management, File System, and Subsystem Security. Page 1 of the introduction, written by Lou Perazzoli, reads: "The NT OS/2 system is a portable implementation of OS/2 developed in a high-level language. The initial release of NT OS/2 is targeted for Intel 860-based hardware, which includes both personal computers and servers..." I try to keep my expression casual as I set the volume on the table next to me. I know these guys find reverence irritating. I hope it's not raining. How will I get the spec back to my office? Doesn't this binder belong in a museum? God, I hope it's not raining. "Do you think you achieved these goals?" I ask. "We certainly achieved extensibility and portability," Lucovsky says. "We tested ourselves by not doing the x86 version first. We did the RISC (Reduced Instruction Set Computing) stuff first. It would have been so easy to drop the RISC support; everyone in the company wanted to. But the only way to achieve portability is to develop for more than one platform at a time. It cost us a lot to keep portability alive, but we did, and that has made it easy for us to respond to things like Merced," he says, referring to the 64-bit chip from Intel. No embedded semantics in the kernel At every step, Cutler and Lucovsky explain, the team prioritized design. They knew that the code they were building had to last for years. This meant thinking ahead, understanding, for example, that hardware would evolve perhaps drastically. "We tried to create a system that had a good, solid design, as opposed to one that would run optimally on hardware of the time," Cutler explains. "When we started, we were working on 386/20's. At the time that was a big, honking machine. Since our design had to be portable, we didn't allow people to optimize code in assembly language, which is hardware specific. This was hard for the Microsoft mentality at the time. Everyone wanted to optimize code in assembler." The original vision kept the operating system nimble. "We didn't embed operating-system semantics into the kernel," Cutler explains. "So when we switched from OS/2 to Windows, we didn't take a major hit. If we had built OS/2 threading or signals into the kernel, we would have been in trouble. Instead we built the OS in layers and created subsystems to handle OS/2, Windows, and POSIX." Not everything can top the list But the original vision also required tradeoffs. The team's engineering philosophy was to focus on one major area at a time. "That's why we wrote a spec," says Lucovsky. "The way we see it, write down what you're going to do, and then execute on it. Don't stand around dreaming, telling yourself, 'Wouldn't it be nice if' We spelled out what we planned to do right there," he says, pointing to the spec sitting next to me, "and we stuck by what we said we would do. |