Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!jack!sdeggo!dave From: dave@sdeggo.UUCP (David L. Smith) Newsgroups: comp.unix.wizards Subject: Re: ABIs and the futurrrr of UNIX(tm) Message-ID: <186@sdeggo.UUCP> Date: 2 Apr 88 06:44:16 GMT References: <431@micropen> <185@tscs.UUCP> <587@garth.UUCP> Organization: Lazy Programmer's Society of San Diego Lines: 65 In article <587@garth.UUCP>, walter@garth.UUCP (Walter Bays) writes: > In article <185@tscs.UUCP> gerard@tscs.UUCP (Stephen M. Gerard) writes: [ A call for a psuedo-code machine independent binary standard ] > > The idea sounds very good. But perhaps you can explain why it's so > hard for a developer to provide multiple versions. (This is not a > knock at developers; I simply don't know the answer.) If we believe in > source code standardization, all you have to do is recompile. (Right? > :-) Is the problem access to the various machines to do the port? Well, there are enough problems just porting across machines and slightly different version of Unix. For example, today I started work on porting some code from our ancient Parallel which runs an old release of SunOS to our nifty, new ICON system. Hardware-wise, the ICON is very nice, but their implementation of UNIX has a few weird quirks, due to their hybridization of BSD and Sys V. At the heart of my code is a set of database routines that use flock() and lockf() calls to keep things in order. On SunOS lockf() has an enforced mode, where the kernel will make routines that attempt to read/write a locked section block until it is unlocked. ICON choose to implement the Sys V version instead which does not have an enforcement mode. Since I was depending on this enforcement in a few parts, I had to rewrite the routines so that they do a check for locks before read/writing. I had also fortunately encapsulated read/writes to the database into a few routines which I could modify easily. However, if I had not and I had several thousand read/write statements into this database which depended upon enforcement it would be a serious problem, requiring quite a bit of man-power to track down and fix. This is not a _major_ problem and the port is going rather smoothly, but this is just between two 680x0 based machines, both running BSD derivatives. In fact, I could have taken my SunOS binaries over to the ICON and waved a magic program over them and had them run on the ICON. Had I done this, however, the enforcement mode would not have worked and I would have ended up with one royally screwed-up database with no clue as to how it got that way. The psuedo-code idea is nice, but I'd settle for full source code compatibility. However, the only way to get this is to buy an identical machine with identical software and one of the reasons we all like Unix so much is that it runs on so many different pieces of hardware supported by so many different vendor. If each vendor were to implement "standard" Unix and only "standard" Unix, what would be the point of having different vendors? However, with different vendor extensions the only way to write portable code is to write to the minimal standard, which defeats the purpose of having extensions. What's my point? We cannot have "standard" Unix running on "standard" hardware unless we are willing to accept stagnation. View the microcomputer marketplace. It is standardized around the IBM PC/MS-DOS standard and has been _stuck_ there for four years without significant change. "Standard" Unix and hardware standardized around SPARC will force the same stagnation upon the Unix and mini-computer market. In order for us to have new and niftier products to play with, we must accept the burdens that come with new and different things; namely some hard work in getting them working. Unix, as of 1988, is not the ultimate in operating systems. What AT&T and Sun will produce will not be either. I hope what I will be working on in the year 2000 will be significantly different from what I'm working on today, however I doubt it. We seem to be narrowing in on a peak for computers which will not substantially change for some time. (Sorry for the soapbox, but I needed to say it) -- David L. Smith {sdcsvax!jack,ihnp4!jack, hp-sdd!crash, pyramid, uport}!sdeggo!dave sdeggo!dave@amos.ling.edu Sinners can repent, but stupid is forever.