Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!comp.vuw.ac.nz!virtue!ccc_ldo From: ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Newsgroups: comp.arch Subject: Re: Architectural quirks Message-ID: <1296.26d2c053@waikato.ac.nz> Date: 22 Aug 90 05:26:43 GMT References: <12459@encore.Encore.COM> <3300161@m.cs.uiuc.edu> <1990Aug17.155925.1588@mozart.amd.com> <1990Aug21.163009.26625@mozart.amd.com> Organization: University of Waikato, Hamilton, New Zealand Lines: 40 In <1990Aug21.163009.26625@mozart.amd.com>, davec@nucleus.amd.com (Dave Christie) says "I don't think major developers are prone to counting on quirks." Ahh, if only things were as simple in the PC world as they appear to be in the mini/workstation world... Probably the classic example is the ongoing battle between Apple and many developers of software for the Macintosh over Adherence to the Rules (as laid down in Inside Mac, the tech notes, the human interface notes and other miscellaneous pieces of documentation) versus the urge to take hardware-specific shortcuts. The most famous offender is Microsoft, and as far as I recall the most stupid thing they ever did (and there were some humdingers) was some scheme in Excel 1.x for determining if a floating-point coprocessor was present: the standard environment query wasn't good enough for them, instead they came up with their own ingenious test that worked with a 68881 but failed with a 68882. In the DOS world, one example that comes to mind is one of the problems that came to light as the 80486 chip was making its first few public appearances: it turned out that AutoCAD was neglecting to clear a "reserved" bit before loading a new value into an 80386 status register, and the '486 didn't like this at all. So they changed the relevant '486 instruction to ignore the setting of that bit. I guess this isn't a case of "counting on quirks" so much as neglecting to check certain low-level sources of possible future incompatibility *very* thoroughly. The end result being that the hardware vendor has to work around the software vendor's mistakes... PS: regarding "try this and you'll be shot"--read any Apple documentation lately? It's full of statements like this--and worse. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 ..that time of year when the kennels become a melting pot of molting pets...