Date : Sun, 24 Jul 2011 19:18:40 +0100
From : profpep@... (Mike Pepper)
Subject: Risc PC (Was 'Minitel in France')
> > "Ensure my software works on as wide a range of platforms as
> > possible using the defined APIs and not messing about tying it
> > down to as small a number of platforms as possible" ?
>
> Pity that reality means that idea doesn't really work.
>
Which is the other version of "There's never enough time to do it properly,
but there's always enough time to do it again".
When I look at the number of programs that broke or needed upgrading as we
went from Win3.11, to Win 95, it was mad. I can't even reckon what I had to
chase for Win ME. All the direct driven hardware broke from Windows 2000
onwards. The Dongles that wouldn't work across versions, (I had to get
software 'hacked' for several clients, where the software or dongle company
had gone; leaving, in one case, a ?50,000 colorimeter, with the only other
option of buying a new software suite at a price of around half the cost of
a new machine).
They all do it - I remember finding a mail order company that was having
slow response problems with the mainframe, and it turned out that the
original software was running on a emulation of the orginal hardware and OS,
because no-one wanted to risk the debugging that would come with
re-compiling the COBOL for the newer 'frame. I got it done, and seriously
upset the mainframe supplier, who was expecting to sell them another, even
faster system to emulate it on, (and that would have stacked 2 emulators, as
I recall!)..
A lot of the early Mac stuff broke at Mac II, because despite warning from
Apple to write 32 bit clean software, a lot of companies used the 'spare' 8
bits to store things in, (the original 68000 had 24 bit addressing).
You can't always rely on the API's either - did anyone here have the fun and
games with different non-backward compatible versions of CTL3D.DLL?, for one
example that sticks in my mind.
PC compatibility can still be an issue, just from motherboard interactions,
or hardware makers that don't stick to the rules. SATA 2 was supposed to be
transparently backward compatable with SATA 1. Have you noticed how many
drives have, (sometimes un-documented), 'Force SATA 1' links, because either
the drives of the BIOS' can't negotiate the version? SCSI seesm a bit better
in that respect, even so, sometimes one rogue device will drop the whole bus
speed to a crawl.
It seems a fact of life in the world of computing. I don't think Acorn's
record is particularly worse than that of many bigger companies. Sometimes
the gutsy thing to do would have been to scrap the old standard, (Like the
horrible PC boot sequence once we got beyond the 286 - I remember being
unable to boot a Windows CD with certain SCSI cards, because the crappy
drivers couldn't change mode).
Funnily, the only app of mine which didn't break across many machines was a
Linux based data logger. It's till running on it's 4th machine now, despite
never being re-compiled. Though I do regard that as more of a fluke, and the
fact that it doesn't have a GUI.
Mike