Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!reed!psu-cs!omepd!perry
From: perry@omepd.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: MSC and signal catching
Message-ID: <664@omepd>
Date: Tue, 12-May-87 14:30:54 EDT
Article-I.D.: omepd.664
Posted: Tue May 12 14:30:54 1987
Date-Received: Fri, 15-May-87 06:47:20 EDT
References: <2681@mtgzz.UUCP>
Sender: news@omepd
Reply-To: perry@inteloa.intel.com (Perry The Cynic)
Organization: Intel Corp., Hillsboro
Lines: 21
Summary: MSC tries to be as UNIX-like as possible

In article <2681@mtgzz.UUCP> rosen@mtgzz.UUCP (Tom Rosenfeld) writes:
>According to the MSC manual signal() can only be used to trap for SIGINT
>(ctrl C) or SIGFPE (floating point exception). It seems to me all
>interrupts are the same (hardware and software) so I don't know why
>MSC only handles 2 of them. ...

MSC makes a real effort to give the programmer as much of a UNIX-like system
interface as possible in MS-DOS. In fact, they claim that provided you follow
reasonable guidelines, your object modules are binary compatible between
MS-DOS and XENIX. Thus, the signal() function must provide UNIX-style
functionality. If you check the list of UNIX signals, you'll see that only
SIGINT and SIGFPE make much sense under MS-DOS.

The UNIX signal() function cannot be used to intercept hardware interrupts
(heaven forbid!). Thus, MSC signal() can't either. I for one am quite happy
with the UNIX-interface approach of MSC. It makes porting C program so much
easier...
------------------------------------------------------------------------
  <<  Perry The Cynic >>		   =>> perry@inteloa.intel.com <<=
				      ...!tektronix!ogcvax!omepd!inteloa!perry
   (Peter Kiehtreiber)				...!verdix!omepd!inteloa!perry