Dave Cutler Talks NT, Cairo, and More (UPDATED)

Dave Cutler

UPDATE: The full 3-hour (!) interview is now available here. It will take me a while to get through this, but I will. –Paul

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

There is no person more important to the history of Windows than Dave Cutler, and yet he has almost never granted interviews with the press, forcing us to learn of his shared history with NT from others. Well, that just changed: Former Microsoft engineer Dave Plummer—the original author of Task Manager, among other accomplishments—has interviewed Cutler, and he is somewhat cannily publishing small clips from that interview each day on his YouTube Channel Dave’s Garage. These interview clips are incredible for all the obvious reasons, but they are also rewriting our understanding of the history of NT, Windows, and more. And anyone who reads this site will want to watch them all.

Or, at the very least, read this synopsis of the key bits of new information I’ve learned from Cutler. Information that may need to make its way into Windows Everywhere, my book about the history of Windows. Here’s what I’ve learned so far, and I will update this article as needed as Plummer posts new clips.

Cutler created software products, not brands

If there is a theme throughout these interviews, it’s that Cutler often has no clear memory of specific products that came out of the source code that he and his team made. This demonstrates how focused he was on his work and how disinterested he was—and remains—in marketing and brands.

For example, he once notes that “people often ask about Longhorn, and I believe that was the precursor to Vista, or it became Vista, or it was along the way,” which seems like an incredibly strange thing not to know given that he architected the platform. But he also refers to the client versions of Windows as “Workstation” repeatedly, the name that had been used when the product line was NT. And he doesn’t remember the name of Windows XP Service Pack 2. And so on, you get the idea.

Unix, Xenix, and … OS/2

In Linux-Xenix-Unix vs OS/2 and Windows: Dave Cutler Interview, Cutler explains how Windows became the default (and the sole) OS personality for NT. Granted we know the high-level version of this story, already: Windows 3.0 and 3.1 were huge successes, Microsoft divorced IBM and OS/2 with it, and NT would form the basis for Microsoft’s operating systems going forward.

But before getting to that point, Microsoft already had a UNIX variant of its own called Xenix, in the pre-Cutler days. Had the company gone with that OS, things might have been very different.

“[Microsoft] did the Xenix thing, and there’s one piece [it] that was genius,” Cutler said. “They had to get a [UNIX] license from AT&T, and so they said to AT&T, would you consider doing a volume license for us? Because we bought more licenses and it was cheaper. AT&T says yeah … and what Microsoft then did was sub-license, they sold their licenses to other people and made the difference. They had a big business going selling Xenix licenses.”

As for OS/2, the joint Microsoft/IBM project that was supposed to replace MS/PC-DOS, Cutler tells the familiar story of the clash of corporate cultures, but adds an interesting wrinkle: The problem with OS/2 then was that it was 16-bit and much of it, including the HPFS file system, was written in non-portable assembler code, and Microsoft’s Nathan Myhrvold learns about RISC processors and decides it’s the future. And that OS/2 code will not port to RISC, it was not portable.

“I told Microsoft that I would not work with IBM,” Cutler said. “They can comment on the design or whatever but I’m not working with them. As it was, they’d come in and they’d review every once in a while and produce their review comments and they were super-negative. And they had actually split off and did a 32-bit version of OS/2 which quickly went right [right down the tubes]. The guys from IBM who reviewed the code for NT were AIX [UNIX] guys from Austin.”

NT’s charter was that it would be a portable operating system that would run multiple environments, and OS/2 Presentation Manager was originally going to be the default personality. At the time, everyone was hyped up about POSIX, [it] was going to unify the UNIX world … We thought that the way to [run multiple environments] was to have the nucleus of the system provide the basic services of the system and then they could be customized for these different environments. Now, that’s kind of a naive view in a sense because there’s a lot of things that wouldn’t be very easy to do that with, things like thread scheduling and stuff like that, it gets kind of sticky. The process structure gets a little sticky, and paging gets a little sticky. But that’s where we started.”

But of course Microsoft also had this thing called Windows. That no one cared about through its first two or three versions. But when Windows exploded in popularity in the early 1990s, it was obvious that NT would adopt it as its primary personality. That history is well-understood, but for his part, Cutler says that while he actually did work on OS/2 briefly, he never used it.

“We were developing NT on OS/2,” he said. “And we couldn’t wait to dogfood, to get off of OS/2. It was abysmal.”

By the way, it’s not clear why “Linux” is in the title of this video.

Cutler’s NT team sent cardboard coffins to Sun’s Scott McNealy and IBM’s Lee Reiswig

As Cutler explains in The time Microsoft sent coffins to competitors: Dave Cutler Interview, the NT team was irked by public comments made by McNealy and Reiswig and decided to retaliate. McNealy, for example, had brought a dog out on stage at a public appearance and it urinated on a fire hydrant that had the Microsoft logo on it.

To respond, the team found some miniature black cardboard coffins to which they added the sound module from a birthday card that played the song “Imperial March” from The Empire Strikes Back, a retail license for their respective operating systems, and a fake dog turd. And then they had them delivered to the two executives with red roses.

At this point in time, Microsoft was in legal trouble over MS-DOS, and Jim Allchin had come down to tell the NT team that Microsoft, as a matter of policy, was going to clean up its act and stop acting so aggressively towards its competitors. And he happened to make this visit at the time that Cutler and a few others were recording an internal video about the coffins. Allchin tells the team that they cannot show this video, and more importantly, that they cannot deliver those coffins.

“I said geez, that’s too bad Jim, we already sent them,” Cutler responded.

Cutler’s NT team defeated Allchin’s Cairo team

