Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.os.misc
Subject: Re: Why Unix is good (was Re: Unix bigotry) LONG
Message-ID: <9031@louie.udel.EDU>
Date: 17 Feb 89 21:58:20 GMT
References: <117@spectra.COM> <692@cvbnet2.UUCP> <3101@ficc.uu.net> <285@bnr-fos.UUCP> <140@aucis.UUCP>
Sender: usenet@udel.EDU
Organization: University of Delaware
Lines: 63
In-Reply-To: <4122@mdt.UUCP>
Cc:
Bcc:

In article <4122@mdt.UUCP> you write:
>In article <285@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
>Most ot those horror stories that I have traced down are cases of 
>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.
>-- 
>Philip W. Dalrymple III
>mdt!pwd
>404/587-2653

Speaking as one who managed a project to make all the company's code run
without change on MS-DOS, UNIX, AOS, and maybe others later, I think I
can shed some light on this. As background, we had a number of programs
for many clients that were very similar. The home office people wanted
to run the programs on minis or mainframes, while the agents in the field
had to run these on PCs. Nothing especially hardware-esk was going on
(these were insurance programs and such) but the users were nieve about
computers and had to be menued to death. Therefore, we needed 
help files that would rename keys to match what the user had, 
programs to present menus of other programs to run, backups and restores,
sohpisticated form entry stuff, strange file formats, background printing,
access through networks, ability to run from either floppies or fixed
disks without recompiling/linkng/etc, and so on. Basically, lots of stuff
that would be easier to do if only one operating system was involved.
The solution I used (which worked quite well, if I do say so myself) was
to identify the appropriate level of abstraction for the operations
to be performed. For example, colors on the screen were not "red", "green"
and so on, but rather "error", "field", "prompt", and so on. Files
were either text or binary (unix-style streams), and never the twain shall
meet, which allowed transparent handling of newline garbage and so on.
Screen calls were not things like "what string do I send to position
the cursor" but rather "position the cursor". Directory operations
did not read the directory files one at a time but rather returned a
list of all files matching a certain file type (spooled output,
data file, rate tables, configuration file, ...). Literal file
names never showed up in the code, nor did any information
about where files were stored ever need to be known by the application.
Not only did this allow for nice portability, but it allowed backup
and installation programs to use the same configuration files that the
application's libraries used to find, for example, where on the hard
drive each floppy program file belonged; and it was guaranteed to
be correct (previously a big problem there).

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