Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!steve
From: steve@acorn.co.uk (Steve "Daffy" Hunt)
Newsgroups: comp.windows.x
Subject: Re: Forcing application to process events
Message-ID: <1682@acorn.co.uk>
Date: 16 Feb 90 15:23:25 GMT
References: <9002151623.AA19195@dawn.crd.Ge.Com>
Reply-To: steve@acorn.UUCP (Steve "daffy" Hunt)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 37

In article <9002151623.AA19195@dawn.crd.Ge.Com>
stpeters@dawn.crd.ge.COM (Dick St.Peters) writes:
>(Steve "Daffy" Hunt) writes
>
>> Yes, but what a shame Sun did not try to write it portably.  I am
>> referring to the very dubious technique of redefining syscall wrappers
>> for read, select (and something else) and then using some parochial
>> method for accessing the 'real' syscalls.  Wacky.
>
>That "parochial" method is available on Ultrix machines, Masscomps,
>and even under Eunice, the Wollongong UNIX emulation for VMS.  What a
>shame some vendors don't provide it.

Yes, so what, it's available under any Berkeley-based system,
including ours.  That does not make it portable.

Let's see.  Syscall().  Cursory research shows that:-
	it's not in X/Open.
	it's not in ANSI.
	it's not in POSIX.
	it's not in the SVID.

Looks really portable.

As I originally said, it's a parochial method.  From that most famous
source of parochial hacks, BSD.

>What would you have Sun do?  Rewrite everyone's OS?  I'll bet this
>method is available in SysVR4 :-)

It may or may not happen to appear in some SVR4 implementations, but
it's not in the SVID.

Besides, the very idea that you can cheerfully redefine symbols and
expect everything to work is a parochialism.

					Steve Hunt.