Newsgroups: comp.std.unix Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!uunet.UU.NET!sef From: sef@kithrup.COM (Sean Eric Fagan) Subject: Re: access permissions in 1003.1 Message-ID: <1991Jun5.002425.2991@uunet.uu.net> Originator: sef@uunet.UU.NET Sender: usenet@uunet.uu.net (UseNet News) Nntp-Posting-Host: uunet.uu.net X-Submissions: std-unix@uunet.uu.net Organization: Kithrup Enterprises, Ltd. References: <1991Jun3.192534.28089@uunet.uu.net> <1991Jun3.225808.8518@uunet.uu.net> <1991Jun4.221021.26605@uunet.uu.net> Date: Wed, 5 Jun 1991 00:08:46 GMT Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix) Submitted-by: sef@kithrup.COM (Sean Eric Fagan) In article <1991Jun4.221021.26605@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: >Given the _POSIX_SOURCE feature test macro, OS designers can load all >they want in, and turn it off only when _POSIX_SOURCE is defined. That doesn't do everything. Yes, it's possible to come up with a system that is not only backwards compatible, but also provides full ANSI and/or POSIX compliance (although it is not possible, necessarily, to mix old and new). Problems encountered: namespace (have to get rid of everthing not defined by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet have to worry about old binaries, as well as sources, that may rely on such things [_iob was my favorite example, although there were several like items in libc that we had to worry a lot about]); different semantics for things of the same name (more an issue for section 1 and .2 compliance; things like df and du have portable definitions under POSIX, which may or may not be different from what old shell scripts expected). One POSIX "optional" feature, required by FIPS, was no-truncate; that is, if a filename exceeded the maximum name length for the filesystem, return ENAMETOOLONG. Do you know how many programs out there are written to generate *unique* names in 14 characters or less, but still will try to create names with *more* than 14 characters? B News, for example, I believe. Again, yes, it's possible to get around all of these. By having three seperate libraries and header files (old, ansi, and posix). By having two sets of command trees (/old and /posix; e.g., /old/bin/df and /posix/bin/df). By defining bits in the executable's header to indicate whether new features are to be used or not. (Incidently, uSoft did that, apparantly, with the OS/2 HPFS [high performance file system]: older programs which do not have the correct bit set in the header will not even *see* the longer filenames. I think this is wrong. Just MHO, though 8-).) >I'm >writing a Posix compliant system which will also be 4.4BSD compatable; >I know whereof I speak. And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards- compatible system (OS, commands, and devsys) for a major vendor. I also know whereof I speak. Many people reading this group can say the same thing; most of them can probably come up with their own horror stories. 4.4 was intended to be largely POSIX compliant in the first place, and BSD places less concern on backwards compatibility than commercial vendords do (SCO, for example, can still execute, *and develop for*, XENIX/XT binaries; can a BSD system say the same about BSD 4.1?). Does this mean that SCO is "better" than CSRG? No, I didn't say that. CSRG was able to come up with a much better system, in many ways (including size, a personal peeve 8-)), and most of their "customers" have sources anyway. But the problems commercial vendors have are very *real* problems. At this point, I'm curious how SunOS did: is it still able to run binaries from 5, 10 years ago, without modification? Can it still take object modules from that long ago, and link them in with current libraries? (Some third-party people ship modules, and let the customer link them with customized pieces, for example.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others. Volume-Number: Volume 23, Number 87