bruceh@pnet06.cts.com (Bruce Henderson) (07/06/88)
It's been 5 or 6 months since Apple introduced A/UX. And
so far the reaction to it has been pretty dead from their
tried and true... the independent 3rd party developer. As a
matter of fact, even their "Blue Chip" vendors are not
porting over. As an A/UX user and a Mac developer of a few
years, I can understand why. So far Apple has yet to
unleash the power of the Mac II's ROMs. Sure, a bunch of
stuff is implemented, and the rest is due "real soon now",
but still, I think A/UX has a long way to go before it has
people loosing their lunches in excitement over this thing.
But let's look in the crystal ball for a moment. The day
will come when Aplle will have Xwindows or NEWS or both up
on A/UX. The real leverage of this system is that it may
one day allow some of the better software packages in the
industry to migrate to the workstation evironment. How?
well on that magic day when all of the Mac II's ROMs are
availabe to an A/UX compiler [either apple's c that is
supplied with A/UX or a 3rd party Pascal] and Developers are
able to compile original source code with little or no
modification, then watch out! From that point calls to the
diffrent "look and feel" routines can be swapped out to UNIX
portable calls and a portable product can be created. I
know that is sounds kind of far fetched, but it is what we
intend to do with our next product for the Mac II, the
development of which Kicks off next week.
So, yes A/UX needs a lot of polish, and a lot more in
the function department. But HEY! it has the best UNIX
manuals of any I've ever seen!
Bruce Henderson
asm...
[for you non MPW types, thats assembly commando]
[pnet06]
UUCP: hodge.cts.com!pnet06!bruceh
ARPA: hodge!pnet06!bruceh@crash nosc.mil
INET: bruceh@pnet06.cts.comkorn@eris.berkeley.edu (Peter "Arrgh" Korn) (07/07/88)
In <266@hodge.UUCP>, bruceh@pnet06.cts.com (Bruce Henderson) said: >... > But let's look in the crystal ball for a moment. The day >will come when Aplle will have Xwindows or NEWS or both up >on A/UX. Actually Bruce, NeWS already runs under A/UX. It's been running under A/UX for several months now, and it's in it's second or third release at this point. If you are interested in playing with it now (and not tomorrow), contact: The Grasshopper Group 212 Clayton St. San Francisco CA 94117 (415) 668-5998 Peter "I don't even run A/UX" Korn -- Peter "Arrgh" Korn korn@ucbvax.Berkeley.EDU {decvax,hplabs,sdcsvax,ulysses,usenix}!ucbvax!korn
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/07/88)
In article <266@hodge.UUCP> bruceh@pnet06.cts.com (Bruce Henderson) writes: > >...Sure, a bunch of >stuff is implemented, and the rest is due "real soon now", >but still, I think A/UX has a long way to go before it has >people loosing their lunches in excitement over this thing. > > But let's look in the crystal ball for a moment. The day >will come when Apple will have Xwindows or NEWS or both up >on A/UX... First of all, let me say that I really don't know much about this subject, but I have tried to run some Macintosh applications under A/UX, and I have briefly scanned the A/UX programmer's manual on the ToolBox stuff. I have, however, memorized significant portions of Inside Macintosh, and thereby permanently ruined perfectly good storage media (can brain cells be erased and reused, like RAM?) If I say anything stupid, please don't hesitate to tell me. The impression I get from the programmer's manual is that "correctly written" Macintosh applications WILL RUN under A/UX, with the toolboxdaemon or whatever it's called providing an environment similar to what exists on a stock Macintosh. Significant exceptions are that the processor runs in 32-bit mode and that UNIX system calls are available. In other words, if your application doesn't do anything screwy with the high bits of addresses, then it should work under A/UX. We're talking binary compatibility here, and everything I have read or heard about A/UX implies that this exists, or will exist "real soon now." When I first heard of A/UX, I envisioned that "everything" would work. Like, if I wanted Tektronix 4105 emulation I could run VersaTerm PRO using the printer port, hook up a null modem cable from the printer port to the modem port, log in on a ptty, start up my plot program, and go! Or if you want to send your mother a birthday card, simply run a color paint program, draw the thing, then print it on your color ImageWriter which is connected to the printer port and which you have selected using the Chooser. Instead, it appears that hardly anything works as expected, and that many crucial features of the User Interface are missing when running under A/UX. For instance "The User changes the screen depth using the Control Panel." I believe desk accessories are needed for this operation; need I say more? All this is understandable, but it does fall far short of what the naive Macintosh user would be led to expect by "run ordinary Macintosh applications under A/UX." Personally, and let me stress that this is only opinion, I don't think that UNIX window systems like X and so forth are the solution. These tend to be slower than the Macintosh graphics interface in my experience, AND they are portable and hence programs written for them do not take specific advantage of Macintosh features. A Mac II running X is not a significantly different machine from an IBM RT running X, except that the UNIX emulation on the IBM is better, and f77 works on the RT. A Mac II running A/UX and fully supporting the Macintosh ToolBox would be a wonder to behold, especially when you log in to the console and get MultiFinder as your "shell." A simple set of tools to convert the data forks of Macintosh files to UNIX data or text files, and the picture is almost complete. In my opinion, the burden is not upon Macintosh developers to become compatible with A/UX, and to read/write UNIX data files when A/UX is present, for instance. Rather, the burden is upon Apple to make the A/UX ToolBox emulation look like the same old ToolBox to any application which tries to run under it. This includes the presence of commonly-used device drivers like ".Print" and ".MPP" and so forth. I don't see why a PBOpen request for ".Print" cannot be sent to the kernel and translated into a request for the appropriate 'DRVR' and serial port to be invoked. It includes UNIX tools that can extract 'TEXT' out of the ".clipboard" file and paste it into UNIX files, converting linefeeds along the way. Apple also has to make sure that if I compile and link a program on a Mac Plus using MPW and following the instructions in Inside Macintosh, that that program will run without modification on a Mac II under A/UX. It would be nice, of course, if programs compiled with other development systems worked also. In fact, is it too much to ask to be able to run MPW Shell under A/UX? This is the kind of stuff that will make the Mac II running A/UX a marvel to see, and not just another ho hum UNIX box that can run "portable" C programs. It would be nice also if Apple were to use "compatibility" arguments with discretion, until they are really sure that their ToolBox emulation is complete. What is the problem here? Is the task of emulating the ToolBox and Mac OS, on a machine which already has most of the ToolBox and OS already in ROM, too difficult? Have the Mac OS boys made the internal workings of the ToolBox so contorted and obscure that not even Apple's own A/UX team can get into it? I hope not. I really would like to see a convincing ToolBox which can run Macintosh applications on a UNIX machine. Earle Horton