caf@omen.UUCP (Chuck Forsberg WA7KGX) (10/20/85)
Now that we have at least four announced versions of SYS V Unix for the 80286 (Xenix, PC-IX, Venix, and the 6300+ OSmerge), I would like to know if these systems are compatible at the binary program level that Bill Gates has declared imperative for commerical success. Can a single binary of a program such as vi or uucico run the 80286 with these four systems?? "SYS V: Consider it standard?" -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Home of Professional-YAM, the most powerful COMM program for the IBM PC Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/22/85)
> Now that we have at least four announced versions of SYS V Unix for the > 80286 (Xenix, PC-IX, Venix, and the 6300+ OSmerge), I would like to > know if these systems are compatible at the binary program level that > Bill Gates has declared imperative for commerical success. Bill Gates has his head up his assembler. There is more to UNIX than Intel processors, and there is more to 8086 family UNIXes than MicroSoft. Sure, if there were no competition, MicroSoft would clean up. Is that a desirable goal to anyone besides Gates? What is he doing to promote viable UNIX standardization? Has he sent representatives to the P1003 working group meetings? Don't believe everything you read, especially UNIX/WORLD.
fair@ucbarpa.BERKELEY.EDU (Erik E. &) (10/22/85)
In article <248@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >Now that we have at least four announced versions of SYS V Unix for the >80286 (Xenix, PC-IX, Venix, and the 6300+ OSmerge), I would like to >know if these systems are compatible at the binary program level that >Bill Gates has declared imperative for commerical success. Bill Gates has his head up an unnamed orifice. The success of UNIX in the marketplace thus far is predicated on one thing: it is portable, and therefore independent of vendor hardware. This means that applications written for UNIX are also portable. Assuming that you carefully code your application, there is no reason why you can't start on an IBM PC or equivalent toy, and as your needs require, move up to (say) a Cray-2. UNIX portability means independence of users from manufacturers of computer equipment; no longer are your operations threatened with utter halt if DEC goes under tomorrow. Good luck if you use VMS. It also means that computer manufacturers no longer need to perpetuate their past mistakes in the name of backward compatability (e.g. Intel 8086, 80186, 80286, ... ; IBM 360, IBM 370, ...). Anyone worrying about binary compatability for UNIX programs has totally missed the point. Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU
campbell@maynard.UUCP (Larry Campbell) (10/23/85)
> In article <248@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >Now that we have at least four announced versions of SYS V Unix for the > >80286 (Xenix, PC-IX, Venix, and the 6300+ OSmerge), I would like to > >know if these systems are compatible at the binary program level that > >Bill Gates has declared imperative for commerical success. > > Bill Gates has his head up an unnamed orifice.... The success of UNIX in (rest of flame elided for brevity) Everyone seems to be missing the point here. Yes, it is wonderful that Unix is (more or less) portable. But even if you hate MS-DOS (as do I) you must admit that it has been wildly more successful than all flavors of Unix put together. This is largely because of ... binary compatibility. A software vendor can write a program for the admittedly braindamaged IBM PC architecture, and can be assured that the executable binary will run on over TWO MILLION MACHINES. That's two million potential customers, folks. Now, sure, software vendors *could* just ship sources in shar archives... on 69 different types of media... and let the customers compile it... and maybe it would compile everywhere... and maybe nobody would rip off the source code and resell it... But let's get serious. End users neither want nor need source code, nor compilers, nor shar archives, nor any of that crap. They want to buy a little black biscuit with bits on it that just plugs into their little 16-bit toaster and does their application, right out of the box, no compilation or customization or messing around required. You need to have a single (or at least a dominant) binary data and media standard because dealers and distributors cannot afford to stock 69 different versions of each product. (Hell, they can't afford to stock even *one* version of the low-volume products.) There is a large retail PC industry out there, ignored by most Unix-oids, which dwarfs the Unix industry in total dollars. It's about time the Unix vendors realized it was in their collective interest to create binary compatibility, at least for Unix versions running on identical architectures. There's no good reason, for instance, that Xenix, Venix, and PC/IX couldn't use the *same* register conventions and *same* a.out (x.out) formats and the *same* system call numbers. It'd be a (small) step in the right direction. Yes, I prefer Unix. But I also prefer large quantities of money to smaller ones. That's why I develop software for the IBM PC. I just wish the Unix market could develop into one in which money could be made. But until the Unix "industry" (I use the word loosely) decides to start acting like a business, with economic goals that include making the technical concessions necessary to sell systems to real live end users... the money will continue to be made in PC-land. -- Larry Campbell decvax!genrad The Boston Software Works, Inc. \ 120 Fulton St. seismo!harvard!wjh12!maynard!campbell Boston MA 02109 / / ihnp4 cbosgd ARPA: maynard.UUCP:campbell@harvard.ARPA
sdyer@bbncc5.UUCP (Steve Dyer) (10/23/85)
I'm afraid that all the folks who are meta-flaming at Bill Gates'
comments regarding binary compatibility in Chuck Forsberg's
original message are really missing the point.
Face it: the software world operates on the distribution of binary images.
Source is either non-existent or extremely expensive. It matters a LOT
to software developers that they might need a different binary distribution
for XENIX 86, PC/IX, VENIX, etc., even though they all support a single
microprocessor family. One of the "strengths" of MSDOS is that the same
binary image runs on all sorts of machines which hew to a certain standard.
But, at this point in time, microprocessor-based UNIX systems are fragmented,
with no standards for system call numbering or invocation, no standard for
a.out format and loading, and so on. Naturally, using 286 extensions would
be incompatible with the 8086, but there is no reason why all 286 UNIX systems
could not be binary compatible (with backwards compatibility for small-model
binaries.)
Of course, this is only meaningful within a microprocessor family like the
80x86 or 680x0, but it is nonetheless important. Good software development
requires the existence of a "critical mass"; a certain market size which can
guarantee returns on one's time and money. One larger homogeneous market
(i.e. all 8086 and 80286 UNIX systems) is far preferable to having to approach
a fragmented collection of smaller markets which might not be worth supporting.
--
/Steve Dyer
{harvard,seismo}!bbnccv!bbncc5!sdyer
sdyer@bbncc5.ARPAbtb@mtuxo.UUCP (Bruce Burger) (10/23/85)
> Anyone worrying about binary compatability for UNIX programs has > totally missed the point. What is the point? I think the point here is that a given machine cannot sell well to the mass market until retail stores carry software for it. Retail stores will invest in software inventory ONLY if they know there is a large base of hardware to support it. Since commercial software is sold in binary form, binary compatibility is important. Other types of compatibility are important for other reasons -- but for retail success, you need binary compatibility. --Bruce Burger
andrew@amdahl.UUCP (Andrew Sharpe) (10/24/85)
Keywords:
{}
Uh, excuse me, but Mr. Forsberg neglected the *approved* version
of UNIX System V/286; the one that has passed port acceptance.
This is kind of annoying, because I spent 1 and 1/2 years of
my life trying to do a decent, working, robust version of
the UNIX operating system for the 80286, with all of its
limitations, and, ahem, features.
--
Andrew Sharpe ...!{ihnp4,cbosgd,hplabs}!amdahl!andrew
***************************************** ___________
* The views expressed above are solely * ,/| _____ |
* my cat's opinions, and do not reflect * | | |___ /| |
* the views of the employees, nor the * | | | | | |
* management, of Amdahl Corporation. * | | | | | |
* * | | |__| | |
* * | | / | | ,|
* * | ~~~~~ |/
***************************************** ~~~~~~~~~~~rcd@opus.UUCP (Dick Dunn) (10/24/85)
> Now that we have at least four announced versions of SYS V Unix for the > 80286 (Xenix, PC-IX, Venix, and the 6300+ OSmerge), I would like to > know if these systems are compatible at the binary program level that > Bill Gates has declared imperative for commerical success. A couple of esteemed contributors to this group have opined that binary compatibility is not that important and have also speculated on the topological relationship between Bill Gates' head and other bodily orifices. I agree with the former and have insufficient information to make a reasonable guess on the latter. HOWEVER, that warn't the question, guys! Two specific points: Given the shameless piece of marketing tripe/hype--the infamous "tricycle" ad blasting the 68020 (carefully blasting the competition instead of saying anything substantive about the product being touted, an 80?86), one of the points was that there are many versions of UNIX for the 680[12]0. Of course that's no really big deal, but I think that after that ad it would be a real grin if the 80?86 UNIXes were NOT object-compatible, and I for one would like to rub it in a little for the Intel weenies. There is a substantial market in the low end for binary versions of software--where the stuff is distributed on tiny floppies, etc. We may not be interested in that end of the business but others are. Leave Bill Gates to contemplate his whatever--but what IS the answer on compatibility among the 86 systems? -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...At last it's the real thing...or close enough to pretend.
mike@hcradm.UUCP (Mike Tilson) (10/24/85)
Several people have responded to the issue of binary compatibility by
arguing that it is nearly irrelevant -- the only way to move from
one architecture to another is by source level compatibility, and once
you have it you aren't stuck with the 80286 when you need something
else. I agree this is a key point.
However, I think the issue is more complex, and there is some truth to
what Bill Gates says. The popularity of UNIX will depend increasingly
on the amount of application software that is readily available.
To an end user, "available" means that one can send in an order for
program "X" to run on machine "Y", and have the tape or disk sent back
promptly. If the answer to the request is "Sorry, we haven't ported to
machine Y yet", then for that user the software is not available, even
if program X runs on "UNIX".
Distribution in source code form is not the answer for commercial software.
One could imagine software vendors who sell source code only, but this
is not practical for most vendors. Software is already easy to steal,
and unlimited distribution of source code is almost a license to steal
(it certainly requires a much larger policing effort.) Most software
vendors make their living selling binary copies, with only the occasional
source code sale. If the software could be protected, most would be
happy to sell source only, but it can't and they don't. There are technical
problems as well -- you want to sell a program that you *know* will run.
If you haven't actually compiled it on the target machine, you don't
know what compiler bugs you might hit, etc. (Note: Please no flames about
the moral wrongness of binary code. In our economic and legal system,
binary code will continue to be the norm, even if some think it wrong.)
Therefore vendors sell binary code. As a software vendor, we at HCR
find the multiplicity of machines to be a real pain. We can live with
the fact that you must make a 68000 version and a VAX version of a
program, but it is very costly to make 10 different 68000 versions.
A binary standard would eliminate needless duplication of effort. As
software companies go, we are fairly big (60 people using almost
$1,000,000 worth of computer equipment) but we can't afford to deal
with all of these formats. Therefore we are targeting our new products
to a few "winner" machines. These machines may not be the best cost
performers, but they have the largest sales because they are sold by
the largest companies. If there were a binary standard, we and other
vendors could sell to more markets, but more importantly, end users
would have a much wider choice.
The biggest advantage of the IBM PC is that a user can go to a store
and buy thousands of programs from big and small companies. These programs
are *cheap*, because of the volume market and competition. Binary standards
for UNIX program portability would help to create a volume UNIX market,
which would give us all a better selection of software at lower prices,
and would increase the general acceptance of UNIX. While there is no
fundamental technical obstacle to this, I don't believe it will happen
for a few years, because there are a lot of sticky little problems. But
it would be nice to get rid of yet another *unnecessary* difference between
machines, so we can focus more on the real differences.
/ Michael Tilson
/ Human Computing Resources Corp.
/ {utzoo,decvax...}!hcr!hcradm!mikegwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/24/85)
> Everyone seems to be missing the point here.
No, we're not. Those of us who think of UNIX as an
operating system and not as a marketplace appreciate
its freedom from machine architectural constraints.
Source-level portability, which is the best that can
be achieved across all UNIX implementations, does not
imply that a software house has to ship sources to
customers. More likely, the software house merely
needs to compile their sources into the appropriate
binary for the target machine and ship off the binary.
This need not even imply running the particular target
systems; cross-targeted software generation systems can
be used. I routinely compile code for my DMD on a host
with a totally different architecture.
There is no more reason to insist on binary standards
for the mass market than there is to insist that all
ball-point pen refills be interchangeable. Multiple
brands can coexist, and the ones that prove popular
will receive wide support. I think this is known as
the free market principle.gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/24/85)
> Leave Bill Gates to contemplate his whatever--but what IS the answer on > compatibility among the 86 systems? Who cares? Let the people who are pushing this ridiculous architecture worry about marketing it. The rest of us should get on with improving the UNIX environment and not be bound by 80*86 marketing problems.
sdyer@bbncc5.UUCP (Steve Dyer) (10/24/85)
> No, we're not. Those of us who think of UNIX as an > operating system and not as a marketplace appreciate > its freedom from machine architectural constraints. Blather, blather. Can we please discuss some issues based on facts rather than this kind of irrelevant knee-jerk rubbish? The particular problem here does not concern itself with constraints imposed by a machine architecture; rather we're discussing the often needlessly arbitrary software interface architectures chosen for implementations of UNIX on the same machine architecture. It's hard to discount the problems which have been mentioned so far, unless one chooses to ignore the problem entirely, as Mr. Gwyn does. I wonder why he chooses to comment at all? > This need not even imply running the particular target > systems; cross-targeted software generation systems can > be used. I routinely compile code for my DMD on a host > with a totally different architecture. Yeah, and where do you test it? :-) (Seeing that you're from the Ballistic Research Lab, maybe I'd better remove that smiley-face!) It's hard to ignore the fact that different test environments are needed for different versions of UNIX, even those which are based on the same chip. One might not compile a system on the target, but it needs to be tested on the target if it is to be considered a professional package. In a sense, this underscores the point that binary compatibility isn't a panacea by any means. But the benefits mentioned before (packaging, economies of scale, source and binary control, convenience of development) still hold. -- /Steve Dyer {harvard,seismo}!bbnccv!bbncc5!sdyer sdyer@bbncc5.ARPA
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/25/85)
It's truly amazing how people can extract more from my words than even I thought were there. I am glad to find out that I don't believe software should be tested before being sold to customers, etc. I hadn't realized I had these strange notions.. Back to the original subject: To get full executable binary interchangeability across different implementations of UNIX, you need: (1) identical instruction set architecture, including floating- point if it is used (this can be a real problem if the micro chip vendor provides a deficient FPU) (2) identical object file format, which constrains what one is able to do about such important system features as virtual memory, shared libraries, dynamic linking, checkpointing, multiple languages, software release control, etc. (3) identical system call interface, which constrains extensions, version updates, etc. (4) compatible virtual address space layouts (5) standard set of system utilities for use within applications Bill Gates's simplistic solution is for everyone to adopt Xenix, no more and no less. This is detrimental to the development of better systems! Standardization need not imply severe obstacles to progress, if done right. But just grabbing one particular implementation and requiring its use is not doing it right. As to the mass market, as I have pointed out there is no need for a single binary format even for a given chip set; there is ample precedent for variety in the marketplace, and in general it leads to better products being developed as a result of competition. As to UNIX's "success": UNIX has already been spectacularly successful, whether anyone has made a buck on it or not. There are other criteria of success than financial. Personally, I think that Thompson, Ritchie, et. al. and the organization that supported their work deserve to profit from it, but those who do little more than just resell what they developed don't get much sympathy from me when they complain that they're not getting as filthy rich as they want to be.
timothym@tekigm.UUCP (Timothy D Margeson) (10/25/85)
Hi, FLAME ON Now about this Unix source compatibility issue. Which Unix version, which hardware, and which code are you talking about? I have not seen anything that demonstrates any form of compatibility between any of the Unix' available. You have so many various forms and versions of the ne'rdowell 'operating system' (I use the term loosely) that source written for one can not be expected to run on any other system. A major cause problem of this phenomenon is to make useful software you must take advantage of certain hardware particulars. Or you use a certain program compiler, again making use of machine specific (or worse yet, os version specific) routines, which again limits portability. Unix is too big and widespread to ever become a reasonable, compatible, portable enviroment for users of personal computers. The phalacy that Unix and C make things portable makes me sick whenever I hear or read someone tauting. The software writer is what makes programs portable, nothing else can. Flame off. -- Tim Margeson (206)253-5240 tektronix!tekigm!timothym @@ 'Who said that?' PO Box 3500 d/s C1-465 Vancouver, WA. 98665
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/26/85)
> Uh, excuse me, but Mr. Forsberg neglected the *approved* version > of UNIX System V/286; the one that has passed port acceptance. See, that's the problem with trying to establish binary standards: who sets the standard? In this case, the only two logical choices are AT&T and Intel, and in spite of AT&T's efforts, the package vendors did their own thing(s). I don't know all the details, but I suspect the AT&T system used COFF and the Xenix system used Microsoft's proposed object file format; the two are of course different. (Incidentally, after working with COFF for a while, I found it to be insufficiently portable. I haven't evaluated Microsoft's proposal.) And common object file format is only a small part of establishing binary compatibility.
marcum@sun.uucp (Alan Marcum) (10/28/85)
In article <602@tekigm.UUCP> timothym@tekigm.UUCP (Timothy D Margeson) writes: >FLAME ON > >Now about this Unix source compatibility issue.... >I have not seen anything that demonstrates any form of compatibility between >any of the Unix' available. >-- >Tim Margeson (206)253-5240 >tektronix!tekigm!timothym @@ 'Who said that?' May I submit Larry Wall's 'rn' as a shining example of compatibility? The installation script and the architecture are fine pieces of work. (Note that nobody said it would be EASY -- just, perhaps, worth it.) -- Alan M. Marcum Sun Microsystems, Technical Consulting ...!{dual,ihnp4}!sun!nescorna!marcum Mountain View, California
henry@utzoo.UUCP (Henry Spencer) (10/29/85)
> Now about this Unix source compatibility issue. Which Unix version, which > hardware, and which code are you talking about? > > I have not seen anything that demonstrates any form of compatibility between > any of the Unix' available. You have so many various forms and versions of > the ne'rdowell 'operating system' (I use the term loosely) that source written > for one can not be expected to run on any other system. > > A major cause problem of this phenomenon is to make useful software you must > take advantage of certain hardware particulars. Or you use a certain program > compiler, again making use of machine specific (or worse yet, os version > specific) routines, which again limits portability. How strange. We routinely move substantial chunks of software between PDP11s, VAXen, 370s, Suns, various 68000 and 32000 boxes, etc. Running quite different variants of Unix, too. How curious that we never realized we were doing the impossible. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
fred@mot.UUCP (Fred Christiansen) (10/29/85)
> Anyone worrying about binary compatability for UNIX programs has > totally missed the point. > > Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU Another reader/submitter alternatively suggested that System V, to be a standard, had to address binary compatibility. OK, here's my comment: I believe AT&T have publicly stated that UN*X System V is, at present, a source level standard. Without questions, a source level standard is very important to developers/programmers. Moreover, without this, a binary standard is very difficult (but not impossible) to create. So, src lvl std comes first. Binary compatibility is not to be sniffed at. See the IBM and compatibles PC S/W market -- gobs of off-the-shelf stuff. Unfortunately, the history and nature of the beast make Un*x binary compatibility much trickier. /usr/group, at least temporarily, abandoned its attempts, and P1003 is also putting this off. -- << Generic disclaimer >> Fred Christiansen ("Canajun, eh?") @ Motorola Microsystems, Tempe, AZ UUCP: {seismo!terak, trwrb!flkvax, utzoo!mnetor, ihnp4!btlunix}!mot!fred ARPA: oakhill!mot!fred@ut-sally.ARPA Telephone: +1 602-438-3472
rer@vaximile.UUCP (R.RICHARDSON) (10/30/85)
> Now about this Unix source compatibility issue. Which Unix version, which > hardware, and which code are you talking about? > > I have not seen anything that demonstrates any form of compatibility between > any of the Unix' available. You have so many various forms and versions of > the ne'rdowell 'operating system' (I use the term loosely) that source written > for one can not be expected to run on any other system. > > A major cause problem of this phenomenon is to make useful software you must > take advantage of certain hardware particulars. Or you use a certain program > compiler, again making use of machine specific (or worse yet, os version > specific) routines, which again limits portability. In my experience, about 50% of the code I've run into ports to *any* UNIX on *any* box with no changes. Another 40% ports after adjusting makefiles and/or code to correct for BSD/USG specific calls, usually the tty driver stuff. And 10% ports after correcting stuff that was written unportably to begin with; it would have been unportable on *any* OS, in *any* language, on *any* box. From where I sit, the biggest win for portability would be for the BSD tty driver to disappear. Or maybe someone should write a compatibility package "ioctl" that traps and translates BSD tty ioctl's. Rick Richardson, ..!houxm!vaximile!rer
fred@mot.UUCP (Fred Christiansen) (10/30/85)
> Uh, excuse me, but Mr. Forsberg neglected the *approved* version > of UNIX System V/286; the one that has passed port acceptance. UN*X System V/286 seems to have disappeared from AT&T's catalog. see the latest issue of $echo. anyone know what happened? right now, only Motorola (at Rel 1) and National (at Rel 2.2) are listed as certified. -- << Generic disclaimer >> Fred Christiansen ("Canajun, eh?") @ Motorola Microsystems, Tempe, AZ UUCP: {seismo!terak, trwrb!flkvax, utzoo!mnetor, ihnp4!btlunix}!mot!fred ARPA: oakhill!mot!fred@ut-sally.ARPA Telephone: +1 602-438-3472
caf@omen.UUCP (Chuck Forsberg WA7KGX) (10/31/85)
In article <2943@sun.uucp> marcum@sun.UUCP (Alan Marcum) writes: >May I submit Larry Wall's 'rn' as a shining example of compatibility? >The installation script and the architecture are fine pieces of work. >(Note that nobody said it would be EASY -- just, perhaps, worth it.) You may submit "rn" when the Microsoft large model C compiler works well enough to compile it without spills, core dumps, or various forms of cooky behavior. On the AT, rn must be compiled with the small model, and rn runs out of memory and abends once or twoce per session, even with most of the newsgroups cut off upstream of here. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Home of Professional-YAM, the most powerful COMM program for the IBM PC Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
tuba@ur-tut.UUCP (Jon Krueger) (11/01/85)
In article <2143@amdahl.UUCP> andrew@amdahl.UUCP (Andrew Sharpe) writes: >Uh, excuse me, but Mr. Forsberg neglected the *approved* version >of UNIX System V/286; the one that has passed port acceptance. I've always wondered what "approved" and "port acceptance" mean in practice. Suppose Alan writes code, Bill ports it to new hardware, Alan "approves" the port, Bill sells the ported code to Charlie, and Charlie discovers some behavior of B's ported code that differs from the behavior of Alan's original code. Is Alan obliged to fix Bill's code to Charlie's satisfaction? If Bill advertises Alan has "approved" his port, is Charlie entitled to Alan's support as well as Bill's? -- -- Jon Krueger UUCP: ...seismo!rochester!ur-tut!tuba BITNET: TUBA@UORDBV USMAIL: University of Rochester Taylor Hall Rocheseter, NY 14627 (716) 275-2811 "A Vote for Barry is a Vote for Fun"
andrew@amdahl.UUCP (Andrew Sharpe) (11/05/85)
Keywords:
There was a point about what *approved*, and *port acceptance* mean
in practice. The major issue is that you may call something UNIX
(and advertise it as such) if it has Bell's blessing. Otherwise,
the name must not be UNIX ( such as Xenix, Venix, Ultrix, etc. ).
--
Andrew Sharpe ...!{ihnp4,cbosgd,hplabs}!amdahl!andrew
***************************************** ___________
* The views expressed above are solely * ,/| _____ |
* my cat's opinions, and do not reflect * | | |___ /| |
* the views of the employees, nor the * | | | | | |
* management, of Amdahl Corporation. * | | | | | |
* * | | |__| | |
* * | | / | | ,|
* * | ~~~~~ |/
***************************************** ~~~~~~~~~~~