ABIs and the futurrrr of UNIX(tm)

Stephen M. Gerard gerard at tscs.UUCP
Tue Mar 29 15:15:12 AEST 1988


In article <431 at micropen> dave at micropen (David F. Carlson) writes:
>
>Why can't a machine independent intermediate
>form be developed for UNIX solely to be translated into native binary on the
>target machine by a similar utility?  This form would have to be opaque 
>enough to discourage un-compiling but adaptable enough to allow for tight 
>native translation on any SystemV (and eventually POSIX) machine.

This sounds good to me!

As a software developer, I can appreceiate the need for protection of source 
code.  However, it is possible through the usage of a disassembler, and some 
work, to generate usable assembly language source from a binary.  

A pseudo assembler interface could take advanatge of optimized library 
routines for each processor type and yield satisfactory results for most 
applications.  This type of standard would not discriminate against the less 
popular cpu's and could offer across the board compatability for UNIX systems 
ranging from desktop PC's to Cray's.  This would still give the software 
developer reasonable protection because without documentation and meaningful 
variable names, the ability to edit such code would be limited to about the 
same level as code generated by a good quality disassembler.  The plus side 
for the software developer, is that they now have a much larger market to sell 
to.  Software vendors for highly compute intensive applications could still 
offer native code releases for a greater cost.  

Any binary standard that limits you to one or two primary cpu vendors is 
better than no standard, but, in my opinion, limits your choices and is still 
too proprietary.  A solution that would be fair to all hardware vendors would 
generate greater momentum towards the standardization of UNIX and offer the 
end user with a greater variety of software solutions.  A good standard would 
allow the end user to purchase the best hardware solution for their needs 
without the fear that they will be limited in their choice of applications 
software.  After all, it is the end user that buys the hardware and software 
that fuels the industry with capitol to insure profits and future improvements.  
The way I look at it, everyone can be a winner!

The end user gets:
	+ An almost unlimited choice in software.

	+ Hardware vendor independant protection for their software investment.

	+ The ability to choose hardware by hardware specifications not
	  software availability.

	+ Lower pricing for popular applications due to increased sales
	  volume and competition.

	+ The ability to easily adapt default values to local conventions.

The software developer gets:
	+ An increased compatability for their software without the need to port
	  to multiple machines.

	+ Increased revenues due to increased sales.

	+ Ability to make improvements faster because programmers can
	  concentrate on the application as opposed to porting problems.

	+ The ability to compete in both the low and high end markets.

The hardware vendor gets:
	+ An increased library of applications that can be used to sell
	  their machines.

	+ A greater potential market created by the increased acceptance
	  of UNIX that would be created by such a standard.

Across the board binary compatabilty would give the UNIX marketplace a
shot in the arm and encourage small businesses to venture out of the MS-DOS
world and take a good hard look at UNIX.

I feel with true hardware independant binary (executable) compatability,
UNIX can easily become the operating system *standard*.

Of course these things can't happen overnight, after all, there are still
vendors out there selling systems with System V.1.

------------------------------------------------------------------------------
Stephen Gerard  -  Total Support Computer Systems  -  Tampa  -  (813) 876-5990
UUCP: gerard at tscs				  ...codas!usfvax2!tscs!gerard
US-MAIL: Post Office Box 15395 - Tampa, Florida  33684-5395



More information about the Comp.unix.wizards mailing list