Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mcnc!ece-csc!uvacs!mac
From: mac@uvacs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: MSC and signal catching
Message-ID: <1487@uvacs.CS.VIRGINIA.EDU>
Date: Thu, 14-May-87 11:53:48 EDT
Article-I.D.: uvacs.1487
Posted: Thu May 14 11:53:48 1987
Date-Received: Sat, 16-May-87 14:45:25 EDT
References: <2681@mtgzz.UUCP> <664@omepd>
Organization: University of Virginia
Lines: 19
Summary: SIG{INT,FPE}

> 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 point of using the names SIGINT and SIGFPE is to avoid depending on
their numeric values.  If MS had been careful they could have defined these
values and the signal function to handle other interrupts.  Instead they
chose object code compatibility.

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

The UN*X fork() function can be used.  The MS-DOS can't.  Porting code doesn't
always work.  Maybe MS should have produced a compiler for MS DOS.