I recall the release of Excel that installed enough of the not-yet-released Windows to run as a GUI app.
Later I would be at an event in New York City where Microsoft and IBM personnel attempted to explain why there would still be Windows (at 2.03 or maybe 2.10) at a client level and that OS/2 would provide a higher-level arrangement.
In July 1992 I was in Palo Alto doing some house-hunting as I prepared to transfer to XSoft (situated adjacent to PARC). Since I was in town, I went up to San Francisco for a Microsoft event in the Moscone Center. It was the reveal of Windows/NT and that was going to be that.
I got to meet Dave Cutler at that event and he reminisced about his love for the Univac 110x at Dupont, before moving on to DEC in his career. The key take-away from conversations around Dave as a system architect concerned choosing the invariants to control and what others to leave loosely observed. It was no surprise to learn, years later, about Dave taking charge of the integration and shaming NT build-breakers.
By then the World was on Wiindows 3.10 and 95 was still to come.
Before I came to Silicon Valley in 1992 I was in a self-designated skunk works project to build a multifunction digital scanner/copier/printer with a PC as the processing unit. It was a pilot effort and some units would end up in Hallmark shops for producing customized greeting cards. We were using beta releases of Windows 3 and also fussing with co-processor boards to cope with the scanner. When the Windows 3 launch happened and swamped the computer stores the WTF moment was, "Wait, why had we not bought Microsoft stock?"
There were a lot of bad bets. It seemed that Lotus had concluded to do 1-2-3 on OS/2 first, probably well-incentivized, but it left Excel in an unassailable position.
At Xerox, the introduction of the Apple Lisa was taken as validating their march to commercialize GUI-based workstations. There was an effort to make developer-oriented releases of the workstation and provide the developer tools (i.e., the Mesa language compiler and other tools). It was expensive, and the sales folk saw it as an opportunity to sell laser printers, also not cheap. The product required a network (XNS protocols at that point). I doubt they sold any.
At PARC there was much Apple envy, and I think they wanted to be Apple. Microsoft was viewed with disdain. Xerox had introduced some consumer level computers, starting with a CP/M-80 all-in-one based on the same motherboard as the Kaypro. When the PC hit, an Olivetti clone (also adopted by AT&T) was marketed. There were even short-lived Xerox stores. At one point, Xerox even did an employee buy-back effort to get more of those discontinued units for use in the business. The roll-out of Xerox workstations had not happened yet.
There was great confusion in Palo Alto on how Xerox was fumbling the future as it was viewed from there. Fundamentally, there was not going to be such a pivot for an $18 billion manufacturing company built around a direct sales and leasing business.
More fundamentally, there was a problem about the perfect killing off the good. As may be typical of companies that exploded around a killer product (the original Xerox hallway copier), there was an intense craving to be the next trick. Xerox had quality erections around laser imaging, fonts, digital formats (not Postscript) and production printing. Meanwhile, Hewlett-Packard, with its Canon engine, not only captured the commodity laser-printer market, it also determined what people would see as good printing. In that context, Xerox write-white technology, adapted from optical copiers, suddenly didn't look right, no matter what the test-print quality metric was. The more-telling case was with inkjet though. HP inkjet technology was considered not good enough and Xerox engineers wanted to kill it with quality. Timing is everything in more than comedy.
It was also a problem for Xerox that it manufactured its own processors and chips. The processors were important for embedded digital processing in copiers and multifunction units, but they could not get to commodity scale and it impacted all products. Engineers preferred Motorola and PCI boards and did not chase Intel. Still, big products depended on the company's own foundry.
And so the fate of OS/2 was sealed, the prickly partnership of two industry giants was doomed, priorities of thousands of app developers were reset, and the direction of an entire industry was changed because of the initiative of one hugely talented programmer. It took years for the implications to fully play out, but it was cataclysmic.
It reminds me very much of the story of how Mac OS was ported to Intel processors. Also basically the work of one programmer as a stealth project.
This section is just wonderful and brings back lots of memories, so weird that we were padding around the same buildings and we never met. Doug Klunder was just my everything at Microsoft, he and Jabe Blumenthal and I did so many things together. Doug was brilliant and also the kindest. sweetest, funniest person you would ever meet. When Jabe designed Excel 1.0 and Doug wrote (most) of Excel 1.0 and I introduced Excel 1.0, well, that was one of the two most fun years I've ever experienced in my career (the other was conceiving of and launching what became ESPN.com in 1995). The Windows/OS/2 conundrum was just a classic case of shit happening when good people work hard, kind of the opposite of IBM which was filled with mediocre people not working very hard. Great to hear from Jon DeVaan, he had the world's most epic Star Trek calendar in his humble office when I first met him in 1984.
The Hungarian naming convention sounds crazy, and the Systems group at Microsoft was never fully convinced of its benefit, but the benefit was real. The reason? Start with DougK’s maxims of debugging data not code and writing self-documenting code.
At its base, program code contains instructions that transform the program data. The code has no meaning without its data. So it makes perfect sense to make the data structures a primary element of the symbolic names used in the code. This allows any human code reader to see what data transformations are happening in every line of code. The benefit is many common programming errors are immediately visible.
Compiler theory was way ahead of reality in these early days. Modern programmers take type checking in structured languages for granted. But due to RAM limitations, the early compilers did not actually do type checking. Hungarian reduced mismatched type errors to nearly zero. Eventually there was proof.
Later compilers did type checking, but many teams working on old code bases never turned it on because it created a huge backlog of work. Teams that used Hungarian found turning on type checking relatively easy. Much later, when Microsoft Research was developing its first static analysis code review tools, the rigorously Hungarian code bases had many fewer type based errors than the others.
P-Code was a very important technology for Microsoft's early apps. Cross platform was one reason, as Steven writes. It was also very important for reducing the memory size of code. When I started, we were writing apps for 128k (K, not m or g) RAM Macs. There were not hard drives, only 400k floppy disks. (Did I mention we all had to live in a lake?)
P-Code was much smaller than native code so it saved RAM and disk space. Most Macs had only one floppy disk drive. A market risk for shipping Excel was requiring 512k Macs with two disk drives which allowed for the OS and Excel code to live on the first drive and user's data on the second. Mac OS did not have code swapping functions, each app had to roll its own from memory manager routines, so the P-Code interpreter provided that function as well.
On early Windows versions of Excel the memory savings aspect was extremely important. The size of programs grew as fast as typical RAM and hard disk sizes for many years so saving code size was a primary concern. Eventually Moore's Law won and compilers improved to where the execution trade-off was no longer worth it. When Windows 95 introduced 32 bit code these code size dynamics returned for a different reason – IO bandwidth. 16 bit Excel with P-Code outperformed 32 bit Excel in native code in any scenario where code swapping was needed. Waiting for the hard drive took longer than the ~7x execution overhead of the P-Code interpreter.
Hi Steven...you spoke about this at length on the ClubHouse Good Time show last week, but just wanted to call out that your decision to publish Hardcore Software by the chapter on Substack makes for a much superior reader experience.
To have your fellow-shapers of the early PC revolution (and one of the subjects of this chapter) like Jon DeVaan provide context and perspective, greatly enriches your already-impressive body of work in a manner that just wouldn’t have been possible if this had been published as a book.
Thank you once again - can’t wait for the next story in this incredible journey of yours!
Speaking of - having a Hardcore Software Clubhouse room where the subjects of your stories join you and share their experiences would be super awesome :)
I am glad you spend a lot of time on DougK. There may never have been a person as good at writing code as Doug. His singular talent at packing data structures and the code to manipulate them was legendary. This led to a funny prank at one point. Doug was so insistent on minimal commenting and his coding "tricks" to save memory, his code was often unreadable to many. This led to someone writing a utility that "Klunderized" source code by removing all white space. Here is another funny story about Doug that relates to my first day at Microsoft. You say he looked like a Doobie Brother. Well, in 1984 he had much longer hair and beard. On my first day, there was no office ready for me, but Doug was taking vacation, so I was assigned to work in his office for a few days. It was as spartan as you describe, except for a nearly completed pyramid of grapefruit juice cans in one corner. Late in the afternoon I am typing away at the z19 terminal when a person who appears to be Jesus Christ walks into the room, opens the large desk drawer next to me. Inside the drawer are two unopened packs of grapefruit juice. Doug tells me that I may NOT drink any of his grapefruit juice, and walks out. It was quite a first day.
There is so much in this section, but the number one take away has to be the immense historical chance involved in Windows being successful. Literally two people, banking on a prior relationship, with DavidW working in his spare time, or perhaps also ignoring his day job completely. Let's be clear, that work was not on strategy, it was not sanctioned by management, and yet it changed the trajectory of Microsoft and the entire PC Revolution (as you call it).
I love the stories Steven! Now, let’s nerd out a bit: “GC would eventually become standard practice on the web and on Apple’s iPhone” The Objective-C implementation for Cocoa Touch pretty famously, maybe infamously, required manual memory management. It was a life of retain and release until ARC arrived. John Siracusa covers it well here: https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/10/#arc
This is fascinating to read Steven. Many of these names are familiar to me on and off but seeing it all together, and the inner machinations etc. is so good. Paul Allen’s Idea Man book (the first half) was like this only less in the weeds details (I’m all for details!!). Really enjoyed this.
I recall the release of Excel that installed enough of the not-yet-released Windows to run as a GUI app.
Later I would be at an event in New York City where Microsoft and IBM personnel attempted to explain why there would still be Windows (at 2.03 or maybe 2.10) at a client level and that OS/2 would provide a higher-level arrangement.
In July 1992 I was in Palo Alto doing some house-hunting as I prepared to transfer to XSoft (situated adjacent to PARC). Since I was in town, I went up to San Francisco for a Microsoft event in the Moscone Center. It was the reveal of Windows/NT and that was going to be that.
I got to meet Dave Cutler at that event and he reminisced about his love for the Univac 110x at Dupont, before moving on to DEC in his career. The key take-away from conversations around Dave as a system architect concerned choosing the invariants to control and what others to leave loosely observed. It was no surprise to learn, years later, about Dave taking charge of the integration and shaming NT build-breakers.
By then the World was on Wiindows 3.10 and 95 was still to come.
Before I came to Silicon Valley in 1992 I was in a self-designated skunk works project to build a multifunction digital scanner/copier/printer with a PC as the processing unit. It was a pilot effort and some units would end up in Hallmark shops for producing customized greeting cards. We were using beta releases of Windows 3 and also fussing with co-processor boards to cope with the scanner. When the Windows 3 launch happened and swamped the computer stores the WTF moment was, "Wait, why had we not bought Microsoft stock?"
There were a lot of bad bets. It seemed that Lotus had concluded to do 1-2-3 on OS/2 first, probably well-incentivized, but it left Excel in an unassailable position.
At Xerox, the introduction of the Apple Lisa was taken as validating their march to commercialize GUI-based workstations. There was an effort to make developer-oriented releases of the workstation and provide the developer tools (i.e., the Mesa language compiler and other tools). It was expensive, and the sales folk saw it as an opportunity to sell laser printers, also not cheap. The product required a network (XNS protocols at that point). I doubt they sold any.
At PARC there was much Apple envy, and I think they wanted to be Apple. Microsoft was viewed with disdain. Xerox had introduced some consumer level computers, starting with a CP/M-80 all-in-one based on the same motherboard as the Kaypro. When the PC hit, an Olivetti clone (also adopted by AT&T) was marketed. There were even short-lived Xerox stores. At one point, Xerox even did an employee buy-back effort to get more of those discontinued units for use in the business. The roll-out of Xerox workstations had not happened yet.
There was great confusion in Palo Alto on how Xerox was fumbling the future as it was viewed from there. Fundamentally, there was not going to be such a pivot for an $18 billion manufacturing company built around a direct sales and leasing business.
More fundamentally, there was a problem about the perfect killing off the good. As may be typical of companies that exploded around a killer product (the original Xerox hallway copier), there was an intense craving to be the next trick. Xerox had quality erections around laser imaging, fonts, digital formats (not Postscript) and production printing. Meanwhile, Hewlett-Packard, with its Canon engine, not only captured the commodity laser-printer market, it also determined what people would see as good printing. In that context, Xerox write-white technology, adapted from optical copiers, suddenly didn't look right, no matter what the test-print quality metric was. The more-telling case was with inkjet though. HP inkjet technology was considered not good enough and Xerox engineers wanted to kill it with quality. Timing is everything in more than comedy.
It was also a problem for Xerox that it manufactured its own processors and chips. The processors were important for embedded digital processing in copiers and multifunction units, but they could not get to commodity scale and it impacted all products. Engineers preferred Motorola and PCI boards and did not chase Intel. Still, big products depended on the company's own foundry.
And so the fate of OS/2 was sealed, the prickly partnership of two industry giants was doomed, priorities of thousands of app developers were reset, and the direction of an entire industry was changed because of the initiative of one hugely talented programmer. It took years for the implications to fully play out, but it was cataclysmic.
It reminds me very much of the story of how Mac OS was ported to Intel processors. Also basically the work of one programmer as a stealth project.
https://www.macrumors.com/2012/06/10/a-bit-of-history-behind-the-mac-os-x-on-intel-project-marklar/
This section is just wonderful and brings back lots of memories, so weird that we were padding around the same buildings and we never met. Doug Klunder was just my everything at Microsoft, he and Jabe Blumenthal and I did so many things together. Doug was brilliant and also the kindest. sweetest, funniest person you would ever meet. When Jabe designed Excel 1.0 and Doug wrote (most) of Excel 1.0 and I introduced Excel 1.0, well, that was one of the two most fun years I've ever experienced in my career (the other was conceiving of and launching what became ESPN.com in 1995). The Windows/OS/2 conundrum was just a classic case of shit happening when good people work hard, kind of the opposite of IBM which was filled with mediocre people not working very hard. Great to hear from Jon DeVaan, he had the world's most epic Star Trek calendar in his humble office when I first met him in 1984.
The Hungarian naming convention sounds crazy, and the Systems group at Microsoft was never fully convinced of its benefit, but the benefit was real. The reason? Start with DougK’s maxims of debugging data not code and writing self-documenting code.
At its base, program code contains instructions that transform the program data. The code has no meaning without its data. So it makes perfect sense to make the data structures a primary element of the symbolic names used in the code. This allows any human code reader to see what data transformations are happening in every line of code. The benefit is many common programming errors are immediately visible.
Compiler theory was way ahead of reality in these early days. Modern programmers take type checking in structured languages for granted. But due to RAM limitations, the early compilers did not actually do type checking. Hungarian reduced mismatched type errors to nearly zero. Eventually there was proof.
Later compilers did type checking, but many teams working on old code bases never turned it on because it created a huge backlog of work. Teams that used Hungarian found turning on type checking relatively easy. Much later, when Microsoft Research was developing its first static analysis code review tools, the rigorously Hungarian code bases had many fewer type based errors than the others.
P-Code was a very important technology for Microsoft's early apps. Cross platform was one reason, as Steven writes. It was also very important for reducing the memory size of code. When I started, we were writing apps for 128k (K, not m or g) RAM Macs. There were not hard drives, only 400k floppy disks. (Did I mention we all had to live in a lake?)
P-Code was much smaller than native code so it saved RAM and disk space. Most Macs had only one floppy disk drive. A market risk for shipping Excel was requiring 512k Macs with two disk drives which allowed for the OS and Excel code to live on the first drive and user's data on the second. Mac OS did not have code swapping functions, each app had to roll its own from memory manager routines, so the P-Code interpreter provided that function as well.
On early Windows versions of Excel the memory savings aspect was extremely important. The size of programs grew as fast as typical RAM and hard disk sizes for many years so saving code size was a primary concern. Eventually Moore's Law won and compilers improved to where the execution trade-off was no longer worth it. When Windows 95 introduced 32 bit code these code size dynamics returned for a different reason – IO bandwidth. 16 bit Excel with P-Code outperformed 32 bit Excel in native code in any scenario where code swapping was needed. Waiting for the hard drive took longer than the ~7x execution overhead of the P-Code interpreter.
Hi Steven...you spoke about this at length on the ClubHouse Good Time show last week, but just wanted to call out that your decision to publish Hardcore Software by the chapter on Substack makes for a much superior reader experience.
To have your fellow-shapers of the early PC revolution (and one of the subjects of this chapter) like Jon DeVaan provide context and perspective, greatly enriches your already-impressive body of work in a manner that just wouldn’t have been possible if this had been published as a book.
Thank you once again - can’t wait for the next story in this incredible journey of yours!
Speaking of - having a Hardcore Software Clubhouse room where the subjects of your stories join you and share their experiences would be super awesome :)
I am glad you spend a lot of time on DougK. There may never have been a person as good at writing code as Doug. His singular talent at packing data structures and the code to manipulate them was legendary. This led to a funny prank at one point. Doug was so insistent on minimal commenting and his coding "tricks" to save memory, his code was often unreadable to many. This led to someone writing a utility that "Klunderized" source code by removing all white space. Here is another funny story about Doug that relates to my first day at Microsoft. You say he looked like a Doobie Brother. Well, in 1984 he had much longer hair and beard. On my first day, there was no office ready for me, but Doug was taking vacation, so I was assigned to work in his office for a few days. It was as spartan as you describe, except for a nearly completed pyramid of grapefruit juice cans in one corner. Late in the afternoon I am typing away at the z19 terminal when a person who appears to be Jesus Christ walks into the room, opens the large desk drawer next to me. Inside the drawer are two unopened packs of grapefruit juice. Doug tells me that I may NOT drink any of his grapefruit juice, and walks out. It was quite a first day.
There is so much in this section, but the number one take away has to be the immense historical chance involved in Windows being successful. Literally two people, banking on a prior relationship, with DavidW working in his spare time, or perhaps also ignoring his day job completely. Let's be clear, that work was not on strategy, it was not sanctioned by management, and yet it changed the trajectory of Microsoft and the entire PC Revolution (as you call it).
I love the stories Steven! Now, let’s nerd out a bit: “GC would eventually become standard practice on the web and on Apple’s iPhone” The Objective-C implementation for Cocoa Touch pretty famously, maybe infamously, required manual memory management. It was a life of retain and release until ARC arrived. John Siracusa covers it well here: https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/10/#arc
This is fascinating to read Steven. Many of these names are familiar to me on and off but seeing it all together, and the inner machinations etc. is so good. Paul Allen’s Idea Man book (the first half) was like this only less in the weeds details (I’m all for details!!). Really enjoyed this.