Windows Cairo is the second generation of Windows NT…the first Microsoft operating system that realizes the “Information at Your Fingertips” vision. –Windows Cairo product planning document
Reading about Cairo is triggering Longhorn PTSD in me. Finally having some understanding of Cairo means I am now even more astonished at the mistakes made during Longhorn.
It’s interesting to learn that Cairo was a wholly distinct operating system from NT. Not being at MSFT at the time, it seemed from the outside (reading trade press) that Cairo was the next version of NT. If it was a third OS group as you write here, was it building from scratch (kernel, etc)?
Cairo was a distinct OS project. It was derived from and relied on NT, but that was a source of much consternation -- eg how much of Cairo was only in user mode v kernel mode and the like. It was supposed to be NT4 but how that would play out was going to be unclear as NT itself was still going forward full throttle.
"the realization that the existing code could be made to work fine and new code brought with it new problems."
This anecdote from Word 1.0 (as well as the words "modern, robust, refined") seems to be yet another instance of a story I've seen played out many times. It sounds like Cairo had this to some extent too. This is not to say that such efforts can't pay off, but I've always wondered why such efforts get the attention and resourcing they do, given the high risk of new issues and overall low historical success (at least from what I've seen).
Do you have any thoughts about how to take a more critical look at such initiatives and how to decide whether such things are worth it or not? It seems that too often, predictable issues with this approach are ignored for too long, leading to frustration and demoralization that seem mostly avoidable. OTOH it's also hard to not assume good intent at the time and realize what was misguided in hindsight.
Bill thought of the company as a portfolio. So some initiatives would necessarily not succeed. I would say in hindsight, and this is not too much of a surprise, he underestimated the human costs of a portfolio. People working don't have the ability to just block off the influence (positive or negative) from projects in the same space. People tend to want to know they "own" something. It is easy to judge that things should not have existed in hindsight, but then again Windows itself was one of those projects just a few years earlier--one that really annoyed the OS/2 team :-)
Thanks! It's an odd thought experiment to look at Windows as one of those projects, but it makes sense!
The "human costs" you mention are on my mind a lot. While innovation and shipping aren't mutually exclusive, I do find that sometimes projects tend to focus on one or the other for too long, and I personally find it difficult to balance the two and shift that mindset when necessary. It also tends to be difficult to convince the innovator that it's time to nail down the spec and work towards shipping, and to convince the shipper that further innovation may be needed to release something more compelling.
I'm curious about something that took place during your TA time with BillG, i.e., "during late-1992 to mid-1994." I'd love to hear what your involvement, if any, was around the following.
I was running product development at Stac at the time, shipping the Stacker disk compression product. We sued Microsoft in early 1993 for infringement of two of our lossless data compression patents over Microsoft's DoubleSpace disk compression feature in MS-DOS 6. The case went to trial in early 1994. We prevailed in our case, while Microsoft countersued us for trade secret misappropriation and also prevailed. No doubt that we were a nuisance to MS for this as we had been granted a pretty broad injunction that prevented OEMs from shipping any product that included DoubleSpace. We ultimately entered into a settlement agreement with Microsoft in mid-1994. It seemed to be at the early stages of Microsoft's patent awareness (as you noted in an earlier chapter).
It's ancient history at this point, but I'd love to hear your thoughts on this.
Thanks for these excellent chapters. I'm recalling devouring the trade press of those days.
The suit took place during my time in the office. It was a pretty straight forward patent case from a technical perspective and the people on the team were experts so I had little to offer. By and large this was rear view mirror since it was MS-DOS and most were convinced the era of drive compression was coming to an end.
Reading about Cairo is triggering Longhorn PTSD in me. Finally having some understanding of Cairo means I am now even more astonished at the mistakes made during Longhorn.
Cairo can be a whole book by itself and a most fascinating one if it covers not just the technical topics but also human ones.
For sure. I think we can agree that there are a few projects that could be books on their own. Maybe this will spur someone to do that!
It’s interesting to learn that Cairo was a wholly distinct operating system from NT. Not being at MSFT at the time, it seemed from the outside (reading trade press) that Cairo was the next version of NT. If it was a third OS group as you write here, was it building from scratch (kernel, etc)?
Cairo was a distinct OS project. It was derived from and relied on NT, but that was a source of much consternation -- eg how much of Cairo was only in user mode v kernel mode and the like. It was supposed to be NT4 but how that would play out was going to be unclear as NT itself was still going forward full throttle.
"the realization that the existing code could be made to work fine and new code brought with it new problems."
This anecdote from Word 1.0 (as well as the words "modern, robust, refined") seems to be yet another instance of a story I've seen played out many times. It sounds like Cairo had this to some extent too. This is not to say that such efforts can't pay off, but I've always wondered why such efforts get the attention and resourcing they do, given the high risk of new issues and overall low historical success (at least from what I've seen).
Do you have any thoughts about how to take a more critical look at such initiatives and how to decide whether such things are worth it or not? It seems that too often, predictable issues with this approach are ignored for too long, leading to frustration and demoralization that seem mostly avoidable. OTOH it's also hard to not assume good intent at the time and realize what was misguided in hindsight.
Bill thought of the company as a portfolio. So some initiatives would necessarily not succeed. I would say in hindsight, and this is not too much of a surprise, he underestimated the human costs of a portfolio. People working don't have the ability to just block off the influence (positive or negative) from projects in the same space. People tend to want to know they "own" something. It is easy to judge that things should not have existed in hindsight, but then again Windows itself was one of those projects just a few years earlier--one that really annoyed the OS/2 team :-)
Thanks! It's an odd thought experiment to look at Windows as one of those projects, but it makes sense!
The "human costs" you mention are on my mind a lot. While innovation and shipping aren't mutually exclusive, I do find that sometimes projects tend to focus on one or the other for too long, and I personally find it difficult to balance the two and shift that mindset when necessary. It also tends to be difficult to convince the innovator that it's time to nail down the spec and work towards shipping, and to convince the shipper that further innovation may be needed to release something more compelling.
I'm curious about something that took place during your TA time with BillG, i.e., "during late-1992 to mid-1994." I'd love to hear what your involvement, if any, was around the following.
I was running product development at Stac at the time, shipping the Stacker disk compression product. We sued Microsoft in early 1993 for infringement of two of our lossless data compression patents over Microsoft's DoubleSpace disk compression feature in MS-DOS 6. The case went to trial in early 1994. We prevailed in our case, while Microsoft countersued us for trade secret misappropriation and also prevailed. No doubt that we were a nuisance to MS for this as we had been granted a pretty broad injunction that prevented OEMs from shipping any product that included DoubleSpace. We ultimately entered into a settlement agreement with Microsoft in mid-1994. It seemed to be at the early stages of Microsoft's patent awareness (as you noted in an earlier chapter).
It's ancient history at this point, but I'd love to hear your thoughts on this.
Thanks for these excellent chapters. I'm recalling devouring the trade press of those days.
Thank you for the kind words.
The suit took place during my time in the office. It was a pretty straight forward patent case from a technical perspective and the people on the team were experts so I had little to offer. By and large this was rear view mirror since it was MS-DOS and most were convinced the era of drive compression was coming to an end.