Path: utzoo!utgpu!bnr-vpa!bnr-fos!bnr-public!schow From: schow@bnr-public.uucp (Stanley Chow) Newsgroups: comp.os.misc Subject: Re: Why Unix is good (was Re: Unix bigotry) LONG Summary: Portability is in the eye of the beholder Message-ID: <299@bnr-fos.UUCP> Date: 21 Feb 89 04:56:06 GMT References: <117@spectra.COM> <692@cvbnet2.UUCP> <3101@ficc.uu.net> <285@bnr-fos.UUCP> <140@aucis.UUCP> Sender: news@bnr-fos.UUCP Reply-To: schow@bnr-public.UUCP (Stanley Chow) Organization: Bell-Northern Research, Ottawa, Canada Lines: 163 In my original article <2850@bnr-fos.UUCP>, I complained about several problems of Unix. Several people have commented on my point on Portability and only one person commented on Ugly User Interface. Does this mean all my other points have universal agreement? (I know, I am asking for it, but as long as I am trying to "stimulate" discussion -- :-) :-) The first problem I listed was Portability: > > - Non-portable code. I know the truism "Unix & C are the most > portable system & language". I have no knowledge about the portabiity > of Unix itself (the many versions of it) but the horror stories I > have heard (and read about in the net) makes me think twice. > (I am not saying it is impossible to produce an implementation of > Unix that is nicely protable or that all C programs are inherantly > non-portable, just that current practice does not). In article <140@aucis.UUCP> bnick@aucis.UUCP (Bill Nickless) writes: > > At least with UNIX you have a CHANCE at writing semi-portable code! The > netnews software, for instance, written on one machine is installable on > the many variants of machines, even running *nix's from different vendors. [Bill then talks about the silent success stories and different concepts of what a horror is.] I am really trying to point out that yes, Unix (& C) does allow people to write code that is very portable, but it does not follow that all C programs written for Unix are automatically portable. As other people point out (see replies below), writing portable Unix/C program takes major effort. To take your example, I am told 'rn' has #ifdef nested up to 6 deep to allow for the difference of systems and machines. Given the same amount of effort, there are langauges like Fortran (oh no, did I just say another bad word?) that can be more portable, even if the application is restricted to a narrow domain. In article <4122@mdt.UUCP> pwd@mdt.UUCP (Phil Dalrymple) writes: > > In fact we have about 250K lines of code that runs under Unix on five > differnet system (both SYSV and 4.2) and the ONLY changes that need to be > made (including ifdefs) are for byte order and the handling of the rs232 > handshake lines for a very non standard device that we must connect to. > Most ot those horror stories that I have traced down are cases of > > 1) Hardware (like our rs232 or byte order) but worst. > > 2) The people do not know what they are doing. > > 3) An attemp is being made to port to another OS as well as Unix. > > Item 3 above is the one I notice most often but I can not explan it. > It may be that the fact that a large amount of changes are needed to port > the code to say VMS or MS/DOS makes those doing the ports to a number of > unix systems accecpt a lower standard of portabilty (sp?) in the code. > Again, I only wish to point out that many (if not most) of current existing programs do not port easily to diverse systems. I would suggest that you have done well if your 250K lines can be ported just by looking after byte orders. (By the way, do you handle 9 bit bytes? Nil pointer that is not 0? Segmented architecture that does not allow addresses before or after an allocated object? Different precision floating point?) In article <9031@louie.udel.EDU> new@udel.EDU (Darren New) writes: [Darren comments on Phil's article and relates his experience in a project and describes the solution he used - Abstraction. SC] > > Anyway, I think the problem of porting to other OSes is due to > not abstracting to the proper level. I have had success with writing > a "portability library" that defines what I want to do in terms of > what the OS provides. Had parsing information (like '/' separates > directory components) shown up in the application code, moving > things to VMS would have been a nightmare, because VMS has a > totally different file naming convention. As it was, redoing most > of the code for directory and file manipulations allowed things > like the interactive installer and the backup/restore programs to > run after simple recompilations. I would suspect that most of the > "horror stories" about moving to other OSes were due to the original > code never being segmented into OS-dependent and OS-independent > portions because the author never considered moving it to a new OS. > On the other hand, since the above project, I have never failed to > segment a program into such portions, and I have never had problems > moving my own programs to other OSes with relatively trivial effort. > - Darren New My point exactly. It is the methodology and style of coding that makes code portable, not the system for which it is written and not the language in which it is written. In article <7911@boring.cwi.nl> jack@cwi.nl (Jack Jansen) writes: > > The real-world issue is not portability of the kernel but portability > of user programs. Unix is still the only OS in the world that will > allow *reasonably* easy porting of *many* programs to *some* > wildly different machines. Note the emphasised words: porting is not > trivial, it will not work for all programs, and not for all machines. I quite agree. I take exception only with people who make your statement WITHOUT the highlighted words. > Compare porting a program between Amdahl UTS, Dec VMS and XENIX > to porting it between OS/360, VMS and MS/DOS. I have had occasion to move Fortran (that dreaded word again) programs between some systems, in the intended domain (that is, a lot of number crunching), I suggest Fortran is at least as easy to port. In fact, I think I will go whole hog and suggest that on large projects (> 1 million lines), the language and the O/S is irrelevent since it will be cheap to retarget the compiler and O/S to the new harware. In the same vain, have you tried to port Sun tools to X-windows (I know, this is not strictly Unix) or just between Sys V and BSD? :-) [Jack then comments on my complain about the Unix user interface. SC] > Absolutely true. Playing devils advocate again, though: have you > ever worked on OS/360? NOS/BE? Or, more in the same class of OS'es > as unix, VMS or MS/DOS? > The *only* reason novices can manage to learn MS/DOS is because there > are only 5 commands to learn. MSDOS < UNIX <<<<<<< Macintosh. As a matter of fact, I have used OS/360. I have no problem in hating it but I would not say it is worse than Unix, just bad in different ways. Also, no one seriousely suggests OS/360 (MVS, ...) as a real interactive system, for batch systems, it has a certain perverted appeal. There is one major point in favor of OS/360: you can always find the information in the obvious manual AND you can trust the information. Would you say that about Unix? :-) As to MS/DOS, would you really put Unix in the same class as MS/OOS? It isn't really fair to compare an 8088 on floppy to an 68030 with a fast 60 MB drive and ethernet. :-) :-) MS/DOS can get by with so few commands is that users (like me) use it to get into an application and forget about MS/DOS. (That shows you what I think about MS/DOS.) Have you looked that Amiga? It has a well thought out (comparatively) kernal interface that accomadates graphics, windows, multi-tasking, etc.. Many Unix hackers like it because of the flexibility and power like Unix but a very efficent system and clean interface. Stanley Chow ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public (613) 763-2831 Disclaimer: What? Me? Have an opinion? Surely you jest. Represent any one? Ha, I don't even represent myself.