Vista vs. Cairo - A Microsoft History Lesson

avocade writes "Here is a nice history lesson by (the unfortunately infamous) Daniel Eran, arguing why the Longhorn/Vista road is very similar to the NT/Cairo road that Microsoft took in the 90's, effectively trying their best to discourage competition in the marketplace."

Comments

Cairo vs NT/Cairo

[DreadSpoon]

This article has a confusing title, given that dominance of the Cairo graphics library these days.

Infamous indeed - spammer

[mccalli]

Daniel Eran has been spamming uk.comp.sys.mac for weeks now, ignoring every polite request for him to stop. He shows no sign of engaging with the group (beyond calling us "a hateful bunch of queens"), just spams links to his blog against charter and then swans off again.

Daniel Eran. Just Say No.

Cheers,
Ian

Better Windows history here...

[Aphrika]

Wikipedia - generally a little more authoritative than a (rather opinionated and flawed) blog entry.

Incidentally, I distinctly remember Cairo not being vaporware or a hoax as stated in the article, there were certainly dodgy builds of it floating around before it was canned and NT 4.0 appeared as a Win95-ified NT 3.51 replacement. The idea that Cairo was a hoax in a non-starter. That's like saying Copland was a hoax, no, sometimes projects get shelved because they're not working out - OS design is an area of computing where it's incredibly easy to be idealogical about features, then figure out that you just can't deliver the goods.

Re:Better Windows history here...

[SmurfButcher Bob]

Actually, I'd suggest that you missed the author's point, entirely. Perhaps it is due to you not being in the position to buy the various products at the time, I don't know.

Here's the perspective. It has zero to do with "15 years later, we have a feature". It has *everything* to do with, "15 years ago, when we needed a solution, Microsoft said they would provide it in a TIMELY fashion." As a result, purchase decisions were directly impacted.

We needed a mutlitasking OS to replace a DG Mini. Windows 1.0 was reputed to provide this functionality.
We called them. "Multi tasking?" "Yes." "Multiple users?" "Absolutely."
We bought it.
They lied.
We called them back.
"The sales engineer was confused with the next version." End Quote.

The project was shelved.
CDOS, released by a company named "Digital Research", became viable.
The project was rehashed, but Windows 2.0 was out. It's DOS support had few caveats, compared to CDOS.
We called Microsoft.
"Multitasking?"
"Yep!"
"You said the other one was. It wasn't."
"We've totally rewritten it. It works for real."
"Multi user?"

We bought it.
They lied.
We called them back.
"It doesn't work."
"No? The NEXT one will, and it's due soon."

See the pattern yet?
We eventually bought CDOS (and later, CCDOS, a value-add version).

We also bought Win30. Hazard a guess why?
They lied, again.
We also bought Win31. THAT one was initially stated to be preemptive, remember? And the sales pigs all claimed it was, when it was time to sign the check. Perhaps you've forgotten the RAGING DEBATES over that very issue, at the time... "Preemptive!" "No, it isn't!" "Yes, it is!" "No, it isn't!"

Our project was fairly simple - run a couple of DOS boxes, and redirect STDIO to a serial port so that two people could run a program. This specific detail was explained to "Microsoft", EACH TIME.

Every time... EVERY time... the MS tactic was to stall our purchase of a competing, fully viable product, via the gross misrepresentation of their own.

The MS philosophy is, and has been, that it is better to ship an "empty box" on-time than to ship a working product a day late.
And they have done so, and I have the disks to prove it - Excel's initial "DMF" floppy distribution, who's lzexpand didn't comprehend DMF... they literally put the "standard" Win31 lzex onto disk 1. Funny, it's LZEx that needs to READ these FATless disks. It couldn't POSSIBLY work. But, the version they needed wasn't read yet, so... ship it! ...To NT BO4.5, which contained such setup.ini script error gems such as "Syntax error line xxx: ***REMEMBER TO FINISH SQL INSTALL SCRIPT". I'm NOT joking. And, you don't know the half of the extent of this.

Clearly, two "top tier" products at the time, and the installations not even been tested. Not once. NOT ONCE. And, the devs KNEW the crap wasn't finished. The Mgt KNEW the crap wasn't finished. Both cases, which were a year apart... the "official" MS reason for issuing new disks to me?

"Media Defect". Again, I am NOT joking. Both cases, no matter how hard I argued, the call takers flat out REFUSED to admit the actual flaw. "No, the media is perfect. The setups are WRONG. Syntax errors... referencing a directory path that doesn't exist on the CD... trivial little things like that..."

Because, you know, the standalone install disk for Exchange had the base directory in the root. On BO4.5, the base setup was a subdirectory. And the scripts hadn't been adapted for it.

Trivial, little things. Right? Or, an omnipresent pattern, that just keeps on recurring.

The point of the article is exactly correct; promise vaporware as a solution NOW, to prevent or stall the purchase of an existing solution, NOW. That they *might* actually deliver the vapor in five years? Irrelevent; I am NOT going to buy a "viable" solution today, when "nervana" is coming next week. I will wait, so that I can assess. Or worse, if the "vapor" is claimed to now exist,

Re:Ok, I'll bite.

[cnettel]

Win32 is not to Win16 what Win64 is to Win32. Win64 is a recompile, with a few typedefs changed and a few further changes where they were really needed.

Win32 contained lots of changes compared to Win16. Threads, overlapping I/O, lots of new controls, additions to GDI, long file names, pipes for IPC. It might seem like a joke, but access violations really had a greater chance of not taking the full machine down in Win95, versus Win 3.1.

And of course, a full driver model for all devices, with the Registry (yuck) to track the config. Yep, you could do anything in a VXD in 3.1, but there was no real structure to it. 32 bit disk I/O wasn't present in the original 3.1 either, so the difference is greater if we compare 3.1 versus 95, or the very last releases of 3.11 WfW versus 95.

Re:Ok, I'll bite.

[TheRaven64]

Win32s was available for Windows 3.1. It exposed some win32 APIs to win16 developers, but not all of them. From the Wikipedia page:

Although ostensibly compatible with early versions of Windows NT, many functions were not implemented including threading and asynchronous I/O, newer serial port functions and many GDI extensions. This essentially limits it to applications specifically designed for the platform.