From owner-freebsd-hackers Wed May 24 10:56:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA19108 for hackers-outgoing; Wed, 24 May 1995 10:56:25 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA19102 for ; Wed, 24 May 1995 10:56:23 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07707; Wed, 24 May 95 11:48:25 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505241748.AA07707@cs.weber.edu> Subject: Re: (fwd) Re: Mma for Linux, when? To: kwong@fathergoose.net6c.io.org (Ken Wong) Date: Wed, 24 May 95 11:48:24 MDT Cc: hackers@FreeBSD.org In-Reply-To: <199505232243.WAA00273@fathergoose.net6c.io.org> from "Ken Wong" at May 23, 95 10:43:26 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > My question to all application developers/providers is why not make it > iBCS compatible. then, every OS can run it, at least in theory. Because IBCS2 is an insufficient system specification for writing fully featured programs (like POSIX, you can't do everything you want to be able to do because it has omissions for political reasosns). One major omission that Word and Wordperfect miss about the console is the ability to put it into scan code mode (not part of IBCS). There are plenty of others. When an IBCS2 product is shipped, it will end up with platform specific features that would also need emulation. For instance, for Lotus 1-2-3, the IBCS2 version relies on SVR3 package installation tools, which aren't part of the IBCS2 standard, and which don't exists on all "IBCS2" compliant platforms. Other applications, such as communications software, depend on device behaviour an naming conventsions. The naming is not part of the IBCS2 standard, and while parameters for standard tty settings *are* specified for fcntl/ioctl, the parameters for baud rates higher than 9600 are not. Similarly, the state mechanics for port open without DCD vary from IBCS2 platform to platform; generally, they involve a machine specific mechanism for disabling getty/uugetty/port-monitors which has to be called in a specific way -- for SCO, this would be the SCO enable/disable commands, which have to be run by an SUID root program using a sprintf( buf, "sh -c /bin/disable %s", ttyname); system( buf); to get around the root identity checking, which is stronger than simple uid/gid checking normal to such programs. For SVR3/SVR4, use of the normal getty program causes open's with the O_EXCL bit set, which using O_NDELAY opens can't be unset, and so must manually be unset by attempting a blocking open and alarming out of it. For ISC SVR4 UNIX, you have to actually pop off a streams module to enable binary transfers, since the tty's are streams-implemented. Suffice it to say, IBCS2 compatible says little more than the loader format and certain designated system calls are compatible. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.