nboogaar@ruunsa.fys.ruu.nl (Martin v.d. Boogaard) (02/16/90)
Recently I used the dos.h file supplied with Borland's Turbo C 2.0 on
a few PC's. It worked fine on a Philips XT and on several AT's but it
gives rise to some unjustified compilation errors when it is used on
my XT 286 machine. The instruction set setting (8088,80286...) didn't
seem to matter.
Anybody any idea?
Martin J. van den Boogaard
Dept. of Atomic & Interface Physics, Rijksuniversiteit, Utrecht
P.O. Box 80.000
decnet: ruunsc::boogaard NL-3508 TA Utrecht
bitnet: boogaard@hutruu51.bitnet the Netherlands
internet: nboogaar@fys.ruu.nl +31 30 532904darcy@druid.uucp (D'Arcy J.M. Cain) (02/17/90)
In article <500@ruunsa.fys.ruu.nl> nboogaar@ruunsa.fys.ruu.nl (Martin v.d. Boogaard) writes: >Recently I used the dos.h file supplied with Borland's Turbo C 2.0 on >a few PC's. It worked fine on a Philips XT and on several AT's but it >gives rise to some unjustified compilation errors when it is used on >my XT 286 machine. The instruction set setting (8088,80286...) didn't >seem to matter. > >Anybody any idea? > > No one's clairvoyant here. Can you tell us what the error messages are. -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | (416) 281-6094 |
nboogaar@ruunsa.fys.ruu.nl (Martin v.d. Boogaard) (02/18/90)
In article <500@ruunsa.fys.ruu.nl> I wrote: >Recently I used the dos.h file supplied with Borland's Turbo C 2.0 on >a few PC's. It worked fine on a Philips XT and on several AT's but it >gives rise to some unjustified compilation errors when it is used on >my XT 286 machine. The instruction set setting (8088,80286...) didn't >seem to matter. > >Anybody any idea? Both david@csource.oz.au (through email) and darcy@druid ( > No one's clairvoyant here. Can you tell us what the error messages are. ) asked for the error messages. Sorry, I didn't expect clairvoyancy, I just thought it was one of those C problems that have obvious solutions. TC complained about illegal function declarations in lines 180 and 211 of dos.h. Off course the solution was even more trivial than I thought it would be: switch off the `ANSI keywords only' option; if you don't, TC's `interrupt' function-definition attribute is not recognized as such. Somewhere in the past I must have decided to use only ANSI C on that specific machine. Martin J. van den Boogaard Dept. of Atomic & Interface Physics, Rijksuniversiteit, Utrecht P.O. Box 80.000 decnet: ruunsc::boogaard NL-3508 TA Utrecht bitnet: boogaard@hutruu51.bitnet the Netherlands internet: nboogaar@fys.ruu.nl +31 30 532904