Take the Microsoft C 1.0 compiler for example. It shipped on multiple 5.25" 360K disks, and when it ran on machines without internal hard disk, so users had to switch floppies between the editor, compiler, and linker.
If there was a bug with the implementation of the editor or compiler itself, how could an end user report it? How did big software companies (such as Microsoft or Borland) open up channels of communication over user-reported issues?
In the early PC days, letter-writing was still common, and that was at first the main channel of communication to report issues. When CompuServe took off that became the preferred forum, at least in the US. Phone support was also always an option!
Here's a typical contact section from a manual, in this case the 1987 Turbo C manual:
How to Contact Borland
The best way to contact Borland is to log on to Borland's Forum on CompuServe: Type
GO BORfrom the main CompuServe menu and select “Enter Language Products Forum” from the Borland main menu. Leave your questions or comments there for the support staff to process.If you prefer, write a letter detailing your comments and send it to:
[...]
As a last resort, if you cannot write to us for some reason, you can telephone our Technical Support department. Please have the following information handy before you call:
- product name and version number
- computer make and model number
- operating system and version number
(the phone numbers were provided in a separate document in the box).
As mentioned in the answers to How were analytics gathered on software built for retrocomputing platforms?, when that stopped scaling, users wrote to magazines instead, in the hope that their problem would grab the magazine writers' attention and they would either solve it themselves, or use their contacts in the relevant company. Actually that's not quite accurate, users started writing to magazines with programming problems as soon as magazines existed!
I worked for Borland in the UK doing support for Turbo C 1 to 1.5. Most contact was via mail or telephone in those days. Bugs were sent over to the US after we did some triage to check if they could be reproduced; I think it was all stored in Reflex (a Borland-produced database) and we got copies of the database periodically.
We had Compuserve, MCI mail, Bix & Cix accounts for online support, but most things were over the phone. We'd normally mail customers replacement floppies, or sometimes we would fax over instructions if the patch was small enough. IIRC there was a patch for the first version of Turbo C which did floating point constant-folding in the wrong order for division (a bit of a show-stopper given the first example in K&R).
I used to phone my US colleagues in the late afternoon to find out what was happening to bugs or if they already knew about a new issue. We'd use MCI mail to communicate with the US over an X.25 Pad system.
Most of the support issues were solved by turning on all of the compiler warnings after the user sent over the source code (in the mail) and working through them. Lots of users of Turbo C were still writing pre-ANSI K&R style C with some fairly dodgy casts, so often the bugs were in their code. Sometimes it was things like double-to-single promotion with function prototypes where classic K&R declarations
extern float myfunc();
float myfunc(p)
float p
{}
actually defines p to be a double due to type promotion (I've forgotten the exact details as it's nearly 30 years ago).
Actual bugs were rare; the only other one I can remember is that code like this:
outportb(0x3fe,inportb(0x3fe)&0x55)
didn't work if you included the <dos.h> header file which turned the function calls into inline x86 calls and the compiler threw away the result of the inportb for some reason.
printf("%1.2f", 999.996); would determine that the value was at least 100 but less than 1000, so it should have three digits to the left of the decimal. It would then...
float myfunc(float ); was illegal, you could only do float myfunc(); and that was the cause of the bugs you talk about.
extern double func (double,double); style. I can't quite nail down the point at which this changes.
You could easily say that having no proper forward channel to customers was the same problem as having no backwards channel to the software vendor. The internet has made a lot of things easier.
For games and cheap software, you had to mainly live with the bug, work around it, or be lucky to find a patch in a magazine.
The User Registration Card that came with some more expensive software was a much more important thing than it is today (Do they still have it? I don't think so).
Major bugs in commercial software were, however, a much more crucial thing than it is today - Send a patch via e-Mail, or offer a fix as a download, and you're done. In the old days, disk-based software was often dubbed and shrink-wrapped by third party suppliers - most software houses didn't do that themselves. In case you found a bug, you had to throw away whole batches of software packages across the whole delivery chain and replace them with new versions - major catastrophe. Existing and registered users would maybe get a "fix pack" on some disks to make them happy - But the more important factor really was the packages not yet sold. You had to call them back from the shops and replace them with new, fixed packages (Or have the shopkeepers add the fix packages to the existing sets, wich was only just a tad easier)
That did, maybe, have some impact on quality control because that way a severe bug was much more expensive than it commonly is today (But you could also argue that software wasn't quite as complex back then, and you might probably be right).
Fax was another option. We were in contact with Borland in the early days of Object Vision. The poor thing wasn't able to do anything useful for us, and we exchanged issues and documentation with Borland via faxes. Software patches and some DLLs required to extend the functionality of the software were transfered via modem. This was on 1993.
My response is maybe a bit "off-topic" since in the 1970's our IBM mainframe compilers were installed from tape rather than floppy disk. But for interest sake, let me put on record the process followed.
A compiler bug would first be identified by an application programmer, since his code once compiled was doing something stupid. Of course, lots of programs did stupid things after compilation, so he first had to convince himself and a "software programmer" that it was the compiler that was at fault. Once the softie was convinced he would scour through the list of known bugs, which was on microfilm (if anyone has heard of that) and updated on a regular basis ~ quarterly or so . If he found it there was a fix to apply. If he didn't there was a page at the back of every IBM manual where you could enter the details and post it off. This never resulted in a response, so you would find some alternate coding construct to achieve your aim and normally find that it compiled to give you the desired result.
First note that the question implies that 5.25" 360K disks was the beginning of computer programming and it was not. Before IBM designed the IBM PC, IBM had already designed and implemented many computer systems and operating systems.
Sophisticated communications capabilities existed before the internet. IBM had SNA. IBM's PROFS even had an email system that existed before the IBM PC.
For IBM PC systems there was something called serial communications that could be used to transfer data over phone lines.
Prior to floppies there was tape, as in magnetic tape, that has existed for more than a half a century. Magnetic tapes were relatively inexpensive.
It was totally possible to send a floppy in the mail.
The fast and noisy bug-fixing, constantly-updating ecosystem we know today has only become popular in the mainstream somewhere in the 90s, probably coming from the open source community.
Testing for critical bugs was expected to be much more the responsibility of the vendor, and what was not found got shipped and only maybe fixed in the next release. Bugs were supposed to be something to curse about and work around, not report or fix - unless it was critical enough to make you call the vendor. Shipping software with a major bug, though, actually was a bigger disaster for a vendor than today: you essentially had one chance to deliver the customers (and print magazine reviewers) with a product considered working good-enough and fit for the purpose. Serious fixes would have meant real-life product returns and shipping fixed media, not just offering some download and calling it fixed.
With problems making the software unusable for SOME customers, likely only those customers were shipped a fixed version when they rang and asked for a problem solution.
Do not forget that many bugs that cause constant updating and a pressure to use up-to-date versions these days are security, not functionality related. Security bugs were a foreign concept in personal and small business computing in the pre-mainstream-internet days (except in actual networking and security software). If a certain input could make a software do something undesirable, it was considered OPERATOR ERROR to give it that input and not a security problem. Virus writers didn't bother to exploit vulnerabilities in data readers since just using straight up executable files as a vector was more effective. Somebody crashing your business network intentionally would not have been considered a gray-hat figure but a criminal saboteur or vandal.
Chances are, many software vendors didn't care about bugs that caused no one actual problems worth complaining about in anger.
One option not mentioned yet, was that we did nothing and lived with the bug as it was.
I still remember using phone support in 1994-5 with Metrowerks, when CodeWarrior had a serious shared library loading bug. The bug was known but not fixed in that version, so we had to order a new version - several CDs. So the old style of support persisted into the early days of the web, because most people did not have the bandwidth or space to download significant patches. When updates were placed on servers in 1994-5, the servers got slammed. Apple put System 7.5.5 on ftp.apple.com and I had to download the update from Usenet groups instead because all the official servers were busy.
