Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!rutgers!att!whuts!homxb!mr
From: mr@homxb.UUCP (mark)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C 2.0 / pricing reality, buil
Message-ID: <2366@homxb.UUCP>
Date: 2 Nov 88 15:37:58 GMT
References: <182@imspw6.UUCP> <16800385@clio> <1724@dataio.Data-IO.COM> <4539@bsu-cs.UUCP>
Organization: AT&T
Lines: 19

In article <4539@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
# In article <1126@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes:
# >QuickC 1.0 had a problem
# >with a certain OLD Western Digital controller due to a BIOS flaw that
# >Western Digital promptly fixed.
# 
# Why on earth would a C compiler be dependent on specific disk controller
# hardware?

The problem was not during compile time, it was during run time.
Quick-C can also run a C program from within. Is seems that the
same interrupt was used as the disk controller used and caused
the disk to be scrambled. This happened to me once, though I was
able to recover since DOS keeps two copies of the FAT table.

# -- 
# Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi

mark
homxb!mr