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?

  • 1
  • 17
    This question appears to have nothing to do with floppies and everything to do with the lack of internet. Back in the day, every copy of the compiler came with a carrier pigeon. If we detected a bug, we would write a description of it on a very small piece of paper which we would then attach to the leg of the pigeon and release it. The pigeon would return to base, thus reporting the bug. The compiler company would then mail us a new pigeon in a basket, for use in reporting any subsequently discovered bugs. – Mawg says reinstate Monica Dec 5 '16 at 8:56
  • 2
    @Mawg and birdfeed was a widely under-reported yet significant portion of the TCO in those days! – Stephen Kitt Dec 5 '16 at 9:51
  • 2
    @StephenKitt And Microsoft hoarded a big bad army of buzzards to hunt down the poor Borland support pigeons - That's why Borland went down in the end and MS prevails in the market today ... – tofro May 21 '17 at 9:36
  • 1
    @Mawg Fortunately today we have advanced far past such ad hoc methods and can now use modern networking protocols over avian carriers. – cjs Mar 7 '20 at 7:08

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 BOR from 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:


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.

  • 2
    One pretty rotten bug I remember being shown on Borland's first Turbo C was that if x and y were constants, x/y would be evaluated as y/x. I've been fairly impressed with Borland C 2.0, and only remember one nasty bug which was fixed in the version (2.11 I think) in the museum but probably existed in 1.0 as well: 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... – supercat Dec 2 '16 at 18:03
  • 1
    ...output a number with three digits to the left of the decimal, rounded to two digits to the right (i.e. 000.00). Does the 1.x printf behave likewise, or was that a bug that appeared in 2.0? – supercat Dec 2 '16 at 18:03
  • 1
    Yeah the constant folding one was fixed within the first week of release. I don't remember the printf one but it wouldn't surprise me. – PeterI Dec 4 '16 at 6:33
  • And it's just occurred to me that prototypes where you can say what parameter types to expect were not part of K&R i.e. float myfunc(float ); was illegal, you could only do float myfunc(); and that was the cause of the bugs you talk about. – JeremyP Jul 11 '17 at 10:46
  • I'm not entirely sure about that, math.h for AT&T Research V7 from 1979 uses that style but the 386BSD code (from 1991) uses the extern double func (double,double); style. I can't quite nail down the point at which this changes. – PeterI Jul 11 '17 at 11:03

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.


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).


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.

  • 2
    Or worked around them, yes. Not a compiler bug, but I remember finding a bug in a Turbo C (or maybe it was Watcom) library routine and rewriting the function to avoid the bug. – LAK Mar 11 '20 at 15:35

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.

  • An upgrade in the mid-1990s that took several CDs!? Surely you mean floppies? Several CDs would be gigabytes' worth of data, which would be HUGE at a time when hard disks were commonly in the hundreds of megabytes range, or a few gigabytes if you had more money than you knew how to spend. – user May 20 '17 at 10:36
  • CodeWarrior came on multiple CDs because there was a lot of sample code, optional libraries, and documentation. I installed the subset of CodeWarrior I needed on my 250 MB hard disk from the CDs. Apple also shipped developer CDs much larger than the commonly available hard disk space in the 90s. – Michael Shopsin May 22 '17 at 15:50
  • 2
    Products definitely came on multiple CDs. Don't forget that multiple CDs isn't just about how much they can hold, it's also about independent revs of different parts of a product. If you keep sending out disk 1 & 2, but change disk 3, then QA has a lot less work to do. It's not like you have to fill them completely. – James Moore Aug 12 '18 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.