In Windows Tukwila 3.99 and Windows Cairo – Dave Cutler Interview, Cutler discusses some of the key NT work that occurred between the initial release and Windows 2000. And key among the initiatives of that era, of course, was Cairo, an NT offshoot that I wrote about in my Programming Windows series and then updated for Windows Everywhere. There’s some great history here, but the key thing to know going in is that Cairo was championed by Jim Allchin, who was hoping to create a next-generation, object-oriented operating system while Cutler’s team was more being more programmatic and worked to bring the simpler Windows 95 user interface to NT.

(Also worth knowing: “Daytona” was the codename for Windows NT 3.5, “Tukwilla” was the codename for Windows NT 3.51, and “SUR” or “Shell Update Release” was the codename for Windows NT 4.0.)

“Behind the scenes, what happened was [Microsoft] hired [Jim] Allchin, he came from Banyan, and Bill [Gates] was big on him,” Cutler said of the beginning of this era. “Allchin had these grand ideas about building his user interface and Cairo and everything, [but] Windows 95 had brought out that interface [first], and it was pretty popular. And you know we [on the NT team] wanted to bring that over to NT. [Allchin said] No, we have to take it to Cairo.”

Cutler convinced Allchin they could do both: He would port the Windows 95 user interface to NT in the Tukwilla release [which never happened, it landed in SUR/4.0 later] while Cairo could push forward with the more sophisticated and object-based Cairo UI.

“I don’t know why he bought this story, but he [did],” Cutler added. “We would put priority on getting Cairo out of the build lab first and then get the rest of it out. And it turned out that Tukwilla just came out every day and Cairo was always broken. Little by little, the Cairo features didn’t get done and they never did one of the things we did with NTFS where we said, you guys can change the file structure as many times as you want, but you can’t stop people from booting old systems and using old file structures. You have to either do an upgrade in place or you have to accept the old stuff.”

In other words, Cutler forced the NT team to “eat its own dog food” by running on their code in development. But the Cairo team did not, and it never successfully built the product let alone got it ready for production.

“Those guys kept promising and promising, but they didn’t get the burn-in right and eventually they missed a date, so he [Allchin] said, OK, OFS (the Object File System) is gone. So little by little, these features, they just never delivered, and they just never delivered. And Tuckwilla just kept growing and growing and growing, and eventually, the two things that I can remember that we really brought over [from Cairo] were the file server software that replaced the NT one and Kerberos. Those are the only two things [from] Cairo, everything else was junked, completely junked on the floor. It just wasn’t there. I just don’t think that the whole project had the focus and the desire to make it really great and it just fell by the way because you know, on the other side of the fence is the NT group. And they’re not letting up, they’ve got they’re full on the throttle.”

Windows XP contained the worst quality source code that Cutler had ever seen

Cutler, a software coding purist, never hid his disdain for Microsoft and its products when he came to the company, and he continued to be unimpressed with the quality of the source code that other groups at Microsoft had created after he arrived. In the misnamed Windows Longhorn and the Worst Code I’ve Ever Seen: Dave Cutler, he tells the story of one of these codebases, which was at the time competing with the much cleaner and more secure code his team was then making.

This is a fascinating bit of history.

Windows 2000 Professional (previously Workstation) and Server were built side-by-side on the same codebase. But when that was completed, the people in charge of each had vastly different ideas about the schedule. Dave Thompson, who Cutler says was in charge of Server, informed Chris Jones, who Cutler says was in charge of client, that the next Windows version would need three years of development time. But Jones said he couldn’t live with that: Consumers didn’t expect the same level of quality as Server and his team could release a new version in 18 months. And so Microsoft split the codebase, with the Server team doing its thing and the client team doing different work.

“It wasn’t long before the consumer software hardly would build and hardly would run,” he said. “In the meantime [in] the Server branch, we fixed a whole bunch of security problems, and none of that stuff was fixed in the [client branch]. Well, we finally shipped [Windows] XP and it was wildly successful. But then it was also buggy, there was a big turmoil about security and so we stopped [development to fix the problems, as described in Programming Windows: Trustworthy (Premium)].”

The problem? That same team used the buggy client code from XP as the code base for Longhorn instead of using the more secure Server codebase. Coincidental to this, Cutler had started working with AMD on the x64 platform that today forms the basis for modern Windows. And it was so good that Cutler simply decided on his own that this was what Windows would use going forward. So he tells both teams that Microsoft is going to create a “64-bit workstation” (later called Windows XP 64-Bit Edition) and a 64-bit Server based on the AMD x64 architecture.

This presented a problem for the Longhorn client team, not that it bothered Cutler, as he referred to that product as “Does-it-matter-horn” anyway. Jim Allchin, who is leading the Longhorn effort, and happened to be Cutler’s boss, is concerned about this side-effort. But Cutler and his team created an x64 client of such high quality using an emulator that it booted and ran fine on the first x64 hardware they received.

“The Longhorn guys just couldn’t get Longhorn out of the build lab, and I tell Allchin, this is this baloney, you guys should switch the code base to the x64 code base,” Cutler recalls. “And eventually that’s what we did. So I unified them [the Server and client teams] back again.”

But before that could happen, Microsoft was right in the middle of its Trustworthy Computing push, and so Cutler’s team finally got to look at the XP source code. His team fixed 5,000 bugs in the code, he recalls.

“We went through everything, and we went over some code that, you know, it was like a shovel you use to turn over manure,” he said. “I think the worst code I probably looked at was the IME code, it was just terrible … We just couldn’t fix [the bugs], we tried to mitigate them as best we could, but we couldn’t fix them. There was a release of XP that was an update that was like a 250 MB dump [Windows XP Service Pack 2] and then they switched the code base for Longhorn to the x64 code base.”

“And that’s the codebase we’re on today, and everything is still unified.”

Tagged with

Share post

Please check our Community Guidelines before commenting

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC