I said:
[ QUOTE ]
Your 'given' doesn't work. MS does not, and has not used technical means to break competitors.
[/ QUOTE ]
You replied:
[ QUOTE ]
There are many documented cases of Microsoft using technical means to try to break other companies' software, including IIS intentionally responding slower to requests from Netscape than from IE,
[/ QUOTE ]
IIS is the underdog, not a monopoly -- tough to leverage your monopoly when you don't have one. The browser/server interface is a mess, and always has been. Everybody uses sniffing code to workaround differences, and always has. Do you have a link to something that shows something more?
[ QUOTE ]
their various attempts to break DR-DOS,
[/ QUOTE ]
You mean the cryptic error message in the beta versions of windows 3.1? You realize windows exposed errors in dr-dos? (It had to -- a real-mode program relying on undocumented interfaces with lots of fancyness now running in V86 mode) The purpose of the beta is for MS to fix bugs in windows. Excluding dr-dos from the beta program is a reasonable technical decision, regardless of the motives of the developer. Surely you have some example of abusing the OS monopoly more recent than 1993? It is worthwhile to recall what Schulman (reverse engineered and published the story of the DR-DOS error message)
wrote:
[ QUOTE ]
I've often had to publicly defend Microsoft against what I felt were acts of scapegoating from whining competitors (including Novell, Borland, Lotus, and Wordperfect), complaints which remind me of the way some Americans like to blame Japan for what are ultimately our own domestic problems.
In fact, much of Microsoft's practice, far from targeting competitor's applications, points in the opposite direction: Microsoft sometimes goes to extremes to maintain compatibility, even with competitor's mistakes (see, for example, the crazy GetAppCompatFlags() function discussed in Chapter 5 of Undocumented Windows).
[/ QUOTE ]
The scapegoating has hardened into conventional wisdom.
[ QUOTE ]
changing the .doc format every version to break Open Office
[/ QUOTE ]
You assume the motive unfairly. Show me an office product -- commercial or open source -- that has made a major release without changing data formats! If they had no competitors they would still change formats between versions. A change that hurts competitors is not the same as a change designed to hurt competitors. MS published the APIs for Ole Structured Storage (the office binary format) a long time ago (~1994). They want programs to interoperate, it stimulates demand.
[ QUOTE ]
and (earlier) Corel and Lotus,
[/ QUOTE ]
MS was the underdog to them. There's no advantage to changing your native format when you're in 2nd place. MS beat them in a brutal price war and eventually MS offered a superior product.
[ QUOTE ]
and their numerous "extensions" to open standards designed to make them proprietary
(see Kerberos and their failed attempt with Java).
[/ QUOTE ]
MS makes extensions that it believes customers want. Let's take java as an example. MS believes their developers expect a java program written with MS tools will be able to easily use COM technology. This is a correct judgment. They had to pay Sun a pretty high price in court for making it easy to use COM with java. MS will sometimes embrace and extend technology from the unix world. The unix world always ignores MS technology, even when it is superior and freely available (see COM).
[ QUOTE ]
Backwards compatibility is easy to maintain when you know exactly what changes you are making to try and shut everybody else out.
[/ QUOTE ]
This is an unfair and contradictory statement. It's unfair because there's nothing easy about backwards compatibility; it is a technical challenge because applications depend on every aspect of the existing interface, not just the published part. If the program ran before and doesn't now then you don't have backwards compatibility -- by definition -- so shutting programs out and having backwards compatibility are contradictory.
Joel Spolsky on compatibility:
[ QUOTE ]
I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
This was not an unusual case. The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1. In fact if you poke around in the AppCompatibility section of your registry you'll see a whole list of applications that Windows treats specially, emulating various old bugs and quirky behaviors so they'll continue to work. Raymond Chen writes, "I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95."
A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work.
... To contrast, I've got DOS applications that I wrote in 1983 for the very original IBM PC that still run flawlessly, thanks to the Raymond Chen Camp at Microsoft.
[/ QUOTE ]
[ QUOTE ]
Windows is not MSFT's only product.
[/ QUOTE ]
A fair point. I was only thinking of the OS group when I said MS doesn't make technical changes for the purpose of breaking competitors. Could you kindly present a contrary example from a public release of Windows?