Newsgroups: comp.lang.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: ReadKey like Function in C Message-ID: <1989Aug17.164552.22925@utzoo.uucp> Organization: U of Toronto Zoology References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <1989Aug15.161101.19925@utzoo.uucp> <5711@ficc.uu.net> Date: Thu, 17 Aug 89 16:45:52 GMT In article <5711@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> The point is, the POSIX way of >> doing things is the closest there is to an OS-independent standard;... > >But it's not. In particular the Posix method of creating new processes is >highly OS-dependent... Sigh, Peter, you have *completely* missed my point. I wasn't saying that you could do POSIX on any operating system. Note the word "standard". My point is that POSIX, good or bad, is a *standard* operating system interface, with a formally-ratified manufacturer-independent document defining it and a great many standards organizations (and influential customers and suppliers) putting their weight firmly behind it. Even Unix's major competitors are swearing up and down that they will be POSIX compatible if it kills them (and it's certainly going to be painful for Microsoft, say, to reverse all its pathname slashes :-)). The odds of finding a POSIX-compatible interface on a random computer from XYZ Vaporboxes Inc. will be *far* higher than the odds for any other specific interface. Even people who cannot be fully compatible, say because they can't implement fork(), will try to be as compatible as possible, say in how you ask for raw keyboard input. >POSIX is not the answer to the gaps that (by necessity) exist in the ANSI >C standard. Perhaps not. But I don't see any superior alternative that is likely to gain the same volume of support, acceptance, and implementation. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu