Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!osu-eddie!elwell%tut.cis.ohio-state.edu From: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP Newsgroups: comp.sys.mac Subject: Re: Mac software under A/UX Message-ID: <3895@osu-eddie.UUCP> Date: Sun, 2-Aug-87 01:37:18 EDT Article-I.D.: osu-eddi.3895 Posted: Sun Aug 2 01:37:18 1987 Date-Received: Sun, 2-Aug-87 11:19:00 EDT References: <2599@hoptoad.uucp> Sender: news@osu-eddie.UUCP Reply-To: elwell%tut.cis.ohio-state.edu@osu-eddie.UUCP (Clayton Elwell) Organization: The Ohio State University, CIS Dept. Lines: 95 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