Debug is a casual, conversational interview show featuring the best developers in the business talking about the amazing apps they make and why and how they make them. In part 1 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about his early career in Developer Technical Support (DTS), working on System 7 in the Copland era, and the advent of Carbon.
Support Debug: Go to squarespace.com/debug and use offer code DEBUG to save 10% on your new website! Go to peek.usertesting.com and use express pass DEBUG to get your results back faster on a free 5-minute video of a real person using your site or app.
- Subscribe in iTunes
- Subscribe in RSS
- Download directly
- Follow on Twitter
Show notes
- System 7
- Copland)
- Carbon)
Guests
Hosts
Feedback
Question, comment, recommendation, or something you want us to follow up on for the next show?
Email us at debug@mobilenations.com or leave a comment below.
Transcript
Nitin Ganatra: I'm actually having a little bit of red wine this afternoon.
Guy English: Oh, a classy fellow.
Nitin: Yeah, well, if you must know, it's actually red wine out of a box.
Guy: Perfect.
Nitin: Maybe not that classy.
Rene Ritchie: That's the kind of show we are.
Nitin: That's fine. I have varied range of taste buds, so, I can drink midrange wines, things like that.
Guy: Right, yeah. It's good enough. You're a famous actor, how did you get into acting?
Nitin: Well a long time ago when I was born in Kenya, I...
[laughter]
Nitin: I'm sure you're referring to the actual famous, Nitin, or Nitin, Ganatra. Interestingly, we've actually made contact with each other over the years. In fact I have a picture of him. I'm not sure if you know this, but there were some ads that were done for the iPod back in 2000, 2001, something like that. Nitin Ganatra was the actor in it. He was the Indianish looking guy dancing to Propeller Heads, or something like that.
I think it was part of the "Rip. Mix. Burn." campaign. A friend of mine who worked in product marketing, she got a chance to talk to him. So I got this Polaroid from him that says, "To Nitin Ganatra, from Nitin Ganatra." I still have that.
[laughter]
Nitin: Even today, we follow each other on Twitter, make comments back and forth, and things like that, although we've never actually met. But, yeah, it's a little odd having what I used to always think was a somewhat obscure name, only to find out that it's the same name as the celebrity.
Guy: [laughs] Yeah, that is pretty funny. If anybody out there Googles you right now, they're going to find out that you've got a pretty successful acting career.
Nitin: Right. I'm really a Renaissance man.
Guy: [laughs] So I guess you program then.
Nitin: Yeah.
Guy: Kind of boring. But yeah. So how'd you get into technology?
Nitin: Oh, boy. OK. I'll try to....
Guy: Right. Reconstruct it.
Nitin: [laughs] Exactly. I'll give this to you in real time. It started when I was nine years old. No, really, my first exposure to anything related to technology was the Apple IIs that we had in our elementary school. We had these horrible text-based games, but that was what we had. The first one that stands out was either called "Trek" or "Star Trek."
It was a very early Apple II game. I think it's 1979 we're talking about here. It was just fascinating that here's this machine that I had only ever seen in pictures in magazines, on important people's desks, or things like that, and look, we get to play with it, too. Not only do we get to actually use this thing, but we're playing a game on it. The whole concept of video games at that time was just so new, too.
The fact that, as a little boy, you get to play games for the first time was just phenomenal. That was my first exposure. I didn't really get into programming and things like that until I got my own Apple II, which was a few years later. I think I was 12 or 13 years old, and I had, oh gosh, I believe it was a II+, but I did have an 80-column card in it, so there was that.
Rene: That's exactly what I had.
Nitin: Oh, really. OK!
Guy: Same here, too.
Nitin: Nice. Nice. It was great, because it had Applesoft built in. It had this other bizarro Integer BASIC thing built in, but I never really wasted time with Integer BASIC. It was all Applesoft.
Guy: I don't know who did. I don't even remember what the purpose of Integer BASIC was.
Nitin: Yeah, exactly. I remember even at that time, it felt like it was this weird thing. It didn't seem as well-documented as Applesoft, and it was different enough. It was all uncomfortable enough that I didn't want to be messing with something that didn't seem like it was as well-documented. But yeah, you're right. I wondered the same thing. Like, "Who the hell did they make Integer BASIC for, and why is it still on this machine if there's this thing called Applesoft on here?"
Guy: My theory was "That's for the big people." Like, "The grown-ups use Integer BASIC."
Nitin: Oh.
Guy: I'm pedaling with the real one, the one that I'm supposed to be using.
Nitin: That's interesting. I never thought of it that way, but I could see how that would come across. Applesoft is kiddie BASIC, and Integer is a man's BASIC or grown-up BASIC.
Guy: Yeah, it has a big word in front of it.
[laughter]
Guy: I was pretty young at the time. I hadn't even realized that, yeah, you'd probably not be using BASIC at all to be writing anything sensible. Was BASIC your first language, and how long did you run with it?
Nitin: Yeah. BASIC was my first language. It started with dopey little programs and getting -- gosh, I forget what the magazines were called. I think there was one called "Apple Insider" or "Apple Cider," maybe. It was C-I-D-E-R, something like that. They had the huge multi-page listings of BASIC programs.
It was funny, now looking back, just realizing that they had these things called GOSUBs, and there were these GOSUBs everywhere. What the heck. In the early days of Applesoft anyway, I never used a GOSUB anywhere. It was just execution starts at the top, you go down to the bottom, and that's it.
It wasn't until a couple years later when I started playing with Apple Pascal, with UCSD Pascal, that I saw the value of having these things called subroutines, breaking programs into functional units, and things like that. So yeah, it was Applesoft for at least three or four years there, and even a little bit of 6502 Assembly, because while I...
Guy: You have to, kind of.
Nitin: Yeah, exactly. Your path to manhood is you have to do something very, very difficult, I guess. I don't know.
Guy: You inevitably hit a wall with Applesoft, where you want to do something cool, you know it can happen, and I think they gave you the manual, didn't they? The ring-bound manual had all of the opcodes and stuff in it.
Nitin: Yeah, that's true. That's actually a good point. I think that the motivation for it was at some point you run into limits around, "How fast can I draw graphics to the screen?" In BASIC, you really can't draw them too fast. It was sort of, "Why are my programs so slow and shitty? There are these games now starting to come out, where things are just bouncing all around the screen. How do they do that?"
The answer was always Assembly. It was just this cryptic thing. That was my first exposure. Unfortunately, I never got as far at that point as writing a game or doing anything more than a page or two or a screen-full or two of Assembly.
Guy: You were already doing it, because you use Assembly where you need to and not where you don't.
Nitin: Right.
Guy: Good discipline there. So you got into the Pascal side of things. On the Apple II?
Nitin: Yeah, that was also on the Apple II. The Apple II that I had had a disk drive, but I didn't have two and I certainly didn't have four. I'm not sure if you ever used UCSD Pascal, but at the time, if you wanted to compile something, you had to stick in another floppy.
When you wanted to link your program, you had to take out that floppy and stick in a third floppy. When you wanted to bring up the editor, you had to go back to the first floppy. It was really the compile-run cycle. There was no debug, as far as I recall, anyway. I never debugged at that time.
[laughter]
Nitin: Really the compile-run cycle was this three-floppy thing. Of course, looking back it was awful. At this point, it's my second experience with a high-level language, but Pascal felt so much more natural than Applesoft. It required these three floppies and it was from this university, and so this is real big-boy computing here. And Pascal just made it so easy to create functions or procedures and pass arguments.
Guy: Structures and all that, or records, I guess.
Nitin: Yeah, records.
Guy: I still have a soft spot for Pascal.
Nitin: I do, too.
Guy: I graduated from Basic into doing Turbo Pascal on a PC. You could do in-line Assembly on it, and so I wrote so many games in Pascal. It seems like it gets a little bit maligned, but it's great in so many ways.
Nitin: Absolutely. Even much, much later in life, when I went to Apple and started working there, there were definitely pockets of people there who felt like, "Why did we give up this Pascal thing?" It didn't have all these pitfalls that you had in C. The compiler the was better. The environment was a little nicer. A lot of people felt like it was a step backwards. I remember feeling that same way, and having a soft spot for Pascal.
Guy: I don't know if Objective C's a step backwards from Pascal. [laughs] Some people just rag on it all the time, and I don't think it deserves it. It serves its purpose well.
Nitin: I'm sorry. To be clear, I was just talking about people who were comparing MPW C to MPW Pascal.
Guy: Oh, OK.
Nitin: Then there was this new thing called C++, which had these horrific compilers. All of that, especially in the early '90s -- we can get to that later -- was...
Guy: Yeah, that's a much more apt comparison.
[crosstalk]
Nitin: No, I don't feel like it's [indecipherable 00:12:01.08] .
Guy: The original Mac was all built around Pascal 2.0 blocks.
Nitin: Yeah, exactly. It's hard for me to now go in there and look. While much later, I expected this wonderful world of something that looked like somewhere between UCSD Pascal and Think Pascal as being the entire operating system, written in this glorious language. Getting to Apple was an eye-opener, realizing what it really was. We can get to that later, too.
Guy: Yeah, we'll end up in the sausage factory, eventually. [laughs] You haven't done any programming in school by this point?
Nitin: When I started to learn Pascal, there was a summer school program that I was taking. That was either late in middle school, or early in high school. It was somewhere around there. I think it was late middle school when I was learning Pascal. That was in a learning environment. Obviously, you learn for two hours and then you go home and plunk away for four or five hours, until you get tired of exchanging floppies and find something else to do.
Guy: The bug caught you early, the iterative programming bug.
Nitin: [laughs] It did catch me early. In some ways, it may have caught me a little too early. By the time I was a junior in high school, I felt like I was done with computers. Obviously, I hadn't learned anywhere near everything that I needed to. There was so much that I, obviously, didn't know and so many things that I hadn't done.
But I had learned enough to satisfy me. I became comfortable in the little world that I understood and felt like, "Maybe I'll go look at other things, like playing tennis, hanging out with friends, or watching music videos."
Guy: That totally rings true for me. I did anthropology and history in university, because I really didn't want a computer job. Turns out I did want a computer job, and they're awesome, but from the other side of the fence, you can see it being boring or staid. It was my hobby, and I didn't necessarily want to sully my hobby by doing it all day.
Nitin: Yeah, that's funny. That's really funny, because that's very similar to what I feel happened to me, too. Yeah, it was my hobby and it was this thing that I was interested in. I don't know what I was thinking. I was a little dopey kid, but I just couldn't imagine going to an office somewhere and doing computery stuff all day.
Guy: Yeah, it seemed it could get boring, right? [laughs]
Nitin: Yeah, it seemed kind of boring, exactly. Like you said, it was taking my hobby, this thing that I was interested in, and now it's become labor. [laughs] Yeah, that's funny.
Guy: But, eventually you did. [laughs] What happened? What'd you do in university?
Nitin: By the time I got around to applying to colleges and things like that, I'd put computers aside and decided it was time to grow up and do something more grown up, or God knows what.
Long story short, I had taken a couple of economics classes in high school and some history courses. I was really more interested in that and, particularly on the economics side, how human behavior is impacted by an economic environment.
Guy: That's interesting. Is that the relative systems from the programming? Is there a kernel of commonality there?
Nitin: I'm not really sure. Maybe there is something there.
Guy: I don't want to psychoanalyze you over Skype, or anything.
Nitin: It's interesting. I hadn't really thought of it that way. We can get to it, but I'm not really sure. There may be something do that, but I feel that it was really music that brought me back into computers, later when I was in college.
I went into college. I went to UC Santa Cruz, in the economics program. I went to Crown College there, for anybody who knows UC Santa Cruz, and very quickly after that went to Kresge, which was the art school. I took maybe two quarters worth of economics courses and realized that I'm never going to get past all this mundane crap to get to the part that I'm really interested in.
Guy: The high-level, human behavioral stuff is fascinating, and then you've got all the nuts and bolts of day-to-day economics, which is a drag.
Nitin: Exactly. Yeah, exactly, the elastic versus inelastic spending, and the macroeconomics and micro. It was just any where near as interesting as I imagined it was, and it certainly wasn't as interesting as the courses I had taken in high school.
After my first year, it was pretty clear that I knew I wasn't going to be an econ major, but I really didn't know what I was going to be either. It was around that time that I had picked up the guitar and started learning how to play guitar. I'm not sure if the same is true in Canada, but in American universities, especially for freshman and sophomores, there's plenty of time during the day to do things other than studying.
Guy: Yes. [laughs]
Nitin: [laughs]
Guy: If there's not, well, you'll just make time. It's fine.
Nitin: Yes, exactly. Even if there really shouldn't be that much time, yes, like you said you'll make that time, and maybe fail a class here or there, or things like that.
After my first and second years in college, it was clear I wasn't going to go into economics. Computers was this thing that I had dismissed long before I ever got to college. Then it was, "Well, political science is kind of interesting." I was taking more and more courses in history and poli-sci, but even that, there was something very unsatisfying about it.
It was really when I had taken some creative writing elective courses that the lack of a correct answer in any of these humanities-based courses just really left me unsatisfied. The fact that anybody could come along and claim whatever the hell they wanted, whatever theory about political systems, about why socialism works well, or why it's the worst thing in human history.
You can argue either side in what's deemed a very legitimate way, and really, there's no right answer, there's no wrong answer. And, that's true. That's how the world works, but that lack of a right answer left me wanting more.
Guy: Yeah, it's unsatisfying, and they're untestable, anyway.
Nitin: Yes.
Guy: You feel like you're going in circles a little bit. How did the music lead you back into programming then?
Nitin: Well, it's funny. I really don't know. It felt like the more I became interested in music and in trying to understand, "Why do we have the major scale and how do we settle 12 notes and 12 notes in an octave, and how is it that octaves are even a thing?"
Once you dive in a little bit and realize that there are these harmonics that are behind music, and audio frequencies tend to double with each octave -- I think that's correct, anyway -- there's real math that describes and helps define what makes something sound pleasant to a human. To me, that part was fascinating. Again, it felt like there was hint of a right answer.
Obviously, people like different kinds of music and people even like different types of performances, but just the fact that everything that people were playing had this basis in mathematics and in physics, it was very satisfying in a way that these humanities-based courses just weren't for so long.
That was the first inkling that maybe I should find my way back around to things where there's more of a right answer, or there's a generally agreed upon correct answer. That's as far as I can tell, you know?
Guy: That's interesting. I know a little bit about music, but I never got into that much. The interplay between music and mathematics has always fascinated me. Music is such a natural thing. Once you understand it there's all of this crazy math behind it that just came out naturally...I don't think people discovered chords necessarily by doing the math to figure them out, but the fact that the math fell out of it fascinates me.
Nitin: Right, exactly. There is this foundation in mathematics that helped explain, as far as we can tell today, what types of tones sound pleasant to a human ear and what ones don't.
Guy: Right, yeah. You can have a discord in sound that makes you feel off edge.
Nitin: Exactly.
Guy: Uneasy, yeah.
Nitin: Yeah, and there are scales and modes that you can play in. In music, there almost is kind of a right answer and wrong answer. If you want to give somebody a feeling of tension or of sadness, you play minor chords, diminished chords, these diminished scales, or things like that. It's almost like seeing through the matrix, right.
Guy: Right.
Nitin: There's music, and some of it sounds good, and some of it sounds bad, but behind all of it there's physics and math. That was very satisfying in a way that other things hadn't been up until then.
Guy: Yeah, I know. I can see that. You what, started taking computer classes?
Nitin: Yeah. It was around that time that I realized that was the part was missing, the fact that everybody could be right or that everybody could be wrong in some of these other courses. I'm sure this sounds like alien to some of your listeners, but there are some of us who are wired up this way I guess.
Guy: I think pretty much everybody out there feels that they are right all the time. Don't worry about it.
Nitin: [laughs] Well, I know I'm right, so yeah.
Guy: Right, exactly. Yeah, me too. See, we're both right.
Nitin: [laughs] Exactly.
Guy: Problem solved.
Nitin: I took a couple of more music theory courses and enjoyed those, and continued playing guitar, although never did anything worth note with it. It was just a fun hobby. Then, eventually, I came back around. I thought, "Well, why not..." I had some friends who were complaining about one of their data structures courses or algorithms courses.
They're describing how sorting works or something like that. All of a sudden I felt like that was something that was very interesting to me. That was something that I wanted to dive in and learn how these algorithms work. The fact that these algorithms can be applied to any computing system was just fascinating.
It wasn't that on an Apple II you must always use Bubble Sort...I don't even know what I was thinking, but the fact that you can really separate algorithms and a lot of the computer theory from the actual system you were running on was also a very interesting thing.
Guy: The science side of things is something versus the engineering side of things. The greater truth of computer science interested you as a purer entity.
Nitin: Yeah, exactly. I didn't go ape shit with it, and it's not like I was real interested in DFAs and NFAs. Computer theory can go off the deep end too, but just the fact that there was this body of work that was done to of show, "Here are how you solve certain types of problems, regardless of the system that you're on," was the first thing that caught my attention and sucked me in.
Then I took some algorithms and data structures courses. By then, I was right back into it. It became the thing I thought about while I was taking a shower. If I got something wrong or if I screwed something up, I really wanted to understand why and learn more. I was just generally interested in it at that point, in a way that I hadn't been interested in anything at university up until that point.
Sadly, this was I think the end of my second year in college. I had taken my first undergrad course in computer science, so I had a lot of catching up to do. I had to move fast to fit in all the course work and graduate in a reasonable amount of time.
Guy: You graduated with a comp-sci degree?
Nitin: Yes, I had a comp-sci degree. I didn't get it in four years. It took me four years and two quarters, something like that.
Guy: That's not bad with two-year...
Nitin: Yeah, that's true. I had put myself through hell. By my fourth year, I was ready to be out of college. I just wanted to get out and work. [laughs]
Guy: Yeah, I bet. Did you join Apple straight out of college?
Nitin: Yeah, I had applied for a couple of jobs and didn't get them. In hindsight, it's great. One of them was working for Amdahl, which was a big mainframe company. I believe they were in Scotts Valley, and a couple of other jobs. It was mid-summer or early summer, after I had graduated, and I was staying up here. Moving back home was not an option. I wasn't giving myself that option, yet.
After applying to a couple of positions and not getting them, I went and joined this contract place called, Oxford & Associates. I had heard that they had some ties to Apple, that lot of people who had contractors at Oxford tended to go on to have contracts at Apple.
Guy: Is that the same one our mutual friend, Juckett, was at?
Nitin: I wonder.
Guy: He did something similar. He had a contracting gig during QA I believe, at Apple.
Nitin: It wouldn't surprise me. Oxford was a big feeder into Apple at the time. Yeah, it wouldn't surprise me at all.
Guy: I'll check with him after, but it's the same story, or at least very similar.
Nitin: Yeah, exactly. I got a job though Oxford contracting to Apple's Developer Tech Support group. I started in DTS. I had worked under contract for six months with Oxford, and then a full-time position opened up at Apple. I applied for it and got the full-time DTS job.
Guy: How was that? That's an interesting job to get right out of school. School, not to sound reductive, but it's a more scholarly approach. When you get into the deep end of QA and all of that, that's a very nuts-and-bolts end to the spectrum. It was at a bit of an adjustment for you?
Nitin: Yeah, it was an adjustment, but, in some ways, it was exactly what I wanted. DTS, I can't recommend it highly enough. I can't recommend it enough. In a lot of ways, I was paid to learn. I was getting, gosh, I don't even remember, like $20 an hour. I was getting paid $20 an hour. I'd never been paid that much before. It was well over twice as much what I had made before that, and I got to learn about Macintosh programming.
I was getting paid, what I thought was a stupid amount of money at the time, to learn. Previously, I had been learning this stuff in university, and I had to pay. I had to pay tuition to learn this. The stuff that I was learning, by the way, wasn't anywhere near as interesting as once I got into Apple.
Developer questions would come in, and I hadn't ever written anything against the Macintosh toolbox by the time I gotten into DTS. The first three months were just figuring out, generally, "Where am I interested in?" and the latching onto the smartest people in DTS who happened to be brilliant people on their own.
It takes a special kind of talent...It's almost cliché now, but when a developer writes in or when anybody ask a question on Stack Overflow, the clichéd response is, "What are you really trying to do?" A lot of times, you get these nutso questions, and it's, "Huh? You want to do want?"
Guy: The question itself is like, "How do I ride my bicycle along a train track. It's like, "No, don't, please don't. Where are you trying to go? I'll give you directions."
Nitin: [laughs] Exactly. I want to use QuickDraw, but I want to use it at interrupt time. It almost works well but not quite, how can I make it work all the time? It was, "Oh, my God. What are you trying to..." At the beginning, it's was, "What is interrupt time and how does that work into how the Macintosh toolbox works?"
Every single question that I got was an opportunity to go and pour over Inside Mac, pour over sample code, and go and talk to the really smart people who were in DTS, who knew this stuff backwards and forwards. Thank goodness, now, they weren't going to give me the answer. They were teaching me to fish. They weren't going to give me the fish, but they were going to say, "Have you looked at 'Inside Mac' memory? Look at the set."
Guy: That's great. You don't know necessarily why interrupt time is special, until you've actually understood how the system works.
Nitin: Exactly, exactly. They're going to spoon feed you just enough so that you know where to look, but then it's really on you to go look and do the deep learning.
Guy: [indecipherable 00:34:45.17] .
Nitin: I'm not sure. I'm going to drop a name here, or maybe a couple of names. One of the people who I work with quite a bit was Jim Luther, who was in DTS for a long time. He wrote More Files. I don't know if you ever used that. He came from the Apple II. A lot of these guys had come from the Apple II.
I could tell that there was a little bit of resentment between the people who are on the Mac who felt like, "This is God's computer, and this is the way of the future. Throw all those sticks and stones called the Apple II away." And the Apple II people were saying, "We're keeping the lights on over here. What have you done? How much does that thing cost again? How much RAM do you have in that?"
There was definitely a little bit of back and forth. That has started settling down by the time I got there. It was just a phenomenal environment.
Guy: They were selling Apple IIs way later than people expect. I think they stopped in the late '80s, maybe early '90s. I don't know.
Nitin: I think I was still there. I believe they stopped selling the Apple II in '93 or maybe even 1994.
Guy: That's a little bit bananas.
Nitin: [laughs] It was nuts. I think even after they stopped selling the Apple II, you could get the Apple II LC card for a while, as well.
Guy: Obviously, your skills grew at DTS. Then you wanted to start writing your own apps or get into a different group. How did that progress?
Nitin: One of the things that I started doing, other than building up my own body of sample code, tips and tricks, and how to figure out developer problems. It took a while. Including the contract time, I was in DTS for about two years. It was from the end of 1992 until the end of '94 when I left DTS and went into the Mac system software.
I went from asking all these people who are way smarter than me, "Where should I look for this? What could be going on here?" or, "Here's the answer I'm about to give. Is that really the whole story? What more should I pass on." to I started picking up new technologies that were being introduced, as well. One of them was this thing called the DragManager or drag-and-drop.
Guy: System 7 introduced that.
Nitin: Yeah. It came out between System 7.0 and 7.5. I think it came out after System 7.1. It was rolled into 7.5, but I think it came out as an extension that you can install on 7.1 or later. There weren't that many apps out there. Obviously, it was brand new technology. There wasn't that much that showed how to use this thing.
In addition to writing the sample code that would go out to developers and things like that, the few times that I had played with a NeXT machine up until then, I really liked the dock. I thought the dock was just the coolest thing. I couldn't understand why there wasn't a dock for the Mac. How many years ago did this dock-like thing come out for NeXT boxes?
It was so cool, but we didn't have one for the Mac. With drag-and-drop, it was an opportunity to use this now built-in system technology to support drag-and-dropping documents or applications from the finder into something like a dock, and using that as a quick launcher.
Guy: Wait, could you do text snippets at the beginning?
Nitin: Yeah, it did. You could do text snippets as well. It had different flavors, they call them, for contents.
Guy: That's cool. You did a dock, a multi-object...
Nitin: Exactly. It was a little shareware app. It was called Malph, M-A-L-P-H. It started as just postcard ware. If you downloaded this thing and you like it, just send me a postcard. Here's my address. No paying or anything like that. I was more curious to see who was going to send me postcards.
Guy: Those were the days. How great was that?
Nitin: [laughs] It was awesome.
Guy: I never did that. I just love the idea of, "Just send me a postcard." Did you get any?
Nitin: I got a bunch. It was phenomenal. I got postcards from Finland and Germany. I definitely got a number from Japan, obviously, the US. From Canada, I got quite a few. It was really cool. I loved it. You get those postcards, it's just a little acknowledgement that, "Hey, I used that thing that you made."
Guy: It's a more warm and fuzzy thing than getting paid. Not that getting paid is bad, but [laughs] somebody took the time to go out and send you a postcard, which is nice.
Nitin: Now, looking back, with the Internet and everything, it feels so quaint in some ways, right? That was another one of those experiences, just creating this dock and coming out with 1.0, and it was kind of shitty. But building on it and coming out with 1.1, 1.5, just the incremental development process and, "What should I work on now? What are the things that it's never going to do? Because I don't think that they're important."
Fending off all of the feature requests. People want it to be something different from what you want it to be. You got to have the...
Guy: It's...
Nitin: Go ahead.
Guy: It's the truth of having a real product. You can program whatever you want, but when you've got a product, you need to make all of these meta decisions about the actual development.
Nitin: Exactly. It's very helpful if you have strong opinions yourself or a strong guiding principle. I didn't create this thing to become a finder replacement. Everybody has who sent me feature requests that were replacing things that you could do in the finder, that's not really what it is. Is this something that I will personally find useful?
I think that was the other part of it, too. By accepting postcards instead of payment, it was liberating in a way as well. It meant that I could do exactly what I want. You can either use it, and that's lovely and I love that you do use it. Or, if you don't use it, I'm not going to feel like I ripped you off or that you paid for something that wasn't what you expected.
Guy: You know what, you're not beholding to your customers? They come and go. If you like it, that's perfect. If not, that's fine. Did you define what you wanted it to be ahead of time, or did it just grow as you got a suggestion, you're like, "Nope, it doesn't fit," and, through the rejection, come to discover what you wanted the application to be?
Nitin: That's a really good question. It was really closer to the latter. Initially, when I wrote this thing, it was to learn about drag-and-drop and to have a dock that I liked using. I'm scratching my own itch here and maybe other people will find it useful. If I really want a dock, maybe other people do to. Here it is. Knock yourselves out.
Really, it was over time, getting feature request or getting feedback that, "I'd love to use it, but it doesn't play..." The most absurd example that I always use was, I can't play QuickTime movies in a dock tile. It was sort of, "It will never do that. I will never, ever add that to this product. If that's what you're looking, then you should move on."
Guy: Didn't they demo that in 2001 with the OS X launch?
Nitin: Oh, yeah. That's like a good point.
Guy: They minimized the QuickTime movie into the dock.
[laughter]
[crosstalk]
Guy: You got SureLocked, don't you?
Nitin: Oh, no! I got SureLocked.
Guy: Maybe those people are finally happy. [laughs]
Nitin: It really was an organic thing or something that developed over time. Initially, you get a feature request and you're like, "That's kind of cool," or you go, "Not really. I want to make you happy, but I'm not going to add that. It's just not going to happen."
Over time, you can see the pattern in the types of things that you want to add because you find them interesting or you think it's going to make a better product, and the types of things you don't. Based on that, you can create a structure that you can help to use to decide whether things are going to come later.
I'm not sure if you've heard of these Steve Jobs stories where before we went and bought a washer, we sat down and thought about the washer-ness of a washer.
Rene: What's the purpose of a washer?
Nitin: [laughs] It was a lot more organic than that. I didn't have a mission statement or any of these other stuff. It was all just, "What do I want to do? What makes me happy with this product?"
Guy: It develops a set of skills that I imagine will come in useful for the longer story. [laughs]
Nitin: Absolutely, absolutely.
Guy: Meanwhile, you're in System 7 group, right?
Nitin: Yes. Then eventually, I'd moved over to the system software team. I believe the first release I worked on was 7.53. At that time, the system software team, I believe its official name was release engineering, maintenance engineering or something like that.
In the name was baked the fact that we're just doing this thing to keep the lights on for now. We're keeping the System 7 thing running. The people over in Building Two are working on shit-hot thing that you're all going to want later.
Guy: Just the Copeland group, right?
Nitin: Exactly, exactly, the Copelands. It was a very small team of generalists. On any given day, you could work on the virtual memory system, and maybe even in the same day, you could work on QuickDraw or cursor handling.
Guy: That's kind of cool. That's up and down the entire spectrum there.
Nitin: Exactly, exactly, just like DTS. I feel very fortunate to have been part of a group like that. Like you said, you can just jump around and work on all of different kinds of technologies and learn, at least a little bit, how they work before you stumble through and try to get a fix in for Performas or whatever the hell we had to do at the time.
Guy: [laughs] How long were you there? This is '94 or '95, right? Things were kind of becoming a bit of a bummer at Apple at the time.
[laughter]
Nitin: I had learned that things were already a bummer. I took my full-time position in April of '93 in DTS, and six months later Apple had their first major layoffs. I was just shitting myself. It was just, "I've only been here six months. [laughs] I'm the low man on the totem pole. Of course, I'm going to get laid off. I would lay me off."
Already, there was evidence that things were not going great for Apple. You're right, from the time I had joined in late '94 or early '95, about a year later was when Copeland started collapsing on its own, around 1996, all that.
Guy: It's been 20 years, but this is purely political. Was there some feeling of vindication from your group that the Copeland guys collapsed, after having been given all the love and you guys were renamed Maintenance Engineering? You know what I mean?
Nitin: [laughs] Yeah.
Guy: I don't want to go negative on anything, but I could see myself feeling that.
Nitin: There definitely was some feeling like that. I always tried to...I don't know. To answer your question, yes, absolutely, there was. All the stories that we had been hearing about...
As release engineer, we had been involved in very mild ways, doing API reviews and things like that of different components that were going to go into Copeland, and engineers can be an opinionated bunch, anyway, as you may have heard. There was definitely some of the, "What the hell are these Copland guys thinking?" Especially when you see an API come by. I very vividly remember looking at some file-system APIs and I was reviewing them for the Copland file system team.
Actually, Jim Luther and I had been reviewing them. Jim was God of the File Manager, and he later became God of VM for System 7 and Mac OS 8. He was obviously the right guy to review this. We were both reviewing this thing together. We were walking through them, looking at this API, and we were just trying to figure out how to create a file. That was it.
[laughter]
Nitin: There were these APIs that were coming back, and they were so overwrought. It looked like they were written by somebody who never wanted to write an API again. They wanted to create the be-all, end-all, most generalized, most abstracted API, to the point where you couldn't even figure out how to do just mundane tasks.
Guy: To be fair, that was a bit of an industry-wide problem at the time. The mid '90s seemed as little bit...a lot of the stuff that Microsoft was doing was super-overwrought. People fetishized the abstraction stuff in the '90s a little bit too much.
Nitin: That's interesting to hear. I didn't realize that this was an industry-wide problem.
Guy: I haven't seen the exact API you're talking about, but, by-and-large, I find that, during that time period, stuff was complicated, overly so, pretty much everywhere.
Nitin: I'm not sure if you've ever seen the Apple Event interface, the APIs for using Apple events.
Guy: Yeah, sure.
Nitin: That was an example. In my mind, and forgive me if you created...I think it was Kurt Piersol and Ed Li, or some people who'd created the Apple event API. Oh, my God, what a disaster! It was just awful.
Before you could send an Apple Event, you had to create an AE descriptor, and you had to add an AE address descriptor that described the destination for this event that you were going to send. There were so many calls that you had to make just to do the most mundane things. It was so hard to use.
Thank goodness something like AE Gizmos came along later and made it so that the most common things were now a couple lines of code, instead of a gazillion lines, and, "By the way, you better check your error codes on the out, [laughs] for each of these calls, too."
The Copland APIs themselves felt like it was the Apple Events team developing this API with even more complexity. It was the Apple Event interface on steroids.
Guy: Would you say that it collapsed under its own weight?
Nitin: I think some of the "under its own weight" was why it collapses. Really, the biggest thing was just the management. I'm trying really hard here to not bash any individual person or anything like that. I'm going to generally say, "The management of Copland."
There were people who were in positions to make real decisions about the future of Copland, and managing the schedules and the deliverable. Neither of those things was done. It was almost to the point where, without saying names, there were VPs of engineering who were supporting parallel efforts on alternate kernels [laughs] that were not the kernel that was slated to ship in Copland.
Guy: Oh, ouch.
Nitin: When you have things like that, it's sort of like, "Do you believe your own story?"
Guy: You're running a research lab at that point, rather than a product company.
Nitin: That's right. That's right. The one person I'm thinking of, in particular, came from a heavy research background. I think that he knew how to spin up new projects and didn't know how to ever ship existing projects.
Guy: There's plenty of really smart people that don't make for great managers. Different skill sets, really.
Nitin: Exactly. Definitely.
Guy: So Copeland collapses around '96. Are you still in the 7 Group?
Nitin: Yes.
Guy: You're in the Systems Group. So how did you take the NeXT acquisition news? Did you guys know about it before the announcement?
Nitin: Yeah, there were some rumors about it. It was understood that BOS were the frontrunners. In Mac hardware at the time, there were some people who were pushing really hard to use the NT kernel from Microsoft, as well.
Guy: I'd heard that too. Which is interesting. It could have been cool, Because it was running on PowerPC at the time.
Nitin: Yeah, it could have been cool. In hindsight, looking at things like power management or security or things like that, I would not want to have the Windows XP story around security.
Guy: No, no, right. I'm not saying...I think the road that was taken was probably the best road to take, but I don't think it's bananas to consider the NT kernel as a basis for the next Mac. I think it was basically a prudent idea to talk to them about it.
Nitin: Yeah. I think you're right. Absolutely. I think it was good that people were open-minded and were considering all options. At the time, I had played with BOS a little bit, but it seemed like there were some pretty big holes there. It really felt like there was more sizzle than steak.
Guy: You could attach your Mac video onto a Cube, but you couldn't print, really.
Nitin: Exactly [laughs] . There was no real, as far as I can tell, internationalization story, no localization story.
Guy: Single-user.
Nitin: Exactly.
Guy: Yeah, exactly. Interesting, but ultimately probably not what you want to build on for the next 20 years.
Nitin: Right. The other thing is that, at that time, one of the things that was sexy about BOS was the idea that they had this fully-threaded toolbox. As far as I can tell, nothing else had a fully threaded toolbox. It was, "No, it's single-threaded, you can have other threads running in the background, worker threads doing worker-thread things, but you should never render into a frame with two threads or have one window per thread."
I think that was part of what was appealing, but ultimately, I'm glad that Apple made the choice, obviously, that it did.
Guy: B also had a C++ API, which at the time was exciting. But [laughs] the fragile base class thing screwed them a little bit after.
Nitin: Gosh, that's right. I forgot about fragile base class problem. Even early versions, I think, of I/O Kit had the fragile base class problem too, right?
Guy: Yeah. Anyway. Bummer. So how did things get shaken up after that acquisition, from your perspective?
Nitin: To go back just a little bit, one of the things that had happened was as soon as Copeland had collapsed, all of a sudden, a lot of the focus around shipping out to customers came back to the release engineering team. We had been shipping on a pretty consistent basis. We had regular updates. Each release was -- in my mind, anyway -- tangibly better. It was easy to see that it was a distinct improvement over the previous release.
In other words, System 7.55 had a bunch of VM work that was done for it. One of the things that I had been working on these power PC native libraries, but if we didn't use the version that was in the ROM then it was, "OK forget it. Let's try to patch it as the best as we can," and hope we don't have too many mix mode switches.
We'd been creating a little bit of a mess along the way. One of the things that was getting teased apart, was getting improved, first with System 7.6 and then later 8.0, and 8.5, were the introduction of more native libraries. It's hard, because you think, "Well, of course. Yeah, compile a native library. That's a MakeFile fix. You want to run native QuickDraw on that box. Add a native QuickDraw target to that particular box." In it goes and, "What's the next job?"
Guy: Yeah, easy as pie.
Nitin: Exactly, easy to find. Unfortunately, because they were all these different ROMs that we had been shipping and memory was still very limited, there was a strong desire to use as much of the code that was in the ROM as we possibly could if it was working.
We really had this mixed system where we had the ROM that was loaded, initialized and was being used. But then on top of that, we would have this native library overrides and ways of overriding the ROM functionality once we have decided that it was suboptimal or buggy or what have you.
Over time, 7.5, 7.6, 8.0 was getting better and better. By the time 7.6 came around, or shortly after 7.6, Copland had collapsed. A lot of the focus around shipping was switched back to of the only teams that with shipping software at Apple, which was our group.
All of the sudden, we went from the small, rag-tag team that was just trying to keep the Mac limping along until this great new OS comes along, to we were the story. We were the thing that was going to be the basis for what would become Mac OS 8, and then 8.5 and 9.0. A lot of Copland technologies came back to Mac OS because of that, things like Application Services, Appearance Manager and things like that.
Guy: The look of Mac OS 8 was cropped from Copeland.
Nitin: Exactly.
Guy: I bought my first Mac in about '96, so it came in for OS 8 or maybe '97. Basically, as soon as the next got acquired, I'm like, "OK, I'm buying a Mac." But I always felt that like system 7, the point releases could have...System 7 has held back a bit because they decided that Copland was going to be 8.
They could never bump the number high enough to actually make the improvements that were happening in System 7 commensurate with the effort and the improvements of the scale of them.
Nitin: Yes, that was absolutely the case. I wish I could remember some more specific examples. But there were a lot of times when the release engineering team wanted to do something. Oh gosh, what will be an example? Let's say Keychain functionality that was first in the PowerTalk release of the System 7.
We decided we want to do this key chain thing. Forgive me. Keychain may not be the absolute correct example of this. The answer we would get back from product marketing was, "No we're not going to add anymore new features and functionality to the System 7 line. That's all going in the Copland. You need to go back to release engineering and just keep this thing limping along."
I talked to a bunch of friends. Thank goodness, I'm still friendly with a lot of the people who were on that release engineering team. A lot of them still hold the grudge against product marketing, screwed up management, or whatever at that time. Like, "You never let us do the great stuff that we could on system 7 because you wanted it all to go in to Copland, and Copland sucked. Therefore, you're stupid."
To me, it never felt that way. I felt like, "If I was running company and if I was placing my eggs in this new basket over here, I don't want any eggs to go anywhere else." It made sense to me. I didn't really resent product marketing, management, or anybody like that for effectively holding back System 7 to make your next OS release great.
The next OS release is really your future. Why do you want to compromise your future just because you can do something today?
Guy: Right, like not irrational decision making. You can see why you'd make that decision. It may not be in your favor, particularly, but that doesn't make it irrational, crazy, or bullheaded. How was OS 8? That one interests me? I think that started after the NeXT acquisition, the actual OS 8 that shipped.
Initially, they said that they would have Rhapsody out within a year or something, which is why I bought my Mac. That turns out not the case. [laughs] That must have been an interesting product. It was really like, "Now you guys have to go make something fancy," but you know that you're effectively going to be end-of-lifed with Rhapsody coming out pretty soon.
Nitin: Yes, that's interesting. The thing that I remember about OS 8 was there was a lot of work that was put in to take the most viable parts of Copland that had been developed already. Some of them were things like the high-level tool box, some of the Appearance Manager work, and things like that. And bring those back to a System 7 foundation. In some ways, it's an embedded operating system. By today's terms, that's an embedded OS.
Guy: For anybody listening, it's effectively the operating system loads up into BAM and the applications are effectively plug-ins. All of the address space is shared. You can poke at other people's stuff. It's very much a very lightweight operating system but today's...
Nitin: Yes, yes. Exactly.
Guy: Sorry, I just wanted to lay the groundwork by what year.
Nitin: Well, thank you.
Guy: Yeah. Pulling it back from Copeland into the 7 branch to create 8, was that a big hurdle or were the APIs similar enough? Was the underlying structure close that you could do it?
Nitin: It was a big hurdle, mostly in that one of the biggest things that went into Mac OSA was a lot of the native toolbox pieces, like a native control manager, a native window manager. The team at the time was, I believe it was managed by a guy named Ed Voss, who's still today...I had hired him back, we'll get to that, years and years later.
He's still in the iOS org right now, but Ed and his team had a lot of these components that were fully native, rewritten in C, just new implementations of Control Manager, Dialog Manager, Window Manager, all of the traditional UI toolbox managers that were there, but they happened to also plug into this new thing called the Appearance Manager.
Now that I'm talking about it, I'm sure I'm getting some of the details wrong because I think a lot of those things actually ended up in 8.5. Around 8.0 was the...Yes, please forgive me. For anybody who's listening, for me, this feels like a memory test.
Guy: Yeah, yeah, don't worry.
Nitin: I know I'm going to fail horribly.
Guy: Getting details wrong is a part of the charm of this show. Don't worry about it.
Nitin: Awesome. Then I will make it very charming.
Guy: [laughs]
Nitin: Yeah, there are a lot of components that were starting to come in Mac OS 8 that, by the time we got to 8.5, we had a lot of these native libraries. The underpinnings of Mac OS were still the same. We had a VM, and it worked a lot better than it did before system 7.55, but it was still a VM that had to operate on a single address space for all applications.
If you had an app, where you wanted use way more RAM than the user expected you had to bring up GetInfo and you type in a new magic number for how much RAM to use. Considering this thing was a Mac, we thought it was always funny, internally. "Oh my god, here's this thing that we've worked so hard to make user friendly, and now we're making this poor user go in type in 4,096 into a size resource or into the Getinfo panel." Poor users.
Guy: Yeah, and what the Mac called a VM is not what you'd see in a comp sci class. A very, very different beast.
Guy: How long was the 8 project? A year and a bit maybe, 18 months?
Nitin: I think it was over a year. I think it was about 18 months. That was sort of when I got an appreciation for shipping frequently. We didn't talk about iteration or agile, or anything like that. The point of these releases, until we got to 8.0 -- it was a little bit stretched out by then -- was we're trying to address customer issues as fast as we can, and get releases out, get high quality releases out as frequently as we can.
And 8.0 stretched it a little bit, but not as much as 8.5 did later. From what I recall there was definitely awareness of the fact that Copeland was this thing that was done. All of the focus shifted back to release engineering.
That was the deployment vehicle for Mac OS, "Until something better comes along, and we thought it was Copeland, but now we know it's not, so we're going to get all our stuff working on this system 7 foundation, and keep that thing going until we get our shit together on the modern OS side."
Even though there was all that work that was taking place, while we were working on 8.0 and 8.5 it never felt like "Why are we doing this?" It never felt like it was pointless work. We had gotten to a point where the developers that we did have were finally...
With Mac OS 8 there was the new look and feel, and with 8.5 there were a lot of new libraries and implementations. If you have an app that's been working for years and years, and if you happen to get lucky and it works by side effects, in some ways...
Guy: Right.
Nitin: Before 8.0 there was this feeling that we couldn't let any app break. We just could not.
No matter how wonky or strange or whatever this app was -- your Super Boomerangs or the things that like patched out half the [indecipherable 01:16:46.04] , "Oh my god, we have to keep all of this cruft working, otherwise people are going to run Windows."
Guy: Especially with a system as slim as Mac OS was. That really ties your hands. You can't even move the address of like a function of something. The date has to be in a certain place at certain times. It's kind of crazy.
Nitin: Exactly, exactly. It was interesting. I can't really point to any one thing that happened, but somewhere between Mac OS 7.6, and certainly by the time we got to 8.5 -- I even think that it was before 8.0 -- there was this acceptance that "We want to advance the OS, and in order to advance the OS we're going to end up breaking some of these things."
Where in the past it was just like completely forbidden, like "Why would you even consider breaking Super Boomerang?" after a while, we got comfortable with having a little bit more of a vibrant development around the OS.
Being able to push back on a developer and saying, "Hey, you've been getting lucky for years now. Maybe you should fix your crap now or if you really don't want to, then it's on you to say you're not supporting Mac OS 8."
Guy: Was that something that came organically from the team or was that like did Avie come in and "Dictate that no other things are going to break?"
Nitin: That's the thing, I don't ever recall Avie specifically saying that. When we get to Carbon, we can talk a lot more about that. When it came time to update the tool box, and we understood that buttons were going to look different and controls we're going to work different than they had in the past, and maybe we're going to call these definition procs with different things set up at different times.
Where in the past it was on system software to make sure that none of that stuff breaks, things started to loosen up a little bit. It was possible now to go back to a developer and say, "We want to advance the OS. We want to make this thing better.
In the process of doing that, we've noticed that you're doing a couple of things that just aren't going to work well, so please, do something to go fix your app, or your init, or your system extension, or whatever the hell, because we're going to break it, and we're going out."
That was certainly not true early. If there were egregious cases where somebody was just doing something horribly wrong and we were going to break them, then all right, F them, you know? But around 8.0 and 8.5, advancing the OS started to come back to having equal footing with keeping the apps working.
Guy: That's cool. That's interesting, because that's almost a hallmark of modern Apple, not that they aggressively break things, but they're not afraid to deprecate things. They're not afraid to just move on.
Nitin: I think some of it started around there. I'm not sure if that was Steve coming in and saying things. I don't think it was. I think it may have been. Maybe it was product marketing just giving up. Timing-wise I'm thinking a lot of these changes happened around 1996 as far as I can recall. I don't think the acquisition happened until 97, so some of that predated a little bit.
Obviously, it got much stronger later, and the idea of advancing the platform and making that as important as keeping the apps working, obviously, that's something that continues today.
Guy: Yeah, I think that's a real strength of Apple actually. Being on the outside, every now and then you get bitten. But, by and large, I think it's a terrific approach.
Nitin: Yeah, and going back to Copeland, when we're slinging poo from the release, one of the things we would comment on is "How can you possibly let product marketing say that system extensions are supposed to work on Copeland? How can you build a modern operating system and make it so that system extensions will work?
Yes, I understand you can be very clever about this and have a Trap table, detect when people are patching things and come up with this very sophisticated way of extending things and what have you, but is that really viable? Maybe you should just push..."
Guy: It's a horrible engineering solution. Exactly, yeah. Yeah, whatever the marketing people say, that's a horrible engineering solution. What you need is a VM. You need BlueBox basically. That's the only thing that makes any sense for that.
So, 8 and 9 progressed pretty quickly with a lot of cool new features, and those are the classic OS's that I ran, while I was waiting for OS X to ship.
That's basically the time that I came to love Mac OS. When I first started, I was coming from OS II, Windows NT, and that kind of thing. The fact that things that stop as I was dragging the scroll bar up and down upset me. [laughs] But, I came to love it and really appreciate it. When does Carbon start to happen?
Nitin: Carbon started to happen, I think it was late 1997, maybe early 1998, somewhere around there. The NeXT acquisition happened, and the party line was still that, "Hey, we're going to have this thing called Rhapsody. Our modern OS story, it's all AppKit-based." If I can very generally paraphrase what the message was, as far as developers go.
Obviously, there was a huge push-back from your Adobes, your Microsofts, and your Macromedias, all your big companies. Those were really the dark days as well, right?
Guy: It's a hard sell, right?
Nitin: Yeah, it's a really hard sell. There were signs of that Steve Jobs brilliance and things like that. Apple, even after purchasing NeXT, that wasn't a credible story. It was going to be a very, very hard thing to push. As we all know, the developers at that time were looking to, I think the terms were, "Preserve their investment in traditional Mac OS development."
Guy: At the time, I was super-frustrated with that because I was at Propellerhead. I was working the games at the time, but just the idea of a cool new operating system excited me. Thinking about it now, that is a very rational position to take, given the many, many millions of dollars that have been invested in this source code.
Nitin: It's funny. I come at it from the other side. It's maybe even irrational in other ways where, "Yes, we've had this Mac toolbox. We can fix it up a little bit, and we can make this existing Mac toolbox. We don't have to go whole hard like the Copeland guys did and just make everything these overwrought APIs.
Instead, why don't we make some of these window records and dialogue records and graph ports and stuff like that? Why don't we make those opaque and make it so that we have a little bit better idea of what developers are trying to do by having these higher-level APIs?
There were certainly people on the Mac OS 8 and the OS 9 side, who felt like, "We don't need to do any of that. MOC is this horrible, message-passing operating system. Message-passing will never be as fast as a direct function call. Why are we even going down this road? Instead, what we should do is build up the..."
There was the nanokernel. We should give the nanokernel, and they could just fully preemptive thing. Get rid of all this message-passing shit, let's just show people what we can do with putting a modern kernel under Mac OS 9."
Of course, by then, the reality of the company and the way management was making decisions, that was just never going to be a viable thing. It was a last-ditch effort by a bunch of the old guard to keep things going.
Guy: This is when Avie was there?
Nitin: Yes, Avie was there at that time.
Guy: Avie's not going to swap out MOC. Pretty sure that's not going to happen. For the listeners at home, we wrote the microkernel that...probably not good to go against that. Interesting, though.
Nitin: I don't think this was as true on the release engineering side. But, on the Copeland side, there was a distrust, not really believing what the execs or the management were saying.
Guy: I can understand that feeling. From there perspective, the golden team and the project fell apart. You don't really know what's happening right now. I don't think it's necessarily rational, but I can definitely understand why the zeitgeist in that group would feel that way.
Nitin: That's true. You asked about Carbon. It was late '97 or early '98. Finally, there was this effort that was put into place to try to figure out, "What are the APIs?" I forget what the number is. I think 6,000 APIs in the traditional Mac toolbox. Maybe there's 3,000. I don't remember, but there were many, many thousands of APIs.
Of the APIs that were available, if we were to create a Mac tool box implementation on a modern foundation, what are the ones that we want to carry along and what are the ones we want to ditch, and why? Let's gather some data as well, to help support whatever decisions we are making.
It was around that time that there were discussions about creating something that I think would ultimately be called the Carbon Dater, which was if you had a PowerPC-native app, it would look up all of your exported symbols, all of the symbols that you need from the underlying operating system, and figuring out, "If you use..."
For example, a standard file, which was the old-world way of picking documents or saving documents, we just knew that that implementation was just horrible. We already have this new thing called Navigation Services, which was a new-world document picker or document saver.
Guy: It came in mid-8, right?
Nitin: Yes, exactly. That was, by the way, one of the things that was originally slated just for Copeland. Once Copeland sort of collapse, then the effort was, "Hey, we really want to ship this thing. Let's ship it on this. Call it Mac OS 8."
Guy: That's cool because actually, 8 and 9 got a bunch of improvements that you wouldn't have expected, but it's cool they were coming back from Copeland. Anyway, I do know the Carbon talk. You encourage people to get onto nav services, more of the stuff that you'd integrated from what was Copeland back into the OS 8 and OS 9 stream.
What was the impetus for Carbon? Did somebody say, "We really need Carbon on OS X."? Was Carbon originally, from your perspective, sanitizing the old Toolbox stuff?
Nitin: I wasn't in any of these meetings where I specifically heard this, but the feedback that I had heard loud and clear was that companies like Adobe and Microsoft, these big players, were not interested in writing a new version of their app in Objective C. That was just not going to for them.
Even in the past, when there was this thing called Copeland, it sounded like Apple had made all these promises to these companies that, "Yes, your existing binaries are going to continue to work, and we're to make sure that they work really well. You don't have anything to worry about."
As soon as this Rhapsody thing came in, then the story was, "Now, throw out all that old shit, it's time to learn Objective C and get on with it." A lot of these companies were pushing back and saying, "No. We're just not going to have a Mac product. Good luck to you, but we're going to release for OS 8 and 9. We're just not going to have anything for this thing called Rhapsody."
I think a lot of the impetus was just, "Oh, my God. How can we make it so that these big development houses come to this new operating system that's so critical to Apple's future?" I really credit Bertrand Serlet with really pushing the idea. In the past, Apple had really strived for binary compatibility, and we needed to keep these things like Microsoft Word 5.0 limping along on Mac OS 8.0 or things like that.
Bertrand was the, as far as I can tell anyway, one of the people in a position of leadership to push back and say, "We're not striving for binary compatibility anymore. We are now going to strive for source code compatibility.
Whatever we need to do to massage your sources or whatever you need to do, developer, to massage your sources to get onto a modern foundation, you should really see this as a big benefit." At the time, the message that was being thrown around and it sounded a little bit silly later, was if you had a moderately sophisticated app, in two weeks with Carbon, you can have that same app running up on OS X, what would become OS X.
Guy: I remember that slide.
Nitin: [laughs] Now you probably roll your eyes at it like, "Oh, uh-huh, two weeks." [laughs]
Guy: It could happen, but probably not. [laughs] It's a great objective, though. Carbon was actually pretty good, and it wasn't that far away from what was considered modern, classic OS stuff, right? Honestly, in those days, compiling work probably took three days, so two weeks is probably a bit short. In general, I think Carbon was a pretty good stab at bringing people forward. Truth is, it worked, right?
Nitin: Yeah, exactly, it worked. Just like we had started this new dynamic around Mac OS 8 and 8.5, we are now willing to push back on developers. We're willing to say, "No, you need to go and fix your app, too. You need to fix your extension, because the boat is leaving. You're either on the boat or you're off the boat."
We had shifted. It's almost the confidence thing where it's, "Oh, no, we're going to wait as long as we need to make this F'd up version of super boomerang limp along on Mac OS 8.5."
Guy: [laughs] You really hate Super Boomerang. [laughs]
Nitin: I do. I really do. [laughs] Mostly because I know the traps that they patched, all those things.
Guy: The thing is, the boat wasn't leaving. The boat was sinking. When the boat is sinking, it's like, "You don't get to sit in the deck chair anymore. You grab a bucket. Help us make this work." I think it was a good cultural shift.
Nitin: I think that that was one of the other things. Switching from binary compatibility to source was saying that, "Developers, this is not a free ride for you. You need to pony up some effort on your side as well. If you want to get your app working on a modern operating system, and believe me, at Apple, we want you to get that thing working in the worst way, so we're going to do what we can.
Make no mistake, you, developer, are going to have to put in some work." There were people at those early WWDCs who did not like that message. There were people who...
Guy: You can watch the video and hear people be upset.
Nitin: I heard some of that feedback myself in some of those sessions as well. It's hard to fault them. I understand. Now, you've got a third operating system to support. How are you going to factor in how much effort you put into that, compared to what the returns are? It becomes very complicated? Is it really worth it after all? What's this Mac thing going to do in the end? Why should I do any of this?
I really credit Betrand and the management at the time for having the stones to say that, "No. We want you to come along but you're going to have to dig as well. Pick up a shovel, pick up a bucket, let's start bailing this thing out. We're all in this together. If you don't, then hopefully, your competitors will."
Guy: [laughs] Yeah, right. With a bit of luck, you can play one against the other. How long were you in Carbon?
Nitin: I was in Carbon. I think it was...Oh, boy.
Guy: Wait. Was it its own cross-platform group?
Nitin: I was in a funny position. Early on, there was a small of people who would come from Copeland, a couple of really smart people. One of the guys, forgive me for name dropping, but he was my manager for a few years and I have a huge amount of respect for him.
He's a guy named John Hirochi. He had come from the Copeland side. It my understanding, he was part of the due diligence and the deep analysis of NeXT, and whether we wanted to get involved in this thing.
He had a couple of people working with him. There were some people from the QuickTime team, believe it or not. The actual, original basis for Carbon was this thing called QTML, which is the QuickTime Media Library. It was a portable subset of Mac Toolbox.
Guy: I did not know that. Now that you mentioned it. I do remember that, because I've used it in Windows in order to record one of those 3D movies, a series of frames that you can rotate around.
Nitin: Oh, yeah, QuickTime VR.
Guy: QuickTime VR thing. For advertising material for game I was working on. The game, you embedded QTML to basically create the VR. I did not know that Carbon was based around that initially or at least used that as a seed. That's interesting. Makes a lot of sense, but I have never heard that.
Nitin: Around that time, I had a chance to work with a couple of really, really sharp people from the QuickTime team as well. We were taking this QTML thing which had been ported to Windows, to Solaris, believe it or not. [laughs] It had been ported to a couple of other Unixy platforms. I don't think it ever shipped on any of those. What was the SGI one? Irix?
Guy: Yeah. I was just about to guess SGI would be Irix, yeah.
Nitin: It already had support for a Unixy-type system. It was a natural fit to start at least building the prototypes for what would become Carbon. Some of the very earliest prototypes that we built, in fact, to my recollection, the earliest prototype that we had built and demoed to Steve Jobs at the time was ClarisWorks, the entire Works package. This is really dating myself here. [laughs]
Guy: What are you talking about? You're just talking about working on System 7, you're dated. Don't worry about it.
Nitin: [laughs] Now, I'm worried about it with ClarisWorks? That's the one I focus on? [laughs]
Guy: That's a good one, because that's an honest-to-God application suite. It does real work, pretty popular. Had the source code. I don't know if it was spun out of the company by that point but whatever, you could get the code.
Nitin: We had the code. It was a pretty significant body of code, obviously. It was very full-featured. For the demos that we did for Steve, it wasn't something that he could install on Rhapsody with these crazy libraries and get something working. It was certainly demoware.
It was enough to prove the point that you could take a significant body of code, and with some tweaks and some largely mechanical changes through the code, in other words, accessing records to using getters and setters and things like that, you could have something that ran.
Guy: You didn't need to reinterpret the entire project and back. You could tweak a few things here and there. That was successful. That's a good sign for Carbon.
Guy: Did you work with third-party? I don't even know if you can say it. [laughs] Maybe not.
Nitin: I don't now if I can say either, but I'm going to say. [laughs] We work...
Guy: [laughs] It's been long enough.
[laughter]
Nitin: At the time, we had Macromedia in the offices. Oh, boy, it wasn't Director. It was another gigantic offering system. When I hear the name, I'll remember it. Anyway, yes. Macromedia was in there. We had our cobbled together headers that allowed us to successfully build and run ClarisWorks.
That was sort of the early, early basis of Carbon. We had been working with Macromedia to get a port up and running. We wanted to get it ready, and we wanted Macromedia to get up on stage at WWDC and say, "Hey, we did this port, and it took us a little bit of time, but, now it runs here, and it's the same source base that works everywhere."
Unfortunately, it never quite got to that point. One of the biggest things that we ran into, believe it or not, was the case sensitive file system on Rhapsody. It was all UFS-based, Unix File System.
Guy: Oh, yeah, I forgot about that. The first ones were all UFS. Wow. That's funny, that comes back with iOS.
Nitin: Yeah, so that bit us pretty hard, back at that time, just getting the thing ported. We really wanted to tell that story and have a third party tell that story, too. Ultimately, it was OK, because Greg Gilley from Adobe -- he was managing Photoshop or something like that at the time -- was able to get up there. I don't think it was a port of Photoshop that they got up and running. I think it may have been Adobe InDesign.
Guy: InDesign was more modern.
Nitin: Exactly. Adobe was one of the companies that had a very early version. They had InDesign and they were jazzed about this. They liked the story and they weren't pushing back, squawking too hard on, "You're going to have to make changes, but hey, you want to get on it. You want to get on a model class, you've got to pay.
Guy: InDesign, at the time, was the underdog to Quark.
Nitin: Yes!
Guy: I honestly think the OS X effort from Adobe is a large part of why they ended up eating Quark's lunch. Quark was so slow to, for lack of a better word, modernize, to come to OS X.
Nitin: Yeah, exactly. Those were the early, other than ClarisWorks and this Macromedia app that I wish I could remember the name of -- InDesign was one of the other early clients -- that we were able to get up and running, and prove to ourselves that, "Hey, this thing is viable."
Guy: Were you more at the Foundational level? I believe Core Foundation stretches back to Carbon, right? That got backported to the OS 8 and 9 tree.
Nitin: Yeah.
Guy: While Carbon was more like an HIToolbox. Was that maybe a bit later? I'm trying to remember.
Nitin: Certainly when we'd shipped, yeah, HIToolbox was definitely a big part of it. My early involvement with the Carbon team -- with John Hirochi and a couple of other people -- was around taking this giant body of APIs and saying, "Are you in or are you out?" Going through and making the call on these things.
Guy: Being the editor.
Nitin: Right. By then I had had a fair amount of experience adding new features and functionality to Mac OS and understanding, at least to some degree, what developers were using and what their expectations were. What APIs can we get rid of and developers will just shrug it off? Versus what APIs would we get rid of and they're just going to scream and call up their marketing person and tell us what a horrible idea this was?
My early involvement was on evaluating the APIs and then coming up with a plan for building this thing called CarbonLib out of headers. We also added some facilities to the interface generation tool that we had within Apple that allowed you to take this language that almost looked like a header file, but it was really generalized. You could build Assembly files for it, Pascal files, PowerPC, or 68k, and extend that so that it could spit out getters and setters for some of these records that we wanted hidden.
Guy: Right, because that's a huge effort. Just for the audience, it used to be these records...well, you're calling them records because it's Pascal lineage. But these strucs, these structures, used to just have all of their members exposed and you could just read and write to them willy-nilly in the code, which does not work well in terms of moving into the future.
One of the big efforts in Carbon did really seem to be effectively taking a more object-oriented approach, where you'd have functions that would get and set this to guard against people just poking random stuff. I didn't know that was automated. That's interesting.
Nitin: Yeah, that was actually automated. My earliest versions had started as a Perl script, but then worked with...
[laughter]
Nitin: So it was "automated" with air quotes. Then, yes, it got formalized and built into the tools that we used to create those headers. Later, my involvement was more on the OS 8 and the later OS 9 side, building this thing called CarbonLib. I was the lead on CarbonLib for OS 8, just figuring out how this library is supposed to work.
We knew we wanted to get rid of these things called definition procs or def procs. Within the Mac toolbox, if you wanted a menu that looked different from the traditional Macintosh menus, you had to create a definition proc that said, "No, the rectangle really is this big. Instead of just drawing text in Chicago 12 this way, draw a little grid of colors that a user could choose from," things like that.
Guy: I never really looked into it that much. Is it a callback system?
Nitin: Effectively, that's what we turned it into. Yes, you're right. It was a callback system but really it was code that was embedded in its own resource that would get these different messages for "Highlight item one," or "Draw the title bar or "Draw the selected title bar." Effectively it was.
Guy: Based on the message it would get, and by message you mean an int. You'd get, "This is the action that was happening," and then it would do something to the graph that it was responsible for.
Nitin: Exactly. The way that had traditionally been done on the Mac was, in modern terms, you had to have your own sub-project or target that built a little resource of code that the system then loaded and used to handle the definition of the look and feel of this thing.
For Carbon, we didn't want that anymore. We didn't want people to write code resources. We wanted it all in a single binary executable. What we did is effectively create a callback system, where we just had a generic code resource, a generic def proc, that ran on Mac OS 8 that would just bind to the application's shared library and call the routines directly from there.
If you're writing an application, you just implement these callbacks. It was just a much nicer system, even.
Guy: Yeah, it's way nicer.
Nitin: It was trying to marry the two worlds and make it so that if you did all this work to modernize your application code base, we wanted to make it so that it worked well on OS 8 or OS 9 as well, as part of preserving your investment in this code base and keeping your apps working through the releases as we make this giant transition.
Guy: Like at DTS, this must have been a huge learning experience. Not only do you need to know all the internals of the classic OS, which you'd been working on, but you needed to quickly learn a lot about what I believe at the time you were still calling Rhapsody. How did that feel? Was that like jumping into the deep end a little bit -- a brand-new operating system?
Nitin: Oh, God, yeah. [laughs] But it was fun too. Yeah, you're right. It was an awful lot like being in DTS, where you're being paid to learn. How many chances do you get in your life to be paid to learn?
As an engineer, you get paid to learn every day, if you have the right attitude about it. Really, whatever your attitude is, you have to learn how the existing system works and how to make something new that works well on the new system.
It was a little bit of going off the deep end. Because I went to Santa Cruz and a lot of the computer systems there were UNIX-based, I had some experience with it, obviously not a huge amount. We didn't have NeXT stations or NeXT cubes at UC Santa Cruz.
Guy: I don't even think they existed by that point.
Nitin: Yeah. They were there. I remember seeing them here and there. Late in college anyway, I remember seeing one.
Guy: What happened with Carbon? Eventually you transitioned out of that group, a very successful project. We would not have the Mac today without Carbon. As a guy that's basically an app-kit, open-step guy, or that's at least my vector into the platform, there's no denying that Carbon is really what made it into a viable platform for the long term. Good job.
Nitin: [laughs] Thank you.
Guy: Problem solved. What happens next?
Nitin: Thank you. Thank you for saying that. I agree. It was critical at that time. You can look at it technically and say, "All you did was hide some symbols and expose some new symbols and covers for some of these APIs," but, yes, I believe it was critical. History has borne that out.
Guy: At the time, I would probably have been one of those people that was holding their nose up about it like, "It's a Carbon app." The truth is, yeah, it's a Carbon app and it's Photoshop. Guess who uses Photoshop. A lot of people use Photoshop, or Word or what have you, or the Finder, iTunes.
Nitin: There was definitely...
Guy: It's a big deal.
Nitin: Yes, I agree. I wish that it was a little bit more integrated into the system sooner than it was, or felt like it was integrated. In other words, when you launched Internet Explorer, which was the browser at the time for the Mac, on Mac OS X, you knew you were in a Carbon app.
The text rendered a little bit different. It was pretty ugly compared to Cocoa. If you were using Office, it took a little longer to launch. Actually, maybe it didn't, but when it came up, you definitely felt like it was something different than the rest of the system.
Guy: It took years to get services working in them. There was a bunch of stuff that was like, "This is clearly a Carbon app." On the other hand, dang it, these are murky apps. If you didn't have them on your system, it would be the Amiga running on a PowerPC. It's pointless.
Nitin: Definitely. On the Carbon team, we really held on to that. We used that to keep us going, too. Even at the time, it wasn't like Carbon was held up as, "Angels sing when you see a Carbon app."
Guy: No, it was always a necessary evil, which is a downer to be on.
Nitin: Exactly.
Guy: [indecipherable 01:57:28.02]
Nitin: You don't want to work on something that everybody just begrudgingly accepts that, "Yeah, it has to be here, because things would be so much worse without it." Who wants to work on that? You want to work on, "Oh, my god. This thing is fantastic."
Guy: It's funny. I'm just realizing that you were on the 7 team, which was the necessary evil team. Then you did Carbon. You're an under appreciated fellow is what I'm saying.
Nitin: [laughs] Yeah. Thankfully, I never really felt that way for me, but who knows what I'd be doing?
Eventually, yes, I did transition over from the lead on CarbonLib for OS 8 to working in the Carbon team, working for John Hirochi who reported to Scott Forstall directly. That was long before OS X shipped. I think I made that transition in 1999, when I first started working for John full time. I was working on the core services components of Carbon, in particular the File Manager.
File Manager, Resource Manager, those low level bits, some Process Manager in there, things like that. Some of the challenges there were that we wanted to have this single, unified API. At that time, Avie Tevanian was the VP of Mac OS development. He was a very strong believer in heterogeneous systems, and fitting into existing networks of computers and things like that.
Guy: Hence, the insistence of file extensions and a bunch of other things.
Nitin: Exactly. Getting rid of resource forks. Resource forks were seen as this weirdo Mac thing that no other file system had. Later, Windows added it to NTFS. They had multiple streams. Even then it was a bizarre thing.
Guy: It was two-headed. Invariably when you try to zip something up, forget it. Everything would break anyway on all of these systems.
Nitin: Right. [laughs]
Guy: It's a nice idea. It's a really nice idea, but keeping things simple is a noble goal, too.
