jww@sdcsvax.UUCP (08/01/87)
I'm not an expert, nor an official representative of anyone. I've read a few manuals and thus know enough to be dangerous. :-) In article <2599@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > I had been proceeding under the false assumption that A/UX was constructed > on top of the Mac OSments here have alluded vaguely to an "A/UX Toolbox" > which wouold seem to be a re-implementation of the Mac OS on top of A/UX. The A/UX Toolbox is that portion of the Macintosh Toolbox and OS available under A/UX. Some of it is in the good ol' ROM where it belongs. A little is emulated on top of A/UX via glue. The former includes QuickDraw, the latter the so-called 'high-level' File Manager calls. > > (1) Will existing Macintosh application files run under A/UX, provided they > adhere to the compatibility guidelines? Not yet. So far, the guidelines would exclude anything useful (e.g., no printing). I believe the goal is to make this true. > (2) If not, will MPW C applications compile successfully under A/UX with > only makefile changes provided they do no direct hardware accesses and > otherwise conform to compatibility guidelines? There are some minor differences between the compilers (even though both are originally from Green Hills) but again, I believe the goal is yes. > (3) Will the full Macintosh file system, down to obscure but important > details like the blessed folder, and most emphatically including volume ids, > directory ids, resource forks and finder information, be supported by A/UX? I can't speak for the blasted folder :-), but the current emulation includes volume id's (like HFS, there's one for each directory, but the assignment is not permanent), no directory or other HFS calls yet. Finder information is stored in the resource fork, a file of suffix .res. The fact that System V truncates names to 14 characters makes the latter somewhat impractical in practice. > (4) [Not of as general concern] Will A/UX come complete with Appletalk and > Internet protocols and applications? If so, which ones, and what kind of TCP/IP and NFS are standard, I believe, but Sun hasn't donated me a machine to prove it and I can't afford to buy one on my own. :-) > (5) Will Macintosh desk accessories and drivers still be supported? Will > they have to be recoded and/or recompiled even if they fit the compatibility > guidelines? I would not put my life's savings into da's for A/UX. I would not even put my in-law's savings into having Macintosh drivers run under UNIX. Do you know what you're asking? Can VMS drivers run under UNIX? Can MS-DOS? If they could, at an obviously abysmal performance, would it be worth it? > (6) A/UX vs. multi-tasking. I dunno. > > (7) What happens to the System Heap on a multitasking, memory-managed "A/UX > Toolbox" environment? Will Mac applications be prevented from corrupting > each others' data the way UNIX applications are? Memory management on A/UX? Can you say 'malloc'? NewHandle calls malloc. There is no system heap, as far as I can tell. As for memory management, I assume that's why it comes with a Motorola MC 68851 PMMU: protection and virtual memory. -- Joel West, (c/o UCSD) Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083 {ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edu
elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (08/02/87)
The information in this article is based on my direct experience with the Mac II in my office running A/UX. Apple has just issued a major upgrade to beta sites, so I may discover improvements when we get our disk back... Note that this contains no marketing hype :-)... In article <2599@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >Specifically, my questions are these. > >(1) Will existing Macintosh application files run under A/UX, provided they >adhere to the compatibility guidelines? As Isaac Newton said, "Pretty Nearly." This does bring a whole new order of meaning to adhering to the guidelines, though. Fullpaint, for example, works with a couple patched bytes in the help window handler (peeking at the upper bits in a handle is a no-no). MacWrite is hopeless (not suprisingly). MacDraw 1.9 almost works, but gets a little confused after a while. I haven't tride 1.9.5 yet. The A/UX toolbox beta docs do give a list of things that you can't "get away with" any more. The biggest problem is that the memory manager is now 32-bit based instead of 24-bits-plus-flags based. >(2) If not, will MPW C applications compile successfully under A/UX with >only makefile changes provided they do no direct hardware accesses and >otherwise conform to compatibility guidelines? All the ones I've tried have worked fine. You can also write programs that use both Mac and Unix facilities (talk about unportable, though). >(3) Will the full Macintosh file system, down to obscure but important >details like the blessed folder, and most emphatically including volume ids, >directory ids, resource forks and finder information, be supported by A/UX? If you ignore the man behind the curtain. It pretends that the entire UNIX directory hierarchy is one big happy volume, and makes up directory IDs on the fly. This works surprisingly well. Since this is all user code, you could in principle write your own version of the file manager routines that emulate whatever you want. The resource manager works fine, and the finder info is stored. resource forks are currently stored as "filename.res," but this may change, as I understand. >(4) [Not of as general concern] Will A/UX come complete with Appletalk and >Internet protocols and applications? If so, which ones, and what kind of >protocol support will be offered? Will Unisoft's standard NFS be included? It has complete Berkeley networking and NFS. The docs describe the AppleTalk stuff, but Unix has this problem with high-speed serial I/O... Raw sockets are now supported, and I intend to get our machine talking to a Kinetics box and our Pyramid via the Ethernet board, to allow printing to AppleTalk printers and the like. >(5) Will Macintosh desk accessories and drivers still be supported? Will >they have to be recoded and/or recompiled even if they fit the compatibility >guidelines? They don't work now, but who knows? DAs that don't "write to the metal" might be possible. The Vertical Retrace Manager is a major problem, but there may be ways to fake it well enough for most DAs. Drivers are probably right out, since they like to do physical I/O. >(6) What is the relationship between A/UX and any possible multitasking Mac >OS which Apple might release? Is the environment significantly different >from a Servant/MPW environment to the user? I'm not sure what you are asking here, but it definitely feels like (because it is) Unix with the ability to do Mac things. >(7) What happens to the System Heap on a multitasking, memory-managed "A/UX >Toolbox" environment? Will Mac applications be prevented from corrupting >each others' data the way UNIX applications are? Mac applications are Unix tasks. There is only 1 heap, and it's part of the process's address space. If the program dies, the worst it will do is core dump, just like a normal Unix program. This is because Mac programs really are run as Unix processes, after having some things set up by a "launch" program (which currently makes sure the screen isn't in use, maps the ROMs and the screen into the virtual address space, sets up the trap dispatcher, etc., and then starts up the program). >If these have already been dealt with here, then please respond by mail; >otherwise, I would doubt that many people know the answers, but these >questions (even the fourth) are clearly of general concern to Mac >developers, so post. >-- >Tim Maroney, {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) >hoptoad!tim@lll-crg (arpa) -=- Clayton Elwell Arpa/CSNet: Elwell@Ohio-State.ARPA UUCP: ...!cbosgd!osu-eddie!elwell Voice: (614) 292-6546