tops10 to vms
with the following reading list
- the soul of a new machine, best book about computers ever written?
- showstopper, a kind of follow-on to ‘soul of a new machine’, with more context around dec and its legacy.
- the brain makers, context around utexas, austin, mcc, etc.
- where wizards stay up late the origins of the internet, context around the utexas dec10 and arpanet.
- the chip how two americans invented the microcip, plenty of info around texas instruments and mcc.
the first two items spur interest in vax and vms, and by extension bob supnik and the history of simh, now opensimh because of modern lawyerese. for that, the following interview is invaluable. of special interest is the early seventies and the role of the dec10. later in the seventies, the meeting of tops10 and two seattle teenagers would influence familiar aspects of dos and ibm compatibles. these strands of history combined in seattle in the late eighties, as discussed below.
Oral History of David Cutler Interviewed by: Grant Saviers Recorded: February 25, 2016 Medina, WA CHM Reference number: X7733.2016 © 2016 Computer History Museum Oral History of David Cutler
Grant Saviers: I’m Grant Saviers, Trustee at the Computer History Museum, here with Dave Cutler in his living room in Bellevue, on a beautiful Seattle day. Nice weather, for a change. I’m here to discuss with Dave his long career in the computer industry. And so we’ll begin. So we were talking about your entry into computers. But let’s roll back a bit into early childhood and living in Michigan and being near the Oldsmobile factory in Lansing. So tell us a little bit about your early days and high school. David Cutler: Well, I grew up in Dewitt, Michigan, which is about ten miles north of Lansing, where Oldsmobile was at. I went to Dewitt High School. I was primarily an athlete, not a student, although I had pretty good grades at Dewitt. I was a 16-letter athlete. I played football, basketball, baseball and I ran track. And I’m a Michigan State fan. Michigan State was right there in East Lansing, so I grew up close to East Lansing and Michigan State. Early on, I was very interested in model airplanes, and built a lot of model airplanes and wanted to be a pilot when I grew up. But somehow that just went by the way. And later on, I discovered I had motion sickness problems, anyway, so that wasn’t going to make it. So that’s pretty much my early… Saviers: So model airplanes kindled a technical interest in aviation and flying? Cutler: Well, I don’t know how I got into model airplanes. There was a local shop that was like a hobby shop that sold model airplanes, and I got interested in building them, and then, of course, you know, you build bigger ones and bigger ones. And you try to build powered ones, and I built a powered one, and I mostly crashed them. So I don’t know if it really fostered a technical interest, but certainly was something that I was interested in for quite a while, but then sports took over in high school. And I became more interested in sports. Saviers: So sports led to an opportunity to go to Olivet College. And athletics were a big part of making that possible, weren’t they? Cutler: I went to Olivet College, they offered me pretty much a full ride. I had an academic scholarship, and I had scholarships for basketball, baseball and football. And I would probably not have went to college, if I hadn’t had a full ride, because we couldn’t afford it. And I had applied a couple other places. I really wanted to go to Central Michigan. And they didn’t accept me. And the thing at Olivet worked out really well. It was close to home. And that’s where I ended up. Saviers: And how did you decide on the course program that you’d take at Olivet? Cutler: When I got there at Olivet, I didn’t really know, I think, like most students, what I really wanted to study. I don’t know why I decided on Math, other than it was a very interesting, challenging thing. And then after I decided Math was my major, then it was natural for me to say, “Well, I ought to have a lot of Physics,” so I took a lot of Physics. And I really enjoyed Math and Physics. I didn’t enjoy some of the other things. Olivet is a liberal arts school, so there was a lot of liberal arts requirements. It’s also a religiously affiliated school, although really not tightly religiously affiliated, but there was a lot of stuff I had to take that was religious related. But I sort of gravitated towards the Math and the Physics, and it worked out well. It was great.
Saviers: So you’re progressing through college and thinking about what’s next, where the career might lead, where you might go to work. Any jobs during college, by the way? Cutler: Did I have any jobs during college? The answer is No. I was so busy playing sports, and later on, the first two years of college I played mostly sports. And studied just enough to get by, and keep my academic scholarship. And then the last two years, I really, you might say, applied myself, and tried to be a good student. What happened to me was within a span of 18 months I had my right knee operated on, and they pulled out the medial meniscus. I broke my left leg, and then I had my left leg operated on, and they pulled out the medial meniscus there. So I was pretty much done with sports at the end of two years. And during those two years, I think that I mainly thought about– I never thought that it was really going to end, that I was going to be– I was thinking, “Well, I’m just going to be playing sports forever.” And then after two years, it’s sort of , “Well, I’m not going to be playing sports forever. What do I really want to do? And so I’m really not sure what I really wanted to do, but I think I really liked Math and I liked Physics, and I’m a hands-on kind of person that likes to build things. So I really think that I would like to have some kind of engineering job somewhere.” So I was sort of aiming at an engineering job, but not going to an engineering school in a time era where it was possible that such a thing could happen. Today, that would probably be pretty remote that somebody could do that. I mean, if you had a Math degree, you probably wouldn’t step into a mechanical engineering job or something like that. Of course, you could step into a computer engineering job. Computer engineers – a lot of different disciplines make good computer engineers. So anyway, my goal in the last few years was to finish my degree and find an engineering job. Saviers: And how did that go? Did you start interviewing companies? Did companies come to the campus? Cutler: In those days, the companies didn’t come to the campuses. We’re talking 1965, and or at least they didn’t come to our campus. And I just mainly applied to a lot of different companies. I applied to Lockheed, and the aerospace companies, and I applied to General Motors and I applied to DuPont. I don’t know how I happened to apply to DuPont. I saw an ad somewhere probably, or something, and waited for people to come back and say, “Hey, we want to interview you.” It turned out that I ended up actually having three solid job offers. One was from Chrysler in a soft trim plant, which was door panels, and the soft trim in an automobile is basically the inside. The job there was a time and studies operations research kind of job, in a town that wasn’t too far from where I lived. I had a firm offer from Oldsmobile to work in their computer accounting department. And I had an offer from DuPont to work there in a job that was supposedly an engineering job. So I decided I didn’t want to work Oldsmobile, because I didn’t want an accounting job. I didn’t know anything about computer science at that time. Computers were around, and people used them for record keeping, and accounting kinds of things. And of course, there were people at universities that were using them for other things. But mostly, when you talked about computers, the general public knowledge about computers was accounting and records keeping. And that’s mostly what the IBM machines were doing was record keeping and accounting. So I decided I didn’t want to work there either. And so I decided to go to Wilmington, Delaware, and take the job with DuPont. Saviers: And was that job what you expected?
Cutler: Was the job what I expected? No. It was a life lesson in interviewing. And that when you interview and you decide you like to go to work for a company, you really should pin them down about what you’re going to be doing when you get there, because if you don’t, you may not be doing that. And I thought I was going into an engineering job. A little bit undefined, but I ended up when I got there with a job that was a tech writer, writing standard test methods for DuPont Elastomeric Materials Division, which were basically methods on how you stretch and pull and bounce synthetic rubber. Saviers: That’s pretty far from computers. What was the first step into computers? Cutler: My first step into computing was with a group at the same lab I was at, which was a Sales Service Lab, which helped DuPont customers apply DuPont products to their products. DuPont basically made raw materials for other people to use in developing a product. For instance, the Elastomeric Materials Division made Neoprene. And Neoprene went into a lot of things like wetsuits, and even went into tires for a long time. So there was another group there which was a Math and Stat Group, and I’d interviewed with them, and they were interested in me. And after about a year, they asked if I could be lent to that group for a short amount of time to develop a model of a foam process for Scott Paper Company. Saviers: Okay, so we were talking about a foam-making process at DuPont and some challenges in that that led to a computing career. Cutler: So DuPont was trying to help Scott Paper company with a new process that they had developed to make foam for the garment industry. And the guy at the lab, the DuPont lab that was the manager of the Math and Stat Group wanted to build a model to help them schedule the production on this new machine. And so they asked if I could do that model. And I said yes, I’d do that, because I was so bored to tears trying to write these test methods, that nobody seemed to like what I was writing. So they sent me off to school with IBM to learn a language called GPSS-3. GPSS-3 was General System Simulator 3. Saviers: General Purpose System Simulator. Cutler: Yes, General Purpose System Simulator 3, which their third version of this. GPSS is a language that’s an event-driven block-oriented language where you have a number of different blocks, or you could look at them as functions, that perform a specific kind of thing. Like Create Transaction was a block. So you could create transactions into the system that you’re trying to simulate. Saviers: And these all operated in parallel, too, right? It was a parallel event language, if I remember right. Cutler: Yes, it is. The language tried to simulate a real-time process, a real time system. And then everything was running in parallel, but there was no need for synchronization. So you were removed from the synchronization aspect of building this model. And I ended up building a fairly large model, and partway through the building of the model, I got really interested in more about how the computer worked than how the model worked. So I began to really dig into a lot about the computer architecture in the
machine I was running on. The machine that we ran this model was an IBM 4044 Saviers: 7440, maybe? Cutler: It was the precursor to the 7094. So it was the 7044. That’s what it was. Saviers: Yes, 7044. Cutler: It was a 36-bit machine. And this is the time that I really learned how fallible humans are. And we learned a lot of humility about programming, and the fact that computers only do exactly what you say, and not what you mean. And I went to the IBM Data Center. We had to go up to Philadelphia to go to the IBM Data Center, and with my deck of 2,000 cards with all kinds of time, free time,scheduled with the IBM representative and my boss and everything. And we’re jollily going up there and we’re going to run this model. And we get there, and we spent all the time trying to take the syntax errors out of the program, and we never got them out the first day. So that was a really humiliating experience. Saviers: So the GPSS project finally worked, and you delivered the model. Cutler: The GPSS project ran for, I think, about a year. And we had somebody from Scott Paper assigned to work with me that actually was somebody similar to me, very little experience and a young guy. And he and I would go up to the Data Center and run this model. And we would feed information into it and try to get results out, and what we were trying to do was, we were trying to figure out how, or what the best schedule was for scheduling a number of different colors and textures of foam on this machine to get the best productivity out of the machine. And eventually we got the model to work, and we said, “Okay, give us a question to ask the model,” and they came up with a question about scheduling and we ran that. And we had a big presentation, and we handed over the model to them, and said, “Okay, here’s the model. All you have to do is go to the IBM Data Center and run this, and you have a guy that can run this.” And I really don’t know what they did after that. I suspect they did very little with it, but it was sort of a– a lot of it was public relations on DuPont having a vested interest in seeing that Scott Paper Company had the best support they could possibly get to run their foam process. Saviers: So this initial foray into computers then leads to digging deeper into how computers really work, and how operating systems really work. Cutler: So after this project, I got more interested in computing, and decided that I would really like to stay in the Math and Stat Group. So I stayed in the Math and Stat Group and worked on various things. We had an 1108. Well, it was 1107 to start with, a Univac machine at the Experimental Station, which was, I don’t know, 15 to 20 miles away, and there was a shuttle that ran back and forth every day, and we could submit programs to run on that computer and get the results back. So I started doing some of that stuff for the Math and Stat Group, and also got involved with procuring a CDC-1700, which was a 16-bit machine, to automate the Instron machines, which was a tensile strength testing machine, for the lab. And so I got pretty interested in that. This all lasted, I would say maybe about two years, and then I
started to think about, that I really wanted to be somewhere where I was working more on computers,
rather than working on computers as a tool to solve other problems. So I succeeded in negotiating a
transfer to the Engineering Department at DuPont, which had lots of computing capability, and they’re the
ones that had the 1107, which they upgraded to the 1108. And I joined the Online Systems Group there.
Saviers: So the 1108 and 1107 had a product called Exec 2, which was notoriously flaky.
system part of it actually kicked in at one point, or a couple of points, where we did get some big things to do. We got a big job to work on at the Experimental Station, which was DuPont’s main Research Center, which is a fairly big site. It was 120 acres and all 13 Operating Departments had offices there. So they decided that they would like to automate the analysis of some of their instrumentation. Their instrument data. And we proposed a Dual-PDP-10 system to do that. We spent, I don’t know, maybe six months with various other vendors. IBM being a vendor, SDS, if you remember SDS? Scientific Data Systems being a vendor that we looked at, the Sigma 5. And we decided the PDP-10 was the best alternative. So we built, or we bought a PDP-10, a Dual-PDP-10 system with shared memory, special built by Computer Special Systems at DuPont– or not DuPont– Digital. And then we wrote an operating system for one of them, which was really the frontend. And it brought in all the data, and then when the data was complete it submitted it through the shared memory directly to the Tops-10 system which then did the analysis, of programs written in Fortran. And then we shipped the results back. So I got quite a bit of experience on DEC PDP-10s. Became pretty knowledgeable about the TOPS-10, and went to Digital to a school on TOPS-10, which was run by Dave Plumber, which was Digital’s number one guy about running courses on the TOPS-10. So after that, I came back to the Engineering Department, and they gave me another job that was on DEC equipment, which was a PDP-11 gauge control system for Chronar film, which was used in magnetic tape. And this system was a PDP-11/20, and at that time there was no suitable operating system from Digital– or not Digital– yeah, Digital. No suitable operating system from Digital that would actually do this. We were going to do this on a very small PDP-11. I think it probably only had 8K of memory. So I was given the task of developing the little runtime, the little real-time runtime system to do the Chronar gauge control system. So when I finished that, I decided that maybe it was time for me to move on and think about something else. In fact, what I was thinking about was I’d moved from using computers to solve problems to actually working on computers themselves, but with not within a computer company. And I thought, well, if I really want to maximize my value to a company, and I want to be in the operating system business, then I ought to go to a company that builds computers. So I arranged an interview with Digital in Maynard, Massachusetts, and lo and behold, they hired me! So off to Digital I went. Saviers: Just to backtrack a little bit here, what did you think of DuPont? Cutler: I was at DuPont for seven years. And the culture at DuPont was really very foreign to me, because it was very– it was an old company. DuPont was founded, I think, in the mid-1800s. They supplied black powder during the Civil War. That’s how they got their start was black powder. A very bureaucratic company. Very regimented. You didn’t tend to do things like go to talk to your boss’ boss. So it was, I had a good time at DuPont. And it was great for my career. But I didn’t feel as comfortable there as I actually ended up feeling at DEC, which was a very different kind of company. Saviers: So did you have a sense of what the DEC culture was like when you decided that it was time to move to there? Cutler: When I went to DEC, I had absolutely no idea what the culture was, other than the fact that I went to the PDP-10 programming course, so I was a little bit acclimated to the facilities. Digital was in a mill, and the mill was old. It led back to the mid-1800s also. But not really anything about the culture. And I really never really thought about that. I think I thought more about the opportunity than I did about, “Was
the culture going to be the same or different?” You know, if the culture had been the same as it was at DuPont, I still would have went, because the opportunity was better. Saviers: So talk a little bit about getting started at DEC. Who was your first boss, and what was the direction of the task at hand? Cutler: ,Let’s back up a little bit about what I was hired for at Digital. This was like maybe another instance of not knowing exactly what you’d end up doing. Although, I really had this one tied down and I was going to work on something called OS-45. And OS-45 was a dream of Dave Stone, who was the head of programming at Digital. And the PDP 11/45 had some special solid-state memory that you could buy that was 300 nanosecond memory. And this is in 1971. And the PDP-10 was at that time, I think the best PDP-10 was above microsecond machine. So this was a very fast machine. And Dave Stone had this vision that we were going to recreate TOPS-10 on the 11/45, and we were also going to incorporate real-time capabilities, and batch capabilities, in addition to the timesharing. And there was a group of people that was assembled that was probably about eight people, and the leader of the group and my initial boss was Peter van Roekens. Peter came from RCA and he was responsible for the development of VMOS– VMOS? Which was the Virtual Memory Operating System that ran on the RCA IBMcompatible machines. And so I came to Digital, and I spent probably the first two or three months thinking about all this stuff. And the group was thinking about all this stuff. And then all of a sudden, we weren’t really making a lot of progress on this, because there was one little small problem that Dave Stone hadn’t really considered as much as he really should have, and that was that the address space of the PDP-11 was 65K bytes. And 65K bytes just wasn’t going to cut it for an address space. And the memory management capabilities weren’t that great either. So we had an awful hard time really getting started and getting up to speed on what we were going to really do with this OS-45. So there was another project that was going on over in The Industrial Products Group. Develop a process control system, or a process control OS for the PDP-11. It was called RSX-11C. And they had been working on that for a couple of years, and it was going nowhere, and they asked me if I would go work on that. And I said, “Well, sure, I guess I will go work on that. You know, we’re not doing much on this other project,” so the first project worked on really as far as real work was the RSX-11C system. Saviers: And the RSX-11 series ended up C then D then M, or something like that, if my recollection is correct. Cutler: RSX-11C was the first in the series of the RSX systems, which were primarily sponsored by the Industrial Products Group, but were also sponsored by the Laboratory Data Products Group also, because they were in the real-time businesses, and RSX-11C was just a core only system that supported a few peripherals, A to D convertors, terminal interfaces. That was about it. And so there was a real need for some more functional systems. And as we filled out the PDP-11 line, of course the 11/45 was a pretty big machine, but we filled it out with a lot of other ones, the 11/40 and the 11/70. There was a need for some more operating system capability that supported a more rich programming and capability. And so there were several RSX systems. There was RSX-11C. There was RSX-11B, which maybe that one may have never had anybody really know much about it. But it was basically RSX-11C that could load DOS 11 files off of the disc. So it was – we can start programs on the disc, and run them, but it’s still a core-only system. And then RSX-11M, and RSX-11D. The order in which we did these was RSX-11C was done
first, and then B. And when I did B, I said, “I will do B, but I want you to promise me that I don’t have to work on this again.” And they said, “Okay.” So about that same time RSX-11D was starting up, which was an equivalent of RSX-15, which was the 18-bit real-time system that Digital sold. And so I was assigned to work on that. And there was a fellow named Hank Kraichi, which was the main designer of that, because he worked on the RSX-15. And I agreed to do the overlay linker for it. So my involvement in RSX-11D was the overlay linker. And when we finished that that came out a little bit larger than we’d hoped, and a little bit slower than we’d hoped. So I had this idea of about building a system with a really different architecture. The RSX-11D had an architecture were basically everything ran as a process. And doing that meant the drivers ran as processes, which meant that there was an IPC, an Inter-Process Communication, mechanism had to exist between the program that wanted the service of a driver, and the driver. Which wasn’t really conducive to the real-time performance we wanted to have. So I had this other idea of building a system that was a lot different. In fact, it’s mostly like the other systems that we built, or I’ve been involved with. So I proposed building RSX-11M. And the Industrial Products Group got pretty excited about it. And they gave me, I guess, about eight people to work on that. And we completed that in about a year-and-a-half or two years. And that became the main real-time system for PDP-11s, because it would run on all the PDP-11s. The ones that had memory management system, or memory management units, and the ones that didn’t. In fact it ran on systems from 32K bytes up to 2 megabytes, a big span. Saviers: So this was the first time that you’re running a major software project? A major operating system development project? Cutler: Was this the first time that I was running a major project? Probably you would consider that to be the first time of a major project, because this was something that we’re actually going to sell. We’re going to sell RSX-11M. We’re going to have customers, we’re going to have support issues, and so there’s all of that. And we’re going to have documentation to do. The PDP-10 system was probably not quite as big a project, but I was the lead guy there, too. Very inexperienced. I don’t know how DuPont ever had the faith they had in me to do that, but they did, and I’m thankful they did. So RSX-11M was really the first time that I did a project. And so I developed around RSX-11 a lot of things about, how are we going to do this, and what are we going to do, and what do we have to do. And so one of the first things I wanted to know is, “What is the scope of work? What are we going to do?” You can’t just say we’re going to do an operating system. We gotta know, “Well, what capabilities is it going to have? What are its constraints?” One of the constraints it had was it had to be subset compatible with RSX-11D. So it wasn’t a blank sheet of paper where we could just go off and do a new system. It was, well, it has to be subset compatible, but it’s source level compatible, not binary compatible. So that was a big caveat, because binary compatibility is much harder to achieve. So RSX-11M was really my first real operating system from scratch. I think it took about two years. It was delivered with what I think was pretty good quality for the tools and everything we had at that time. My philosophy about quality was quality was number one. It’s still my first thing is quality is number one. Saviers: So the “Size is the Goal” rubber stamp played into that? Cutler: One of the big constraints with RSX-11M was, or one of the big problems with RSX-11D was it required so much memory. So with RSX-11M we wanted to build a much smaller system, and I figured
out right off the bat that the only way to do that was we give everybody a budget. So everybody had a budget about how much memory they could use. And so that was their target. So if somebody came back and said, “I can’t possibly do that, and whatever the budget was, then we’d rethink that. But generally everybody met their budget. And so to reinforce that, every– I had this rubber stamp made that said, “Size is the Goal.” And everything was stamped with “Size is the Goal.” You know, in those days, there was no email. So there was no electronic exchange of communication, so all communication was through memos, and every memo was stamped with “Size is the Goal.” “Size is the Goal.” So we ended up with in a 32K byte system, there was 16K bytes for the operating system, and 16K bytes for whatever the user environment was. Or the application environment. There wasn’t really user mode. There was user mode and kernel mode, but these were dedicated systems. It wasn’t a system where there were a lot of people who were going to use this in a general way. It was like, “This system is dedicated to controlling something in a real-time way.” And whoever bought the system would write the software that would control their process. Saviers: Now this is where the first Dave Cutler kernel, the DCK shows up? You go off and code a big part of the operating system yourself? Cutler: Well, all the stuff that I worked on, I did a lot of it myself. I did– going back to the PDP-10, I did a lot of that myself. In fact, everything that I’ve done throughout my career, I’ve always been a very handson person. I can’t just stand back and say, “You know, this is what we’re going to build, you guys go off and write the specs, and I’m going to manage you.” I sort of become part of the team, and I look at myself as more of a leader than a manager. And I want to lead the people to build a product, and that means I’m a part of that. And there’s no job that I can’t– that I won’t do. I like to have– I have this little saying that, “The successful people in the world are the people that do the things that the unsuccessful ones won’t.” So I’ve always been this person that, you know, I will build the system, I will fix the bugs, I will fix other people’s bugs, I will fix build breaks. It’s all part of getting the job done. Saviers: So the PDP-11s run out of gas. DEC decides it’s time to build a 32-bit computer. They’re behind, the SDS and SEL and others have 32-bits, and a new operating system is needed, and the project VMS starts. Cutler: About, I think it was 1975, Digital realized that they needed to build a 32-bit computer. And so being a part of RSX-11M and the 11 world, I kind of got involved in that. We had several architecture groups, several levels of architecture group. We decided to call this VAX, and VAX was a code name which stood for Virtual Address Extension, because the PDP-11 had such a small virtual address space. Gordon Bell was the person that was behind this. It was his vision that we should build this computer. The VAX-A was the hardware architecture group, and VAX-B was sort of a review group. And then I think there was another one called VAX-C, which was like the rest of the company. And I was like a formal member of VAX-B, but an informal member of VAX-A also. So I spent a lot of time on the VAX-A group discussing the computer and whatever. Bill Strecker was involved in this and Gordon Bell. This was my first real involvement with Gordon. He was at the company all the time I was there, but this is the first time I was really involved with him. And we would meet almost every day and talk about this computer and the instruction set and what we should do. And one of the biggest goals of VAX was to be able to encode a program in the same amount of memory that the PDP-11 could encode it. So that dictated an instruction
set that was pretty dense. The other thing is we definitely wanted to increase the virtual address space by quite a bit. And building a 32-bit computer would allow us to do that, and at that time, like going from 16 to 32 was like, “Man, how could we ever run out of 32 bits of address space.” And later on, we’ll skip forward and we’ll figure out why we did run out of 32 bits. So the VAX-A and the architecture group, basically were defining the architecture. And there were other software people involved. There was some people form the PDP-10 group that were involved. Mainly Peter Conklin, and we hired a fellow from Xerox who had worked at SDS, who had worked on a system called CP-5, which was one of the systems that ran on the Sigma 5. It was the operating system of the Sigma 5. His name was Dick Hustvedt. Dick was involved with VAX-A, and the other person was involved with Peter Lipman. And some other people. But we basically developed the architecture and then the company said, “Well, let’s build it.” And so we said, “Well, how long do you want this to be?” And they said, “Well, two years seems reasonable.” And he said, “Oh, my lord, we can never build this in two years, this is too complicated of an architecture to build in two years.” So we had this off-site, one week, come to Jesus meeting about what we would do to the architecture to make this system buildable in two years, and that– I think that was called the Blue Ribbon committee, and there were three software people– three software implementers, and three hardware implementers, plus some of the architects. And we hammered out the final VAX architecture, which reduced the complexity of the instruction set architecture quite a bit. I suspect that people would still say that the instruction set architecture was overly complicated, but it was really complicated before that. And the other thing that happened was the memory management was so complicated that the only person that could actually explain it was Richie Lary. And everybody else was sort of like, “Yeah, that seems like it might work, but we’re not really sure.” And so we really simplified the management architecture so that the hardware architects thought that they could build it efficiently and the software people thought that we could build an operating system for it. And one of the decisions we made with VAX– in fact we made a couple of decisions with VAX that limited the life of VAX. One was the encoding of the instruction stream to be equivalent to the PDP-11, which caused an extremely difficult to implement hardware system that was mainly in hardware and not mainly in microcode. So the VAX instruction set mostly was executed in microcode and not in hardware, because it was so hard to decode. And the other thing that was kind of a mistake, a long-term mistake was the page size being 512 bytes versus something more reasonable like 1K bytes or 4K bytes would have been a much better solution. However, we looked at it and the marketing people wanted to sell VAX systems that were the size of PDP-11 systems in memory. So they wanted to sell a system that was 128K bytes. Well, the most complicated instruction in the VAX architecture was “add pack six.” That was an add packed instruction, decimal instruction with six operands. That could touch 40 pages. So it became, if it had to touch 40 pages, and you only have 128K bytes, then you don’t want to get into a live-lock situation where what’s going on in the system is such that you can never get all the pages in to actually execute instruction. So we settled on the 512 byte instruction set. So after the architecture was signed off on, and we decided there was a lot of fill there, we went through the blue-ribbon committee. Published the final architectural spec, then we put together the software group, and we put together the hardware group to build the hardware, and to build the software, and I was the technical lead of the software group. And then we spent-, I would say six months trying to think about and understand how to build the system, because we were deathly afraid of building a paging system. There wasn’t a lot of experience on paging systems in those days. The PDP-10 did not have paging, it had swapping. BB&N had built a modification to the PDP-10, which had paging. But the scuttlebutt was it didn’t run real well. Multix was a paging system, and Multix did not run well. I’m not sure
that Multix would run well on today’s hardware. It was a great system, it spawned a lot of creative ideas, but it was basically very slow. Anybody that ran on that system definitely was not concerned about productivity. So we spent a long time figuring out how we would build this system, so we thought we would have good performance, we would be able to build it in a couple of years. And we would have the quality that we wanted to have. And so after six months, we authored a document, called it, I think, The Scarlet Design and Project Plan. Or it was the Scarlet Project Plan. And from that we started out and we implemented– or actually we developed the VMS mainly on RSX-11M. RSX-11M had a little bit, by that time, it had a little bit of timesharing capability, so there was multiuse and we had a large 11/70. Probably two megabytes of memory on it. Two megabytes! So we developed mainly on RSX-11M but then we ran it on a simulator. The group that actually built the VAX-11/750 was the group that was assigned to build the emulator for VAX. And we actually had an emulator run on, which is a hardware emulator. We didn’t run on a simulator, we’re on an emulator. And we developed it– got it running there. And then when the hardware, or the breadboard, for the VAX 11/780 was available, we took what we had and we went upstairs and it pretty much ran. It booted up and at least we got to the point where it didn’t crash. So that’s kind of how we started, and then from then on they built a prototype. I think it was Proto 4, and that was our development machine, and everybody ran on the development machine. And we ran what we built. And this was the first instance of the dog food thing. Where you run on what you’re developing, and that gives you a big incentive to fix whatever’s wrong. – VMS is a timesharing system. So we were all in our offices, and all close to the machine, and if it crashed, you know, Dick Hustvedt and Peter Lipman and I would go out and look to see why it crashed. And we’d figure out why it crashed. And we’d reboot, go back to our office and fix the problem. And then go out and reboot a new system, and then everybody would be with the new system. So that’s how the development of VMS occurred. And the day we shipped VMS, we had zero known bugs. That was zero known bugs. That didn’t mean there was no bugs. But there was zero known bugs, and I know there was a bug right at the very end, where we had a race condition that was fixed like in the 11th hour. And then the final binaries were submitted to the manufacturing plant. Saviers: So the VMS and the VAX 11/780 kind of launched DEC into the supermini, bigger applications, more nudging into the commercial world, all kinds of new features and requirements coming, and that spawns a lot of evolution of VMS. So you were with the VMS team for all of that. Cutler: No. VMS was my first very difficult project where there were some constraints placed on us that were very hard. The two years that we were given to eventually or effectively produce a system of the level and caliber of VMS was very short. And at that point, I thought, you know, “Maybe I should try some other things I’m interested in.” And one of the things I was very interested in was compilers. So at the end of VMS Version 1, I decided that I would start a compiler group to produce a PL/1 compiler. So I really didn’t continue on with the continuing versions of VMS. I split off at that point and started this group consisting of, I think, four people. And I think we grew to about six people to do a PL/1 compiler, and we bought a frontend for the compiler from a company in Boston. And we produced the backend, which was the code generator. And I think that was another two-year project or so. And part of that project also spawned a C-compiler for VAX also.
Saviers: And this was an example of really eating the dog food, of writing the compiler in the compiler in
PL/1?
Cutler: Actually PL/1, as far as the dog food kind of thing, was an interesting way we did the compiler.
We had the frontend of the compiler that was delivered to us on Multix. And Multix, we first thought that
what we would do is we would take the Multix compiler and we would compile the pieces of the Multix
compiler and we’d bring them over to VAX and run them, eventually. We tried running it remotely on the
Multix system, and we couldn’t get it to run in full loop locks mode. And this is like, I don’t know, a
hundred, or whatever it is, it’s fifty miles to Boston. It’s 300 baud. So we tried half-duplex. It was a little
better half-duplex. So we just, so that wouldn’t work either. So we decided what we would do is we’d hire
a shuttle service. And the guy who was working on the frontend would produce stuff on Multix, put it on
mag tape, give it to the shuttle service, bring it to DEC, and we’d take it off the mag tape. So the first thing
we did was we did– we bootstrapped the compiler backwards. So we were doing a code generator on our
end, but the code generator was mostly written in assembler. So we got that working, and then we would
bring back the phases of the compiler one by one, backwards until we got back to the beginning of the
compiler, and then we could compile the whole thing at Digital. So we really were eating our dog food,
because the whole compiler was written in PL/1 except for the parts of the code generator that had to run
last.
Saviers: So now we’re about 1981 at DEC or so? Or a little earlier?
Cutler: This is about, well, it’s 1980/’81, sometime during that year. Maybe early in that year.
Saviers: So some circumstances conspire and you think, “Maynard’s no longer for me.”
Cutler: So what happened after the PL/1 compiler was, I getting really a little bit fed up with the growth of
Digital. When I started at Digital, there were 12,000 people, and I don’t know in ‘81, there certainly wasn’t
12,000 anymore. There was 75,000 or something. And so what started out to be this really engineering
run, engineering environment, suddenly became more of a management, marketing, and program
management environment, which I wasn’t too happy with. And so I had expressed some things to Gordon
about maybe that I would like to be somewhere else. And he had offered to– he said, “Well, anywhere
you want to go, you know, maybe we can figure out how we can start an engineering facility there.” And I
said, “Well, I don’t know. Maybe I’ll be okay here.” And then this opportunity came up to start a company
that was going to commercialize a compiler– I’m sorry, a language, that was funded by the government
for a real-time control, which was called Praxis, and it was done for Lawrence Livermore. And it was
actually done for the Shiva Nova project, which was a fusion energy project. So I kind of got enthused
about doing that. And we– “we” being, I guess, about six people. Three of us from DEC and a couple
from– or four of us from DEC, and a couple from Lawrence Livermore. You know, traveled around the
Bay area looking for money, and we got to the point where I think we figured out that maybe this wasn’t
the right thing to do, or at least I figured out this wasn’t the right thing to do. And so I told Digital
colors, and paying his wife for our stationery. And so suddenly all our money that we’d put together was gone. And I’m thinking, “Wow, I don’t know if I want to go with this guy.” So at the last moment, I said, “Nah, I’m not going do it.” So effectively all the other DEC guys says, “Well, we’re not doing it either.” So then became the question about well, “Gees, what are you going to do?” And so I said, “Well, you know, I think it’s really appropriate that I think about being somewhere else where I’m kind of isolated a little bit from– a little smaller environment, where we don’t have all of the bureaucracy we’re developing at DEC.” So Gordon says, “Well, gees, that sounds good to me. Where would you like to go?” And I said, “Well, I can’t be on the East Coast, because that won’t be far enough. You know, I really don’t really like the Southwest too much. So, maybe like Arizona and New Mexico. Probably Texas is not a good place. Probably the West Coast would be the best place.” Well, Gordon says, you know, “The West Coast would be fine, but I want you to be somewhere where there’s a university that’s got a good Computer Science program, so that we can draw people from there, and maybe we can actually collaborate with the university.” So the DEC real estate department arranged this trip where we would fly to several different places on the West Coast and look at. And we went to San Francisco, we went to Sacramento. They were really hot on Santa Rosa. We went to Portland, and we came to Seattle. And I had spent a little time in Portland, a little earlier. In fact, what had spawned the earlier offer by Gordon to establish an engineering facility for me was that I had actually interviewed at Intel in Portland, which is kind of an interest– this is kind of a backtrack, but only go back and talk about that just for a second. And this happened and I interviewed and they were building the 432 at that time, which was their 32-bit computer. Which eventually never ever materialized. But we had lost a couple people. Dave Best, who had been the program manager for the 11/750 went there. So I interviewed out there and it got to the point of they were going to offer me a job, and they said, “Well, we can’t really offer you a job, because we really cooperate a lot with Digital, and you’ve got to tell Gordon Bell that you’re interested in this.” So I said, “Eh, no problem.” I called Gordon, I said, “Gordon, I’ve been interviewing with Intel. And I don’t really want their job, but I want their offer, because I want to figure out how much I’m worth.” I said, “Okay. You okay with that?” And he says, “Sure.” And I hung up and about 15 minutes later, the phone rings, and it’s Larry Portner’s admin. Said, “Larry and Gordon would like to come up to Spit Brook Road in New Hampshire and have lunch with you. And I said, “Oh, that’s fine. When?” “Today. Will that be okay?” And I said, “Sure.” So they came to Spit Brook and we went to lunch, and they basically said, “Well, why do you want to leave?” And I said, “Well, I don’t want to leave, I just wanted to know what my value is in the market.” They said, “Oh, well, maybe we can work something out.” I said, “I really like Portland. And Gordon said, “Well, maybe we can think about this.” So, you know, they did something about the salary thing, and something about stock options and I thought about that a little bit. Then I said, “Hey, I don’t really want to do that. I’ll stay here for a while,” and then this other company opportunity came up. And then when that fell through, it was really like, “I really do want to move.” So anyway, we’re back to the West Coast, we’re going back to the West Coast, and we go everywhere, and we come to Seattle, and it’s raining, but everything’s green. And so I said, “Gee, boy this is really a nice place.” And we visited the university. We talked to the Chairman of the Computer Science Department. I forget what his name was. He was really interested in us coming. And so we went back home and we thought about it for a while, and said, “Seattle’s gotta be the place. That’s got to be the place.” So that’s how we ended up in Seattle. Sort of we took the trip and looked at some different places, and decided we didn’t really like Sacramento very well. The Bay area was a little bit too busy for us. And Bellevue was a pretty nice place to be. So that’s where we ended up.
Saviers: So here you are. So a number of people decided to come with you, and some other folks were hired here locally. You started up a lab. Cutler: We came here and we brought, I guess about eight people with us. And we hired– you know, one of the things was we liked to hire some people from the University of Washington to firm up that connection with the University of Washington. We hired a couple people from there, and started on a project - our charter, by the way, for this was to produce – again, going back to the real time roots– to produce some software for embedded chip-based VAX systems. We were working on a chip set at that time called Scorpio. Which by today’s standards would have been huge, because it was six chips. I think three of them were custom, custom VSLI chips. So it was a big compared to today, but it was very small compared to what we had in those days. So our charter was to build this runtime system, a little real time operating system, which was very easy to program. And which was very easy to implement real-time applications. And the name of the system was VAXELN. And it was my first entry, our first entry into multithreading. We actually did multithreading in VAXELN, which is about the same time that the Mach kernal was doing multithreading at Carnegie Mellon, just about the same time. So we got partway through this project, and we started thinking about, “Well, Scorpio has been going for quite a few years now. We don’t know when it’s going to be delivered. We don’t really have any suitable platform to run this on. Maybe we should think about what we should do to VAX to maybe make VAX a smaller architecture.” So we started an effort within the company called MicroVAX, which was to trim down the architecture. And then later on, after we had developed the architecture, we thought, “Well, we still don’t have any platform to run this on, because we’re going to have to produce a chip for this.” And there was a MicroVAX chip. “So maybe we should start a hardware group here, too, and we should produce an implementation of MicroVAX that would not be one chip, but it would be a small system, maybe the size of a PDP-11/05. So we brought some more people out from DEC-East, for the hardware project. And they were mainly people from the East, but we also hired, I guess, three people locally, because there’s a lot going on in this area with electronics, so it was easy to hire a few people, and to produce MicroVAX-1. We actually shipped VAXELN and MicroVAX-1 together. And I got very interested in hardware at that time, and I ended up working on VAXELN pretty much writing the kernel. And the other people wrote the pieces of the file system, and the pieces that went around it. But then I switched to the hardware group for the MicroVAX-1 and wrote all the microcode. Saviers: And somewhere along the way, you hooked up with Carver Mead and took the team to learn how to do chip design. Cutler: The way that I implemented the MicroVAX-1 system was Gordon thought it would be a good idea if we tried some new technology with respect to producing silicon chips. And one of the new technologies that was being touted by Carver Mead from, was he from Caltech? Saviers: Caltech, yes. Cutler: And Lyn Conway had some silicon power tools and the company that was founded– actually called Silicon Compilers that Carver Mead was a principle in, and John Hennessey was also. And we got together with them, and inspect a chip that they could build that would be the central processing unit of the system, and it would be on one chip. And so that’s– they produced the chip. They designed the chip
jointly with our specifications going back and forth. They didn’t have all the expertise. And then our
hardware guys designed all the hardware that went around that. We had an awful time getting the chip
built. We went to a company called AMI to start with, which, you know, in those days semi-conductor
companies were popping up like dandelions, there were lots of them. They’d pop up, they’d run through
their VC funding. They’d roll over and play dead. AMI never actually produced a chip for us that worked.
They produced a chip and we got the chip and we looked at it, and they had done all the masks
backwards. They were all the negative of what they should be.
Saviers: Oops.
Cutler: Oops. So I don’t know how that happened. So we went to another company called SEEQ. And
SEEQ actually produced the chip. I can’t remember us having any problems with the chip with respect to
errata. There may have been some things that we worked– I don’t really remember. I remember it being
pretty much bug free. And we were able to take that chip and we put it in a Q-Bus-based system. And that
was MicroVAX-1, and we ran VAXELN on it, but later on, we also ran VMS on it. Part-way through the
MicroVAX architecture discussion, we had trimmed the memory management capabilities of VMS quite a
bit. Not VMS, the memory management capabilities of VAX way down, which meant that VMS would not
run with it. It would have to be big modification to VMS to make it run. And so I was writing the microcode
and I thought, “Gees, why don’t we just do the full memory management, there’s not much microcode.”
So I got Bob Supnik to agree to that. He was the guy who was doing the microcode for the MicroVAX-1
chip, that we’d just do the whole thing. It was going to be less work to do that, than not do it, and we get
VMS to run. So we got VMS to run almost at the same time we got our system to run. And I don’t
remember exactly the year, it was probably ‘86 or something, maybe ‘84. About three years, maybe three
years in development for that system. So that was our first project at DEC West.
Saviers: And where did that lead to?
Cutler: Well that led– what did that lead to? That led to problems!
which was Western Research Lab. And we were sort of working on one. So Jack Smith, who was the Senior Vice President of Engineering said, “DEC West is responsible for the RISC architecture.” So there started the Prism project, which was a new RISC architecture for DEC. And I think we probably started that in about ‘85, I think maybe? ‘85? So that’s what happened after we were– we were very successful at being that, we’re just tremendously successful. Very low overhead. Very few people. We got things done in just record speed. For record amount of money. Engineering, NRE costs were like zilcho compared to the other projects. But then into a period of not being able to find the right thing to do, and then into the architecture. The new architecture. Saviers: So I guess it was RISC war that started to evolve at DEC between various parts of the company? Cutler: Well, the reason that the Prism architecture actually got assigned to DEC West was because there were so many projects going on in the company trying to develop RISC architectures. And of course, Digital already had– we now had the 36-bit line, which was the PDP-10, and then the DEC System 20. We had the VAX line, we had the PDP-11 line. I don’t think we were probably making any 18 bit 9s and 15s. We may have still been shipping a few 8s by then. But so we really didn’t need three or four new risk architectures. So the Prism architecture started out much like the VAX architecture with representatives from– VMS had a representative. Hudson, which was the semiconductor branch had a representative. Marlboro had a representative. One of the guys that worked on that architecture was there. We had myself, and then we had a guy from the architecture group. And we then spent the next three years, just about three years, going through a revision of this, and then taking it back to the senior technical community. And they would look at it and say, “Oh, we don’t like this.” And we would go back. We flipped from 64 to 32 to 64 back to 32 in the architecture, which it took a long time to sort through all that, and then the whole principle of RISC was to produce a system architecture that was easy to implement. You didn’t have to have brute force methods of doing things. And massive verification suites. But then the company kind of ran off the track and started adding all these things. The first thing that happened was we had to have vector arithmetic. So we have to compete with Seymour Cray. So we had to have a vector architecture. Well, Seymour probably had, you know, he probably had eight vector instructions. Well, we had to have 150 vector instructions. And they had to be long vectors, they weren’t short vectors. So this went on and on and on. And you know, in the meantime at DEC West, we’re sort of gearing up– you think we’d be in a holding pattern, but we’re not, we’re sort of gearing up for building one of these systems. And we have proposals for building these systems, and we took MicroVAX-1 and we actually converted it to be– to run Prism code, so people could actually develop software. And we came to a point where finally the company just said, “We’re cancelling Prism.” And I went through several– we went through a lot of iterations. I’d go to Maynard, try to get some consensus on what we should be doing. I’d come back home, and invariably it was always something bigger and we’d add people. So we kind of grew from like 20 people to 180 people. So we had this 180-people organization, and we’re building kind of a nebulous product based on this new architecture at a time when the company was trying to build three of these machines. There was in Marlboro and one in Littleton and one in Seattle. So our machine got canceled. And our operating system, which was called Mica, got canceled. And I sort of got– I kind of went through the stages of trying to find some ground where we could all agree on what we were going to build, come back. I’d sell the people on it, and then they’d get disappointed. So I said, “Eh, I
don’t want to do this again.” So I said, “What am I going to do?” And I said, “Well, I guess I’ll form a
company.” So I got three other guys, and I, together, these are the same three guys we met with when I
was talking earlier about Ballmer, which we’ll get into later. And we decided we were going to form a
company to build servers. And I formally quit, although I didn’t leave right away. They gave me an office
somewhere else, until I had really settled things. I spent a lot of time travelling back and forth to the Valley
talking to the VCs and what we’re doing and whatever. And we actually got to the point where we had the
VCs all lined up. We had three VCs and MIPS. We were all going to put up some seed money. We were
going to have a million dollars’ worth of seed money, which was probably quite a bit of money in today’s
dollars. And this would have been in 1988. So somewhere during this period, a quite a few of the people,
when Prism was canceled, had decided that maybe they’d look across the street at Microsoft, and go to
Microsoft. And one of the people that went over there had been talking to Bill, Bill Gates, about the group
at DEC West, and that we had a good operating system group, and maybe that would be something that
he might be interested in. So there was an interview arranged and I went over and talked to Bill about
what they were interested in doing, and what they wanted to do. And see if I was interested. And their
basic concern was that Intel was not bringing the X-86 architecture forward fast enough, and that RISC
processors were going to overtake them, and if RISC processors overtake them, then all the PC software
that they developed wouldn’t be valuable anymore. And that they ought to have something going on in
RISC. And if they were going to have something going on in RISC then they needed a new operating
system that wasn’t written in assembler, that was written in portable language, so that they could run
across several different architectures. And so I sort of listened to all of this, and was really interested in
doing my own company. And so I kind of left the interview thinking, “Well, I don’t think I’m real interested
in this.” And sort of, you know, time kind of– or you know, a couple of months, we mulled this all over, the
four of us. And finally we got all the VC lined up and we got the commitment from them for the money.
And before we were– we got the commitment– boy, you listen to them talk, we were the greatest people
in the world! But as soon as we got the commitment, our value seemed to diminish a little bit. And they
were a little bit more vocal about whether or not we could actually run a company or not, and whether
we’d be able to develop a product, even though we had a good history of product development. So that
sort of got under my skin a little bit. And about the same time, Steve Ballmer, who worked at Microsoft,
and he was the Head of the Finance Department at Microsoft, called and said, “You know, what are you
thinking?” And I said, “Well, I’m thinking that we’re really close to doing this company, and we’re probably
going to turn down the– or I’m probably going to turn down the Microsoft offer.” And he said, “Oh, gees,
why don’t you give me a chance to convince you otherwise?” And I said, “Well, yeah, okay.” And he said,
“Well, how about breakfast at Denny’s, you know, on Saturday morning at seven o’clock.” Or I don’t know,
maybe it was a Sunday morning. I mean, but it was early. And I said, “Yeah, okay.” So the four of us went
to Denny’s, and sat down. And Steve is such an energetic guy, and a positive thinker! And so he starts
the sales job, and I guess the best way– thing you can say is he fleeced us!
something that’s VAX compatible, so the next best thing was UNIX. And we decided that Mach was the best example of a UNIX system. So we were actually going to use Mach on this server. But anyway, Ballmer fleeces us, and we all decide to sign up and go to work for Microsoft. And so, you know, I quit immediately. They’re still working for DEC. And like I quit on Friday, and joined Microsoft on Monday, and the following Monday, these other three guys follow me. And then from there, we– I don’t want to say we recruited, because we didn’t really recruit people, but people asked us about opportunities. And of course, we’re forthcoming about opportunities, so we managed to bring over quite a few people. And part of the thing about going to Microsoft was they wanted the portable operating system, but I like the hardware part of it, too, having that. So we convinced them, or I convinced them that I should have a hardware group and a software group, and that we would produce– the hardware group would actually produce the first RISC-based PC that the software group would be producing the operating system for. So we were able to bring over– I’m sorry, we weren’t able to bring over, we were able to satisfy the– Saviers: I think the statute of limitations has long passed. Cutler: The statute of limitation long-passed. We were able to bring over these people from DEC that had been the top performers at DEC West, and so we got the top hardware guys, and we got the top software guys. It was about 10/10 or something like that. And we hired some more people. We hired– we had, part of the thing about the group was that we– the hardware group, not like the software group– the software group, Microsoft wanted to make sure we had Microsoft people in the software group because otherwise we would just produce something that was DEC, the DEC cultural thing, right? So we had, actually I think we had one, one software guy, and he was a pretty good– or he was a vocal Microsoft guy, and he had a lot of ideas. Which, actually dovetailed with ours pretty well about how to build an operating system. Microsoft had been working with IBM on OS/2 for several years by that time. And that relationship was not going real well, and this guy had worked on that, so he was very happy to join our group. Saviers: So you parachute into Microsoft, and after a short period of time you look around, what did you see? What did Microsoft look like at that time? Cutler: Well, Microsoft didn’t look like DEC. Or actually I should say, Microsoft was a very different company than DEC. DEC was– the thing I liked about DEC, and I think that I can honestly say that I spent most of my best– the most enjoyable engineering years at DEC between 1971 and 1980, or maybe ‘82 or ‘83– was DEC was mainly an engineering company. It was run mainly by the engineers. The engineers proposed the products. They talked to customers. They tried to produce very high-quality products. And put them in the market. And then the marketing arm of DEC was not– I would say during those years was a really strong. I think it became strong after that. Much stronger, because the focus of the company became much more marketing-oriented than it was engineering oriented. But Microsoft was very marketing oriented. Microsoft was– while they marketed the PC software DOS to IBM, so they were very more marketing oriented, which, you know, I thought was– I liked that, because– I liked it and I didn’t like it. I liked it because it was going to be– I was going to have a group of marketing people that were really going to be out hawking the projects, or products. On the other hand, I didn’t like it because they might have their fingers in what we were going to do. And it turned out that the original version of NT was pretty much an engineering-driven thing. Except for a couple of things and that was that in addition to
being portable, Microsoft wanted the system to be compatible with multiple operating environments. So that sort of led us to an architecture within NT that would allow different subsystem personalities. And so we had to keep IBM happy and run OS/2. Of course we want to run DOS. And then the other thing that was big was very popular. Big, was popular, was POSIX. These are the standardized UNIX interfaces. So the personality of this thing was going to be this multifaceted thing. So, let’s see, I’m trying to think. Why did I go down this road? Cutler: Oh, okay, we were dropped in. Cutler: So anyway, the Microsoft people, or Microsoft sort of dedicated that level, but none of the rest of the levels. The rest of the level was pretty engineering-driven. And we set about designing Windows NT much in the same way that we had set about designing VMS. Except that in terms of Windows NT we decided to produce a much more detailed specification of the system. In VMS, we sort of had– we had this small group, and we spent a lot of time talking about things. And we did do some specs. But they were pretty rudimentary specs. For NT, we wrote a humongous spec. And I would say it was over six months, about how the whole system would work, so that people could pick up the spec. As new people came in, they could pick up the spec and understand it and read the code and actually kind of understand what was going to go on. Our first projected delivery date for the OS was like two years. And that actually took us five years to produce the first OS. I could have never– if you’d ask me even today if it would have taken five years back then, I would have said, “No,” I’d say, “We could do it in two years.” But there was so much more to do. VMS did not have a graphical user interface. We had to do that. We didn’t have the subsystem problem in VMS. We had a running multiple personalities. We had to run the PDP-11 binaries. And we produced what was called the AME, which was the Application Migration Executive. And we ran all the– in fact, that’s how we got the VMS software out was by running the 11 software on the VAX. Saviers: Completely unconstrained architecture in the I/O, and so on, in the PC. Cutler: Right. And so we had a lot more to do. And we started out with this idea that we’re going to produce the first RISC PC and we’re going to produce the software for it, and we make this– well, I can’t say that we make this mistake. This mistake has already been made for us when we get there is Intel at the time is producing the i860. And this is one of the fastest RISC machines in certain applications. And those applications are mainly graphics. So Microsoft wanted to use that as the microprocessor for our first reference implementation. We were going to build a reference implementation of the 860 and we got one of the OEMs, which was Olivetti, that signed up to build this. So we were going to build the reference system, and they were going to take the design, make it manufacturable, and manufacture it. We were going to build the software. But then part way through that, we found out that the i860 was pretty sick. It had a lot of errata that would make it pretty unusable as an OS-based system. It had some quirks that were– made it very nice for the graphics world, but not very well for the operating system world. Had a virtually tagged cache. So basically every time you switched context, you’d sweep the cache, because it has all the virtual tags from the last address space you ran in. So anyway, it took five years to do the first version. So I guess the original question was, “How different was the environment?” Well, the environment was a lot different, because DEC was an engineering run company, and were always based on engineering excellence. Microsoft, I think, justifiably, I would say, is a marketing-based company. And they weren’t based on engineering excellence. So there was sort of a little clash between our culture, and
the Microsoft culture. But I think that we instilled a lot of that into the Microsoft culture, but we still had a lot of things going on that were sort of outside our control that were within the Microsoft culture. So it made the project a lot longer, and the environment– it was very different. Saviers: Somewhere along the way, you said to me, “There were a lot of coders at Microsoft, but no software engineering.” And you had to bring the discipline of software engineering to Microsoft. Cutler: Yes, I think one of the things that we brought was the engineering discipline on building software, and I don’t think that Microsoft had the engineering discipline that we had at that time. Of course, you know, that’s 28 years ago. That’s a long time, and the discipline at Microsoft now is, I would say is excellent. There’s a lot of stuff in place. It’s not the same atmosphere that we had with the original NT team, because our team was small. You know, we started out with 25 guys. At the end of Version 1, were At the end of Version 4, were 400, which is big– today it’s 4,000. Saviers: Now along the way, a lot of things get added to what NT is. I guess you had Program Managers, that was, I think, the title. Cutler: As far as the culture and environment, at DEC we had Program Managers, but Program Managers were sort of– they were quasi marketing people in some sense. They didn’t try to manage the engineering effort. The engineering effort was managed by the engineering people. So there was a big clash in the beginning between me and the Program Managers of Microsoft over who did what. And I wrote– I wish I could find this piece of mail I wrote. But I wrote this big thing, big piece of mail to our Program Manager about his job and mine, which laid out what I thought his job was, and what my job was. And so that pretty much worked itself out, because we pretty much operated the way we did at DEC. But over time Program Managers at Microsoft had taken a more direct involvement and control over what happens. Saviers: So you have this enormously complicated thing. Multiple platforms you’re going to run on, portability. Keeping control of this, and keeping everybody moving for five years gets to be quite a challenge. Cutler: So a little bit about the complexity of what we’re building. We talked about the 860, and the problems with the 860, well, part-way down the road, we’d only went about a year, and we decided there’s no way we can go with the 860. And so we said, “What should we do?” So we said, “Well, how about MIPS? MIPS is doing the R4000. That’s the platform that we ought to make the first one.” So our hardware groups switched to the R4000, and we started to go in that direction. Now, just to make a lot of difference to the operating system, because the way the operating system is structured, or was structured was we’re sort of taking the stuff that was absolutely portable, and it was still portable, and then the stuff that was hardware architecture specific was divided out so that you just had to replace that. So the first thing that happened was DEC got wind of what we’re doing and says, “Well, gees, we’re building an R3000 workstation. Why don’t you support the R3000, too?” So I guess, foolishly, we said, “Okay, we’ll support the 3000, too.” Well, that put us into some difficulty now, because the 3000 is not entirely compatible with the 4000, so now we’re building for two platforms. So we had the R3000 and the R4000. And not long after, said, “Well, it looks like it’s going be a little while longer than we thought. Maybe we
should add the 386 back into the mix here. You know, Intel’s coming out with, I think it’s a 386-25, 25
megahertz.”
afternoon and we’ll go get beer and pizza and chips, and we’ll meet, and just everybody will get to know each other.” So this grew into a huge thing! I mean, I can imagine five years and every Friday night that you’re doing this. We start out, we’re in a room about this size, and we end up in a huge room! And we start out that I send the development managers, there was like four development managers under me, I send them down to Safeway to buy a few beers and pick up some pizza and bring them back, to the end when we have full catering from Marriott. Marriott’s bringing everything, and we go from like chips and salsa and beer or pizza, to shrimp and all sorts of stuff that’s catered. Kegs of beer. I mean, it was interesting. And then there was some things that were, we’d always have something going on where we tried to get people to feel better about what’s going on, and how much stress they’re in. I know that there’s some people that felt they were under a lot of stress, and sometimes they’d break, but I think generally we held everything together pretty good. Saviers: So blowing off steam with the team. Skiing, racing. Cutler: Well, one of the ways we blew off steam a little bit was in fact the guy that was the Microsoft guy that had joined us early on, decided that it would be a great idea to go down to Laguna Seca and go to the Russell Racing School. So I think about maybe eight of us went down to the school and we went to the beginner’s school, which I think was four days. And we were in a Mazda open-wheel car. And you know, that was a good thing to blow off a little steam. And it was really an eye-opener about, for me, about driving a racecar. I really wasn’t very good at it. Or wasn’t as good as I thought I should have been at it. And the beginner’s school, they just teach you basically how do drive the car, about the dynamics of the car, G-forces, cornering and all that sort of stuff. But then they have an advanced course where you actually at the end of the course you get to do a race. So a few of us decided, “Well, we’d like to go to that, too.” So, I don’t know, a couple/three months expire and we go down and we do that. And so we do the race. We go through the advanced school, and they do some more things. And I’m getting a little better at it. And we finish that, we do our race, and that was fun, so I thought, “Well, maybe, you know, they have the School Series, what they call the School Series.” And you basically go down once a month, and you race on Saturday, and then on Sunday, and then you come home. And Debbie1 was involved in this, too. Debbie came down and did the beginner one and she did the advanced one. And so she and I would go down there every month for, I think we went down from, oh, somewhere in March to September, something like that. Every month, so it was ten races or something like that. So I did that. And that was fun. And so then they had– every year they had what they called a Pro Race. And the pro race they would– they didn’t have governors on the systems, but they sort of would tune– they would open them up a little bit. They’d reprogram the ECU, the Engine Control Unit, and give them a little more horsepower. And they’d say, “We’re going to Pro Race now,” and the Pro Race meant there was a prize package, and you could win some money. I think probably the top was 10K or something like that. But this would draw a lot of drivers that were pretty good. So I did one of those. I think I finished next to last, only because one guy, my first one, only because the other guy was worse than I was. So then I got involved with a guy that was one of the instructors down there, and another guy that owned a race team to import an Atlantic car from New Zealand. And that was when I started into the racing really seriously. And so I owned that car, and he raced that car one year, which was 1995, and the next year I decided that, well, we really should
have a new car to race. So I bought a new car, and so the question became what to do with the old car.
So I climbed in old car, and gees, I was pretty good. So I decided, “Well, I’ll race in this series.” So I
started racing in the Atlantic Series and I raced 56 races in that series. And had some pretty horrific
accidents. Nothing that I was really hurt really badly in. But one at Laguna Seca is sort of an infamous
one, because ESPN played this over and over and over again for, I don’t know, five minutes of broadcast
time or something. And one of the turns I did a longitudinal flip. So you think about a flip as going endover-end. It was a barrel-roll flip. I did a flip like this, and landed on the top. And it was in a corner where it
was really dusty and the dust flew, and there was big dust clouds.
Saviers: What turn was that?
Cutler: It was Turn 10 at Laguna Seca.
Saviers: So a fast downhill sweeper–
Cutler: To the right.
Saviers: To the right, yes.
Cutler: And ESPN picked that up, and they just played that– they played it over and over, because
there’s a certain amount of time they have to– the yellow goes out, they have to clear the track, then they
have to get the wreckers out and upright the car. So the race is,
Saviers: Stopped.
Cutler: Stopped. But they just keep playing this over and over and over again.
Saviers: Your favorite one? Cutler: The Milwaukee Mile, by far. Nazareth, Pennsylvania. I raced there, too. Saviers: Any analogies from racing into software development? Cutler: Yes, actually, I think there is. It’s focus. I’ve always been a person that really can focus on the job at hand. And racing is– driving a race car is focus. I mean, what happened ten milliseconds ago, it’s gone. You’re going to focus on what’s coming up and what’s going to happen. So I think there’s some analogy there about being really successful, I mean, in anything, it’s to focus on what’s important, and what you have to achieve to get to the success. So in racecar driving, it was just another example of that. Saviers: So the super intensity of concentration. When you’re writing code, how do you achieve that? Can you stand music being on, or want to be in a quiet office? Cutler: In general, noise doesn’t bother me much. I would prefer that somebody’s not– there’s one guy at work now that whistles. And that’s not a problem, but he whistles down the hall, and I’m like, “I really don’t like that.” But generally noise doesn’t bother me much. But I do focus on what’s going on, especially if I write a new piece of code, you know, I’ll write the code and I will spend maybe three or four iterations of executing the code in my mind. All the error paths, all the paths it can go through to see if I can prove that it’s correct, before I even run the code. And most of the time when I run code, it pretty much runs the first time. It may not be absolutely correct, but it will run. It won’t crash. So that’s being able to focus on what’s going on, and not have things bother you or whatever. Saviers: In the NT program, it was demolishing bugs. How would you change the process to create less errors and make them easier to fix? Cutler: The easiest– probably the easiest bugs to fix. well, the question is how to make bugs easier to fix and– Saviers: And fewer of them. Cutler: I think fewer of them is probably the easier of the two, because the fewer the bugs are, the harder the ones that are left are going to be solve. And the hardest bugs to solve are the ones around synchronization. They’re not around correctness of code flow. They’re around the correctness of synchronization, where there’s not the correct barriers, there’s not the correct locks, or there’s race conditions between code paths, or something. One of the things that also exacerbated the five years was multi-processing. I had the bee in my bonnet when I went to Microsoft that we were going to produce MP systems. And nobody else was producing MP systems. DEC had, at that time they had the VAX 782, which was this funny asymmetric thing. And we had an 11/70 that actually was SMP, but there was some Unibus problem that we decided not to manufacture that. So SMP problems, synchronization is a big problem. The problem with less bugs is, I think, through the engineering process itself, and the people– you got to have– quality has to start from the bottom up. It can’t start from the top-down. You can’t
legislate quality, quality has to be something that’s inborn in everybody at the lowest level. And any link in the lowest level that doesn’t produce a quality piece produces bugs up the line, because they interact with other pieces of the system. If you’re building the lower levels of the system, then your leverage as far as causing problems up in the levels is very high. So I think reducing the number of bugs is basically thinking more about quality and paying more attention to quality. I don’t think that necessarily you have this thing where, “Well, we’ll do 100 percent test afterward. You know, we’ll do everything and then we’ll test to see how good it is.” It’s got to be built in to start with. So I think building systems with fewer bugs means paying attention to that all the way along. And not– for me, I hate it when there’s a bug filed against me. I don’t like that at all. And I don’t want that bug to exist filed against me for any longer than I have to. I’ll drop everything to go fix that bug, because I know I can fix that. So there needs to be that kind of mentality. I mean, there’s a lot of people that say, “Oh, yeah, I got 50 bugs. Oh, you know, I’ll get them fixed.” Well, it’s like quitting smoking. You know when the best time to quit smoking is? Right now! It’s not an hour from now. Or a day from now, or a week from now. It’s right now! So the best time to fix the bug is right now. So that would be fewer bugs. Make them easier to fix, I don’t know how we’d make them easier to fix, other than building better tools for analyzing what’s going on, I guess, is primarily the way we would make them easier to fix. And we have lots of tools now. We have lots of tools that do the same thing. You know, that somebody has said, “Well, that’s a good tool, but I’d like the tool to do this. I don’t own the tool, but I think I could build a tool that was a little better that would do this, and maybe we could find something a little better.” And so we have a lot of tools. We have a lot of source level tools. One of the big problems that we had partway through the evolution of NT was hitting a big security attack or wall or whatever. Somewhere after about 2001, somewhere in there. The internet, we really got going on the internet somewhere in the late ’90s. And the internet suddenly had problems with people with viruses and trying to attack your system. So we developed some tools that analyzed the source and tried to find places where you have buffer overflows - are the biggest one. And the amount of buffer overflows that we had was just mind-boggling. And it was like we have this tool, and the tool says, “Look it, right here, this could overflow.” And so that was great, I mean, that made it so that it lowered the bugs. Even things like, I mean, an arithmetic overflow can cause a bug because maybe you’re calculating the size of the buffer that you want to allocate, because you got a byte count, and you do this computation and, gees, that overflows. And now it looks like you need a small size. So you allocate that size, and then you use this other size to transfer data into it, and all of a sudden you have a problem there, so you have some tools that analyze the source, and actually point out places where there’s bugs. And we actually fix those like they’re bugs. The problem with those tools are that they’re static analysis and they have a lot of false positives. So you see a lot of things that aren’t really problems. And they can’t see some things. You may have, in your code, you may have had logic that made it impossible for the thing that it’s complaining about to occur. And it’ll say, “Hey, this is bad.” So those have to be filtered out. And so we have ways to filter that out, too. Saviers: If you go back a little bit to getting programmers to really produce good code, is there a Dave Cutler School of how to get a programmer moving along in that direction? Cutler: Do I have a way to move people to build good code? I guess the only way that I can say that I have– help people build good code is by example. Everything that I do, I try to make it my best. And everybody sees the source. And obviously they see that I don’t have a very big bug count, or a zero bug
count. They look at my code, and I hope that that really helps them become better programmers. But
another aspect of this is really with the young people starting out to really engrain in them the importance
of quality. I mean, for me, there’s nothing worse than software that doesn’t work. I mean, I just can get
really upset with software that doesn’t work. Where it’s obvious that something just– I mean, it’s
something simple. I mean, if something doesn’t work on your phone, or it doesn’t work on your tablet, or it
doesn’t work on your PC that should work, it should infuriate you, because it just should not be that way,
right? It should be– all the stuff that doesn’t work should be stuff that is little tiny things. Maybe it’s like
there’s a few pixels over here that are wrong. Or something that’s just minor. In fact, a lot of the bugs that
are– that have been and continue to be filed against NT are these kind of things. They’re cosmetic things.
And they tend to– they have low priority. So those things are not upsetting, but it’s upsetting when you
have something where you ship a product and it’s in the field for four months, and all of a sudden there’s
this disaster that happens where you wipe out somebody’s data, and then all of a sudden, it’s like, “Wow,
that’s really a problem.” So I think quality is something that starting out with young people and saying,
“Hey, you know, we really got to have quality.”
Saviers: So we come to ‘93, I think the final release date of NT? Or the official release. Millions of copies
shipped.
Cutler: The initial version of NT is shipped in 1993. And then we shipped, NT 3.5, which was Alpha
support about six months later. And part of that was also a kind of cleanup, let’s improve the performance
of the system release. We did not have the performance level in the system in the first release we would
have liked to have had. It was a little bit bloated. Now bloated in those days was like maybe it took 24
megabytes.