jng@well.sf.ca.us (James N. Gershfield) (03/11/90)
Hello, world. Does anyone know whether the upcoming Release 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX? Is the new A/UX a complete rewrite of A/UX 1.1? What are the major differences between A/UX 1.1 and 2.0? Thanks.
logan@inpnms.UUCP (Jim Logan) (03/13/90)
In article <16611@well.sf.ca.us> jng@well.sf.ca.us (James N. Gershfield) writes:
#
# Hello, world. Does anyone know whether the upcoming Release
# 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX?
#
# Is the new A/UX a complete rewrite of A/UX 1.1?
#
# What are the major differences between A/UX 1.1 and 2.0?
I read an article on A/UX 2.0 recently, and I think we'll be
lucky if it is System V Release 3! It improves on various
things, like Mac OS application support, X window support, among
other things that I don't remember. If anyone has more
information than me, PLEASE POST IT! I will be purchasing A/UX
2.0 for my IIci.
-Jim
--
James Logan UUCP: uunet!inpnms!logan
Data General Telecommunications Inet: logan%inpnms@uunet.uu.net
(301) 590-3198
tjt@lance.tis.llnl.gov (Tim Tessin) (03/13/90)
In article <16611@well.sf.ca.us> jng@well.sf.ca.us (James N. Gershfield) writes: > > Hello, world. Does anyone know whether the upcoming Release > 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX? > Is the new A/UX a complete rewrite of A/UX 1.1? > What are the major differences between A/UX 1.1 and 2.0? Think of AUX 1.1 as a UNIX system with some Mac toolbox stuff thrown in to play with. Think of AUX 2.0 as a Mac OS system which just happens to run UNIX underneath. Almost any properly written MAC program should run. Hacks like hfx are no longer needed. Lots of on-line help, etc. The point of all this is to look just like a MacOS and never have to know you are running UNIX [I'm not sure I like it, but then, I'm an old UNIX hack]. Clearly meets the goals of being able to shove a UNIX system on an old MAC'er with minimum frustration. I don't know the heritage of the UNIX port other than what is already known about AUX 1.1. Tim Tessin tjt@lance.tis.llnl.gov
mahesh@ndcvb.cc.nd.edu (Mahesh Subramanya) (03/13/90)
In article <729@ncis.tis.llnl.gov>, tjt@lance.tis.llnl.gov (Tim Tessin) writes: > In article <16611@well.sf.ca.us> jng@well.sf.ca.us (James N. Gershfield) writes: > > > > Hello, world. Does anyone know whether the upcoming Release > > 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX? > > Is the new A/UX a complete rewrite of A/UX 1.1? > > What are the major differences between A/UX 1.1 and 2.0? > > Think of AUX 1.1 as a UNIX system with some Mac toolbox stuff thrown in > to play with. > > Think of AUX 2.0 as a Mac OS system which just happens to run UNIX underneath. > Almost any properly written MAC program should run. Which is great, but imagine having a couple of windows open, and also getting a modal box saying, in inimtable MAC fashion SYSTEM ABOUT TO CRASH CATASTROHICALLY, TOTALLY TRASHING YOUR DISK OK? and leaving you *NO* other choice than to click on OK!!!! Could happen y'know Mahesh Subramanya Office of Univ. Comp. Univ. of Notre Dame Notre Dame, IN 46556 #WOW!!! ITS GOT A MOUSE!!!
cander@unisoft.UUCP (Charles Anderson) (03/14/90)
From article <239@inpnms.UUCP>, by logan@inpnms.UUCP (Jim Logan): > In article <16611@well.sf.ca.us> jng@well.sf.ca.us (James N. Gershfield) writes: > # Hello, world. Does anyone know whether the upcoming Release > # 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX? > # Is the new A/UX a complete rewrite of A/UX 1.1? > # What are the major differences between A/UX 1.1 and 2.0? > > I read an article on A/UX 2.0 recently, and I think we'll be > lucky if it is System V Release 3! It improves on various > things, like Mac OS application support, X window support, among > other things that I don't remember. If anyone has more > information than me, PLEASE POST IT! I will be purchasing A/UX > 2.0 for my IIci. Acording to MacGeek, A/UX 2.0 will support additional MacOS features such as the Sound Manager, 32-bit QuickDraw, AppleTalk 2.0, AppleShare client and the high density floppy. There will be a new Finder program which will be able to copy, rename, delete, move, and launch files, so the current hfx utility will not be needed. The finder will support old, 24-bit applications and MultiFinder-style multi-tasking. In terms of real Unix features, they are supporting the BSD Fast File System (UFS), 3.2 NFS and shared libraries. Shared libraries should be a real win for X applications, since you only need one copy of the X libraries in memory, instead of one copy for each unique application that's running. As for newer, "standard" Unix support (i.e., OSF or SVR4), I do not believe Apple has made any public comment about endorsing either operating system. The fact that they the MacWeek article (based on stuff from Apple) does not mention such features as /proc filesystem (see ksh man page), RFS, SunOS VM code, etc suggests that they are not supporting SVR4, at this time. There is an implemention of SVR4 on the Mac which has been publicly seen at Unix Expo in November and UniForum in February, but it has NO relationship to A/UX and is not available as a commercial product. Charles. {sun, ucbvax, pyramid, uunet}!unisoft!cander
gday@digigw.lab.digital.co.jp (Gordon Day) (03/16/90)
In article <729@ncis.tis.llnl.gov>, tjt@lance.tis.llnl.gov (Tim Tessin) writes: > In article <16611@well.sf.ca.us> jng@well.sf.ca.us (James N. Gershfield) writes: > > > > Hello, world. Does anyone know whether the upcoming Release > > 2.0 of A/UX will be compatible with AT&T System V Release 4 UNIX? > > Is the new A/UX a complete rewrite of A/UX 1.1? > > What are the major differences between A/UX 1.1 and 2.0? > Think of AUX 2.0 as a Mac OS system which just happens to run UNIX underneath. > Almost any properly written MAC program should run. > The point of all this is to look just like a MacOS > and never have to know you are running UNIX [I'm not sure I like it, but then, > I don't know the heritage of the UNIX port other than what is already > known about AUX 1.1. > > Tim Tessin > tjt@lance.tis.llnl.gov > I don't know the heritage of the UNIX port other than what is already Perhaps some of you can enlighten me here. I had made the (obviously mistaken) assumption that A/UX was a BSD4.3 derivative. If this is not so, will I be in for a nightmare when I move from SunOS4.0.3 to a Mac running A/UX 2.0? Is the X option available from Apple really just the standard release with yet another TWM lookalike? What are the mechanics of launching a Finder app from the A/UX side? How buggy is the current release, and with the new features, what's the guess on the next release? I plan on running a number of IIci's with X on A/UX together with Sun 4/80s so I would like to mount the A/UX /usr on a Sun server. Will the A/UX side be happy with this? Any comments/answers would be MOST welcome. Gordon W. Day =:! (gday%digital.co.jp@uunetuu.net)
liam@cs.qmw.ac.uk (William Roberts) (03/20/90)
Here's today's announcement, downloaded from AppleLink. I've followed it with the Macintosh IIfx announcement since that is a fairly serious piece of hardware and certainly something on which A/UX should be considered. ------------------ A/UX, Version 2.0 and X Window System Copyright 1990, Apple Computer, Inc. A/UX, Version 2.0 A/UX Version 2.0, available in mid-1990, allows users to work with UNIX through the Macintosh interface and permits simultaneous operation of Macintosh, X Window and UNIX applications. Features: -- Hundreds of existing Macintosh applications run under A/UX. -- Macintosh, UNIX and X Window applications share the Macintosh desktop. -- Text may be cut and pasted among Macintosh, UNIX and X Window applications. -- Macintosh-style startup and shutdown simplifies the process of accessing a UNIX system. -- Access to AppleTalk network resources is available through the Chooser. -- Commando, the UNIX command line builder, runs UNIX utilities using a menu, eliminating the need to memorize strings required to invoke commands. -- A mouse-based text editor facilitates access to UNIX text files. -- Support for 32-bit QuickDraw, provides true color and grayscale capabilities. Compatibility: -- Runs on the Macintosh SE/30 and all of the Macintosh II family computers. The Macintosh II requires a Paged Memory Management Unit (PMMU). -- Supports the new graphics cards and the future graphics coprocessor. Availability: -- Available in mid-1990 on the Macintosh IIfx, IIci and IIcx on a pre-loaded internal 80MB hard disk. -- Also available on Apple tape cartridge, floppy disk, and CD-ROM disk. -- Right-to-Copy and Right-to-Update products will be offered to large institutions. -- User's, Programmer's and Administrator's manual bundles will provide the essential information about A/UX 2.0 and UNIX development tools. X Window System for A/UX 2.0 A new version of X Window system will be available for use with A/UX, Version 2.0 in mid-1990. Two environments are available to the user: MacX and X11. MacX This environment allows X Window, Macintosh and UNIX applications to share the MultiFinder desktop. X client applications may appear on the desktop in their own window, or all X applications may be contained in one window. MacX is configurable and provides access to the X Window System for both experienced and inexperienced X and UNIX users. X11 This environment is the standard Version 11 Release 4 from MIT, with enhanced quality and performance. X11 displays only X client applications without access to the Macintosh desktop or applications. Manuals will accompany X Window System for A/UX to explain the X Window System, Installation and use of MacX and X11. Manuals will also be available separately. Site licensing will be available for customers who meet the conditions described in Apple's site licensing agreement, as well as a Right-To-Copy product. New Product Descriptions New Product Highlights 3/19/90 ------------------ Macintosh IIfx Copyright 1990, Apple Computer, Inc. The new Macintosh IIfx is the fastest Macintosh for all existing Macintosh applications. It offers more power with CAD/CAM, scientific data analysis and visualization, commercial publishing, financial management, multimedia production and artificial intelligence and enables the user to work with interactive 3-D animation and photographic quality image manipulation. Features: - 40Mhz 68030 microprocessor and 68882 floating-point coprocessor. The Macintosh IIfx runs up to 100 percent faster than the Macintosh IIci, and up to 300 percent faster than the Macintosh IIcx and Macintosh IIx computers. - Built-in 32K static RAM (SRAM) cache stores the processor's most frequently used instructions. - dedicated SCSI DMA (Small Computer Systems Interface/Direct Memory Access) channel which reduces the workload of the main processor and speeds performance of the SCSI bus. - dedicated I/O processors increase system efficiency. - six NuBus expansion slots can Accommodate multiple video, communications, networking, and other expansion cards. - Processor Direct Slot (PDS) allows direct access to the system bus. - six built-in ports: two serial ports, two Apple Desktop Bus ports, stereo sound jack, and a DB-25 SCSI interface. - 512K ROM on SIMM includes support for 32-bit QuickDraw and A/UX-supported functions such as: 32-bit addressing and virtual memory, which extends the computer's internal memory by transparently treating the hard disk as though it were RAM. System Software Macintosh operating system version 6.0.5 (shipping with the Macintosh IIfx and available to all users in June 1990) is required for the Macintosh IIfx. Note: Although System 6.0.5 is compatible with all previous Macintosh models, it offers no increased functionality over previous versions. DRAM Memory Upgrades Both 4MB and 8MB DRAM memory expansion kits are now available from Apple for the Macintosh IIfx. Note: In order to provide increased performance, DRAM for the Macintosh IIfx is shipped on 64-pin (rather than 30-pin) DRAM SIMMs (Single In-line Memory Modules). These components have never been used by Apple before. Therefore, you cannot use DRAM from any other system in the Macintosh IIfx, nor can you use Macintosh IIfx DRAM in any other Macintosh system. Parity Support 4MB and 8MB Memory upgrade kits for parity*-based Macintosh IIfx systems are available for ordering now, and will ship in June, 1990. Support for parity has been included in both the Macintosh IIfx and the Macintosh IIci to address the needs of customers (such as those in the federal government and medical industry) who require an added degree of assurance in the handling of critical information. *Note: Parity must be ordered at the time the Macintosh IIfx is ordered; the system cannot be upgraded at a later date to include support for parity. Available Configurations The Macintosh IIfx is available now (3/90) in the following configurations: - Internal 1.4MB SuperDriveM-*, floppy-based system with 4MB RAM - Internal 1.4MB SuperDrive, 80MB internal hard drive with 4MB RAM - Internal 1.4MB SuperDrive, 160MB internal hard drive with 4MB RAM Macintosh IIfx CPU (4MB) Order #M5510LL/A Macintosh IIfx HD 80 CPU (4MB) Order #M5515LL/A Macintosh IIfx HD 160 CPU (4MB) Order #M5520LL/A Macintosh IIfx HD 80 Parity CPU (4MB) (avail. June, 1990) Order #M5524LL/A Macintosh IIfx 4MB Mem. Exp. Kit Order #M0376LL/A Macintosh IIfx 4MB Parity Mem. Exp. Kit (avail. June, 1990) Order #M0377LL/A New Product Descriptions New Product Highlights 3/19/90 ------------------ -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 01-975 5250 (Fax: 01-980 6533)
dwb@archer.apple.com (David W. Berry) (03/20/90)
In article <306@digigw.lab.digital.co.jp> gday@digigw.lab.digital.co.jp (Gordon Day) writes: >Perhaps some of you can enlighten me here. I had made the (obviously mistaken) >assumption that A/UX was a BSD4.3 derivative. If this is not so, will I be in >for a nightmare when I move from SunOS4.0.3 to a Mac running A/UX 2.0? Nope. It's SVR2, plus berkeley enhancements. The enhancements include almost anything you'd want. I've ported a wide variety of programs specifically designed to BSD and had no problems. > >Is the X option available from Apple really just the standard release with yet >another TWM lookalike? There are now two X products available from Apple. MacX a MacOS version that also runs under A/UX and a "native" X port which only runs under A/UX. MacX uses the Macintosh window manager for X windows or can display a "normal" X desktop in a Mac window. > >What are the mechanics of launching a Finder app from the A/UX side? Double click on it, or type it's name on the command line. >I plan on running a number of IIci's with X on A/UX together with Sun 4/80s so >I would like to mount the A/UX /usr on a Sun server. Will the A/UX side be >happy with this? Sure, we do several similar things here.
liam@cs.qmw.ac.uk (William Roberts) (03/20/90)
In article <306@digigw.lab.digital.co.jp> gday@digigw.lab.digital.co.jp (Gordon Day) writes: >In article <729@ncis.tis.llnl.gov>, tjt@lance.tis.llnl.gov (Tim Tessin) writes: >Perhaps some of you can enlighten me here. I had made the (obviously mistaken) >assumption that A/UX was a BSD4.3 derivative. If this is not so, will I be in >for a nightmare when I move from SunOS4.0.3 to a Mac running A/UX 2.0? A/UX 2.0 is still System V at heart, in that it uses inittab rather than just a single /etc/rc script, you have to think about using cpio (though tar is available), rsh means "restricted shell" and not "remote shell". Apart from that it isn't any more of a nightmare than moving from SunOS to other non-Sun machines. >Is the X option available from Apple really just the standard release with yet >another TWM lookalike? YOu could compile the standard release if you really wanted to be sure of what you were getting. MacX is the thing where Apple have done some work on producing a psuedo-rooted system (i.e. the root window is not done with X, and the window manager is provided by the native Mac system). >What are the mechanics of launching a Finder app from the A/UX side? Double click it, or type its name to a shell prompt. > >How buggy is the current release, and with the new features, what's the guess >on the next release? A/UX 1.1.1 is solid though its Mac application support is fairly limited. We've used it for several months with a student lab of 100 machines and had very few panics. Some of the utilities aren't so hot and the C compiler isn't nearly as good as gcc. As for guesses about A/UX 2.0, guess away... >I plan on running a number of IIci's with X on A/UX together with Sun 4/80s so >I would like to mount the A/UX /usr on a Sun server. Will the A/UX side be >happy with this? No problems at all - we did almost exactly this (but with a VAX 11/750) for some while before putting in a IIcx as the server. We made the change because we were still developing our idea of what should be on our standard partitions (which are local to some machines but on NFS for others) and it is much easier to make a block-for-block image than to wipe a filestore and use tar or whatever. Our students do use X11 on the machines if they want to (e.g. for a graphics course or project work) and two of my colleagues use X as their standard window system on their IIcxs - this is the Apple X11R3 and works ok, though 8Meg of memory makes a big difference over our usual 4 Meg configurations (but then everyong says that about X!). We still support all of our student files on 3 Sun 3/50s plus some overflow on a Sequent Balance 21000: this setup creaks a bit and we will be replacing the Sun 3/50s in time for the next academic year. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 01-975 5250 (Fax: 01-980 6533)
urlichs@smurf.sub.org (Matthias Urlichs) (03/21/90)
In comp.unix.aux, article <7264@goofy.Apple.COM>,
dwb@archer.apple.com (David W. Berry) writes:
< Nope. It's SVR2, plus berkeley enhancements. The enhancements
< include almost anything you'd want. I've ported a wide variety
< of programs specifically designed to BSD and had no problems.
<
Why not SVR4?
Does the A/UX kernel finally support the Berkeley FFS, and/or the
#!/usr/bin/whatever convention? Or ar these still the "almost" in the above
"almost anything"?
The above are, to me at least, the two most annoying non-features A/UX has.
Oh yes, I'd also like to have TIOCCONS instead of /dev/osm, please.
(Ever had "tail -f /dev/osm" cause a kernel bus error?)
<
<>What are the mechanics of launching a Finder app from the A/UX side?
< Double click on it, or type it's name on the command line.
Obvious once you're told, I suppose...
Is there a decent Mac-like text editor? Or the functional equivalent to the
MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix,
omitted.)
I suppose you'd need a virtual file system (or something) to handle the
.<paragraph> current-selection feature.
<
<>I plan on running a number of IIci's with X on A/UX together with Sun 4/80s so
<>I would like to mount the A/UX /usr on a Sun server. Will the A/UX side be
<>happy with this?
< Sure, we do several similar things here.
But can you run the Sun binaries on A/UX, and/or vice versa?
(The answer is a very obvious "no", right?)
NB: Sorry if this sounds like more or less unnecessary bickering about a good
product. It is (good, I mean), but it could be better. What couldn't?
--
Matthias Urlichs
chuq@Apple.COM (Chuq Von Rospach) (03/21/90)
urlichs@smurf.sub.org (Matthias Urlichs) writes: >Does the A/UX kernel finally support the Berkeley FFS, and/or the >#!/usr/bin/whatever convention? Yes, and Yes. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] All spirits are enslaved which serve things evil -- Shelley
dwb@archer.apple.com (David W. Berry) (03/21/90)
In article <1990Mar20.181959.16435@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Does the A/UX kernel finally support the Berkeley FFS, and/or the >#!/usr/bin/whatever convention? Or ar these still the "almost" in the above >"almost anything"? >The above are, to me at least, the two most annoying non-features A/UX has. Well, since A/UX 2.0 has now been annoucned (see elsewheres for complete announcements, it's been posted), yes the 2.0 kernel will support both FFS and the #!/usr/bin/whatever convention. > >Oh yes, I'd also like to have TIOCCONS instead of /dev/osm, please. >(Ever had "tail -f /dev/osm" cause a kernel bus error?) Well, there is now a TIOCSETCONS, which probably does just about the same thing. > >Is there a decent Mac-like text editor? Or the functional equivalent to the >MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix, >omitted.) Well, MPW runs with a single patch, and there is a Mac-like text editor as well. > >NB: Sorry if this sounds like more or less unnecessary bickering about a good >product. It is (good, I mean), but it could be better. What couldn't? We're really trying to make it much better. We think that A/UX 2.0 shows Apple's intention to make the best A/UX we can. Not that our ideas of "best" will always agree with yours, but we'll consider anything. >-- >Matthias Urlichs
coolidge@cassius.cs.uiuc.edu (John Coolidge) (03/21/90)
liam@cs.qmw.ac.uk (William Roberts) writes: >gday@digigw.lab.digital.co.jp (Gordon Day) writes: >A/UX 2.0 is still System V at heart, in that it uses inittab >rather than just a single /etc/rc script, you have to think >about using cpio (though tar is available), rsh means >"restricted shell" and not "remote shell". Apart from that it >isn't any more of a nightmare than moving from SunOS to other >non-Sun machines. Actually, it's been much easier than a number of other non SunOS machines I could name. We've got a very heterogeneous lab, and the A/UX machines have been about the easiest to integrate with the Suns (which tend to be the reference standard). Administration-wise, they're a bit different (inittab rather than /etc/rc, etc), but not much of a problem. >>Is the X option available from Apple really just the standard release with >>yet another TWM lookalike? >YOu could compile the standard release if you really wanted to >be sure of what you were getting. MacX is the thing where Apple >have done some work on producing a psuedo-rooted system (i.e. >the root window is not done with X, and the window manager is >provided by the native Mac system). To expand on this a bit: Apple has two X products. X11R{3,4} for A/UX is, basically, just the MIT X product. R3 adds support for color to MIT's R3, but since MIT's R4 is faster than R3 and has color support, there's not much reason to run R3. We're running R4 and doing just fine. MacX, on the other hand, runs under MacOS or the A/UX Finder, and provides a Mac-like interface to X. The normal Mac interface is mapped into a ICCCM compliant window manager, and X windows can be either rooted (in a normal Mac window which functions as a X root window) or rootless, in which case they operate very much like normal Mac windows. >>How buggy is the current release, and with the new features, what's the guess >>on the next release? >A/UX 1.1.1 is solid though its Mac application support is >fairly limited. We've used it for several months with a student >lab of 100 machines and had very few panics. Some of the >utilities aren't so hot and the C compiler isn't nearly as good >as gcc. As for guesses about A/UX 2.0, guess away... The normal 'cc' that comes with A/UX is pretty good iff you only want to compile small to medium programs. It has a few minor problems with some dubious C syntax, but by and large it's pretty solid. The biggest problem is has are fixed-length tables (for symbols, etc), which simply overflow on large programs. However, gcc 1.37 is very solid on A/UX (I've compiled X11R4 and other large programs with it and had no problems). You still have to live with Apple's assembler, though :-( (it produces OK output, but has fixed size tables too and sometimes loses optimizations, and has a _very_ limited symbol space). Gas doesn't provide support for COFF yet... >>I plan on running a number of IIci's with X on A/UX together with Sun 4/80s so >>I would like to mount the A/UX /usr on a Sun server. Will the A/UX side be >>happy with this? >No problems at all - we did almost exactly this (but with a VAX >11/750) for some while before putting in a IIcx as the server. We've got a similar configuration, with /usr/local, /home (our home directories), and optional stuff mounted on foreign machines (all kinds of different machines --- NFS works just fine). The only things that _have_ to be local are swap space and system programs (A/UX can't boot diskless). --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.
rick@Apple.COM (Rick Auricchio) (03/21/90)
In article <1990Mar20.181959.16435@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Why not SVR4? Since we've been working on this for over a year, it would've been tough to find a V.4 tape, yes? > >Does the A/UX kernel finally support the Berkeley FFS, and/or the >#!/usr/bin/whatever convention? Or ar these still the "almost" in the above >"almost anything"? Yes, and yes. > >Oh yes, I'd also like to have TIOCCONS instead of /dev/osm, please. Oh, well. Not yet. >(Ever had "tail -f /dev/osm" cause a kernel bus error?) No. >Is there a decent Mac-like text editor? Or the functional equivalent to the >MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix, >omitted.) Yes, adapted from MPW. Called "textedit". >But can you run the Sun binaries on A/UX, and/or vice versa? >(The answer is a very obvious "no", right?) You're right there. But you already know that wasn't a *real* question, right? Not much binary compatibility among systems. >product. It is (good, I mean), but it could be better. What couldn't? True. I expect to be working for a long time perfecting it. The more we add, the more we understand needs a bit of polish here and there. But 2.0 has to ship, so many of us reluctantly have to forego a bit of polish in favor of getting it to everyone. -- -- Rick Auricchio, Apple Computer Inc, 20525 Mariani Av MS 58A Cupertino CA 95014 sun!apple!rick OR rick@apple.COM Mooney N894AR (408) 974-4227 Never eat prunes when you're famished. My opinion is my own. My employer? They use a windsock and a fire extinguisher.
oberst@phoenix.Princeton.EDU (Daniel J. Oberst) (03/22/90)
Some early reactions of an A/UX 2.0 beta tester: A/UX 2.0, the latest version of Apple's UNIX offering, is what Apple's UNIX should have been all along. When I first installed the software,it appeared that the installation had failed, and I tried to re-launch the installer program--surprise!! A/UX *WAS* installed! Only the Mac Desktop and icons looked and worked so much like MacOS I couldn't superficially tell it was UNIX! Basically, A/UX lives in one Multifinder layer that lets you set up multiple terminal windows from which you can run UNIX (A/UX) applications,moniter UNIX processes, and do other UNIX-y sorts of things (much like the 'term' program from earlier versions plus a console window). In the other layers you run whatever MacOS applications you want. Appletalk works (either over Ethernet or LocalTalk); you can access AppleShare volumes; print to a networked LaserWriter, use Broadcast, or do whatever you would otherwise do in a Mac environment. Your MacOS/Multifinder environment gets a chunk of memory equivalent to your installed RAM. So a 4 MB Mac with A/UX 2.0 gets a 4MB Multifinder environment, and A/UX's memory management keeps it and the MacOS side of the house happy in that space. What's best is that MacOS disks and hard disk volumes are transparently visible to MultiFinder and the Mac applications running under A/UX!! Stick in a floppy and its Mac files can be read. Attach a hard drive with your MacOS files and applications and they become accessable to the system, right on your desktop. (Note, we encountered problems with some non-Apple drives, but we understand that new drivers/disk formatting utilities will take care of this problem). Tired of waiting for a good tn3270 for A/UX? Just use Brown University's tn3270. Need to do a Tektronix emulation? Just use the NCSA Telnet you're used to on the Mac. Hypercard, MacWrite, MacTCP, they all work just like in the Mac OS. Furthermore, your UNIX files can also be accessed from the desktop (or via the standard UNIX command line if you wish), directories appear as folders, your NFS-mounted remote files systems just show up as folders within your "root" volume (it appears as a hard disk with the name '/') on your desktop. If you have AppleSingle or AppleDouble files on your local UNIX disk (or on some remote NFS mounted system) such as the Gator box creates when it emulates AppleShare, they will appear as Mac icons that can be launched by double clicking. There's even a Mac-friendly editor to deal with UNIX text files if you don't want to fight vi. If you want or need it, though, you have a command line environment available. It also includes a powerful 'Commando" feature.(UNIX die- hards would call it a crutch.) Based on a utility found in MPW, it allows you to start a command, and then call up a window that lets you select options and arguments using radio buttons and menus, and interactively builds the command line for you. So if you forget how to sort a directory listing by date of last access, the Commando brings up a dialog box with that option. For those who have spent too many hours at a Mac and can't even remember the 'ls' mnemonic for directory or 'grep' to search for a string, there is a folder of "Useful Commands" with short descriptions of each. There are some provisos: Only '32-bit clean' Mac applications are guaranteed to work in the standard login environment. Apple has been pushing vendors to make newer versions of their software 32-bit compliant, but there is a 24-bit login environment that will allow earlier versions of software to run. In addition,(for the hard-core) there is a bare-bones standard command-line-only login environment, as well as an X-Windows environment. The login screen offers a pull- down menu to give the user a choice among these options before logging in. Running the 24-bit environment, some niceties are lost (like the 'Commando' command completion). If you run the X-Windows environment, you lose the Multifinder windows, and get only a 'standard' X-Windows desktop. However, the announced-but-not-yet- released MacX will run under the 32-bit MacOS environment, so you can have your X-cake and eat it too! In fact, you can have an X- window 'client' program running under A/UX, but displaying in the MacX 'server 'window which runs as one of the Multifinder layers. Note also that while MacOS applications and the desktop are aware of the UNIX files and file system, the A/UX side of the house can only deal with its own (and NFS-mounted) files. Now of course if MacOS ran an NFS-server... All this flexibility comes at a price. Running a very early beta release of the software on an 8 MB MacII, responsiveness was sluggish at times. Handling remote file systems, updating the desktop, spooling print files, background processes, all take a slice of the CPU's horsepower. If A/UX is the UNIX we have been waiting for, the zippy new Mac IIfx maybe the machine *A/UX* was waiting for. However, having your whole Mac environment suddenly living on top of UNIX is quite a tour-de-force. We will be installing A/UX 2.0 on an early test version of the IIfx to see how it performs on this machine. A/UX is reported to make good use of many of the enhancements that have been incorporated into this machine X-windows mavins will be pleased to find, however that the latest X- 11 release 4 version of the software is much improved, and performs very nicely under A/UX 2.0, even on the MacII we first used to test it. We saw none of the 'rubber-banding' with resized or dragged windows we saw in earlier versions, and drop-down menus were responsive and snappy. The 'battle for the desktop' now has several contenders, with Mac- on-UNIX added to NeXTSTeP-on-UNIX, Motif-on-UNIX, OpenLook-on-UNIX, and Presentation-Manager-on-OS/2 (not to mention Apple's own System 7 which debuts this summer) all fighting to win the GUI (Graphic User Interface) Wars. In terms of a migration strategy, however, A/UX 2.0 seems like a real a break-through that will allow users to move to a multi-tasking operating system without losing their environment and software investments.
chuq@Apple.COM (Chuq Von Rospach) (03/22/90)
oberst@phoenix.Princeton.EDU (Daniel J. Oberst) writes: >There are some provisos: Only '32-bit clean' Mac applications are >guaranteed to work in the standard login environment. Apple has been >pushing vendors to make newer versions of their software 32-bit >compliant, but there is a 24-bit login environment that will allow >earlier versions of software to run. I'm finding a lot of stuff works -- I use Word, Excel, Hypercard on a regular basis. MPW doesn't work without the patch (that'll change officially RSN). Aldus freehand seems to hang during initialization. MS-Mail (init/cdev combination) 2.0 doesn't work. It's almost amazing how well the compatibility works: Boomerang 2.0 works under A/UX 2.0. INITs on Unix. (better. RANDOM INITs on unix, not just Apple ones). >All this flexibility comes at a price. Running a very early beta >release of the software on an 8 MB MacII, responsiveness was >sluggish at times. I've been told this is because early kernels are full of debugging and instrumentation. By release time, this'll all be stripped and it'll be faster. >We will be >installing A/UX 2.0 on an early test version of the IIfx to see how >it performs on this machine. Bwa-ha-ha. you'll like it. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] All spirits are enslaved which serve things evil -- Shelley
vpsingha@athena.mit.edu (Vivek P. Singhal) (03/22/90)
In article <14743@phoenix.Princeton.EDU> oberst@phoenix.Princeton.EDU (Daniel J. Oberst) writes: >Some early reactions of an A/UX 2.0 beta tester: >[long description deleted]. Even after reading numerous postings about the power of the A/UX operating environment, I still haven't seen the answer to one question: under A/UX 2.0, can applications be written that take advantage of BOTH the Macintosh toolbox and Unix library calls (e.g. fork ())? Can such "hybrid" programs be written with existing tools like MPW? Or, are programs that use the Mac toolbox restricted to residing in the "compatibility" layer, unable to use the multiprocessing (and other) capabilities of Unix? Vivek -- _____________________________________________________________________________ | Vivek Singhal: vpsingha@athena.mit.edu 474 Memorial Drive | | (617) 621-0405 Cambridge, MA 02139 | |___________________________________________________________________________|
gentner@Apple.COM (Don Gentner) (03/23/90)
In article <14743@phoenix.Princeton.EDU> oberst@phoenix.Princeton.EDU (Daniel J. Oberst) writes: >Some early reactions of an A/UX 2.0 beta tester: > >A/UX 2.0, the latest version of Apple's UNIX offering, is what >Apple's UNIX should have been all along. Gee, thanks a lot. >Running the 24-bit environment, some niceties are lost (like the >'Commando' command completion). You can still use Commando in the 24-bit environment. In the normal 32-bit environment, there are three main ways of invoking Commando: 1) In the Finder, double-click on the command icon (or select the command icon, and choose Open from the File menu).. 2) In CommandShell, type: <command-name> Command-K (or choose Commando from the Edit menu). 3) In CommandShell, type: cmdo <command-name> Methods 1) and 2) still work in the 24-bit environment. Don - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Don Gentner email: gentner@apple.com Apple Computer telephone: 408 974-5198 10440 Bubb Rd, MS: 58A fax: 408 974-0892 Cupertino, CA 95014 AppleLink: GENTNER
amanda@mermaid.intercon.com (Amanda Walker) (03/23/90)
In article <1990Mar22.152002.15159@athena.mit.edu>, vpsingha@athena.mit.edu > Even after reading numerous postings about the power of the A/UX > operating environment, I still haven't seen the answer to one > question: under A/UX 2.0, can applications be written that take > advantage of BOTH the Macintosh toolbox and Unix library calls (e.g. > fork ())? Can such "hybrid" programs be written with existing tools > like MPW? Or, are programs that use the Mac toolbox restricted to > residing in the "compatibility" layer, unable to use the > multiprocessing (and other) capabilities of Unix? You can indeed write applications that use both native A/UX facilities and the Toolbox. I'm not entirely clear about whether these end up in the "virtual Macintosh" process or in their own UNIX processes, however. The easiest way to write these seems to be to make an MPW library that's the equivalent of A/UX's "libc.a", so that a Mac application can call A/UX system calls (Apple is calling such a library "a third party opportunity :-)"). This is what CommandShell is--it's a Mac application that can open pipes and fork off other processes... -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
dwb@sticks.apple.com (David Berry) (03/23/90)
In article <1990Mar22.152002.15159@athena.mit.edu> vpsingha@athena.mit.edu (Vivek P. Singhal) writes: >In article <14743@phoenix.Princeton.EDU> oberst@phoenix.Princeton.EDU >(Daniel J. Oberst) writes: >>Some early reactions of an A/UX 2.0 beta tester: >>[long description deleted]. > >Even after reading numerous postings about the power of the A/UX >operating environment, I still haven't seen the answer to one >question: under A/UX 2.0, can applications be written that take >advantage of BOTH the Macintosh toolbox and Unix library calls (e.g. >fork ())? Can such "hybrid" programs be written with existing tools >like MPW? Or, are programs that use the Mac toolbox restricted to >residing in the "compatibility" layer, unable to use the >multiprocessing (and other) capabilities of Unix? Yes, a hybrid program can be written to take advantage of the toolbox and unix libraries both. CommandShell (the by now infamous terminal emulator) is one such program. The documentation suite includes, "A/UX Toolbox" which contains complete information on how to do it. David W. Berry A/UX Toolbox Engineer dwb@apple.com
urlichs@smurf.sub.org (Matthias Urlichs) (03/23/90)
In comp.unix.aux, article <7294@goofy.Apple.COM>, dwb@archer.apple.com (David W. Berry) writes: < In article <1990Mar20.181959.16435@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < >Does the A/UX kernel finally support the Berkeley FFS, and/or [#!/what/ever] < < Well, since A/UX 2.0 has now been annoucned (see elsewheres for < complete announcements, it's been posted), yes the 2.0 kernel < will support both FFS and the #!/usr/bin/whatever convention. Great! < >Is there a decent Mac-like text editor? Or the functional equivalent to the < >MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix, < >omitted.) < Well, MPW runs with a single patch, and there is a Mac-like text < editor as well. < But unfortunately, it can't yet run A/UX binaries from/in its windows. (Shouldn't be too difficult, really... Someone want to write a "unixrun" tool?) And the MPW Shell patch should be posted. (The description of how to figure it out yourself mentioned a debugger -- which one? MacsBug? The Unix kernel debugger? The latter would be bad since I don't have a terminal here.) < >NB: Sorry if this sounds like more or less unnecessary bickering about a good < >product. It is (good, I mean), but it could be better. What couldn't? < We're really trying to make it much better. .[...] Judging from the differences between 1.1 and 2.0, I'm inclined to believe that. How long will it take to get System 7.0 up and running under A/UX? ;-) < Now my only problem is that under A/UX 1.1.1, I have a severe case of "incoming serial characters get mysteriously lost at 9600 baud, uucico doesn't get enough time, and I'm the only one in the world this has ever happened to" problem (occurs both for built-in ports and the CommCard). This problem isn't improved by the fact that both the II --> IIfx motherboard upgrade and A/UX 2.0 seem at least three months away, and living in Germany tends to make matters worse ... -- Matthias Urlichs
liam@cs.qmw.ac.uk (William Roberts) (03/23/90)
In article <14743@phoenix.Princeton.EDU> oberst@phoenix.Princeton.EDU (Daniel J. Oberst) writes: >Some early reactions of an A/UX 2.0 beta tester: > >A/UX 2.0, the latest version of Apple's UNIX offering, is what >Apple's UNIX should have been all along. Agreed. >When I first installed the >software,it appeared that the installation had failed, and I tried >to re-launch the installer program--surprise!! A/UX *WAS* installed! >Only the Mac Desktop and icons looked and worked so much like MacOS >I couldn't superficially tell it was UNIX! Don't be silly - who ever heard of a Mac volume called "/"??? >Basically, A/UX lives in one Multifinder layer that lets you set up >multiple terminal windows from which you can run UNIX (A/UX) >applications,moniter UNIX processes, and do other UNIX-y sorts of >things (much like the 'term' program from earlier versions plus a >console window). In the other layers you run whatever MacOS >applications you want. A/UX is the operating system. If you want A/UX 1 style console emulations you can have it. If you want to run the window system, you can: just like Suns & Suntools, except that the window system is MultiFinder and there is a window system login program. The CommandShell application is the equivalent of commandtool, except that one application handles all of the windows, rather than one program per terminal window. Note that Mac/Sun comparisons in this message come with the same "good and bad sex" distinction as the widely reported MacPaint/SunPaint comparison... >Appletalk works (either over Ethernet or >LocalTalk); you can access AppleShare volumes; print to a networked >LaserWriter, use Broadcast, or do whatever you would otherwise do in >a Mac environment. Yes indeed. AppleTalk phase 2 though, so upgrade those FastPaths to understand ETherTalk phase 2.. I am doing a CAP port for "AppleTalk for A/UX" which is the unbundled A/UX 1.1 stuff. >Your MacOS/Multifinder environment gets a chunk >of memory equivalent to your installed RAM. So a 4 MB Mac with A/UX >2.0 gets a 4MB Multifinder environment, and A/UX's memory management >keeps it and the MacOS side of the house happy in that space. Beta software may change. There's no reason for this arbitrary limit and I for one want it raise to the size of the swap space. After all, A/UX itself takes a megabyte or more like all the other Unix kernels these days, so that "4 Meg" is using virtual memory anyway. >Furthermore, your UNIX files can also be accessed from the desktop >(or via the standard UNIX command line if you wish), directories >appear as folders, your NFS-mounted remote files systems just show >up as folders within your "root" volume (it appears as a hard disk >with the name '/') on your desktop. The Finder does a bit more than this in the way of "type guessing" for A/UX files: it looks at the permissions bits to see if it's executable (for example). >If you want or need it, though, you have a command line environment >available. It also includes a powerful 'Commando" feature.(UNIX die- >hards would call it a crutch.) Based on a utility found in MPW, it >allows you to start a command, and then call up a window that lets >you select options and arguments using radio buttons and menus, and >interactively builds the command line for you. It's quite a good "what does this do" alternative to the manual page as well. New tools provide new ways of working. >Note also that while MacOS applications and the desktop are aware of >the UNIX files and file system, the A/UX side of the house can only >deal with its own (and NFS-mounted) files. Now of course if MacOS >ran an NFS-server... Not relevant, though we did do some work on an NFS server process on A/UX that served the Mac filestore. MacOS doesn't come into it, and AppleShare does work for Mac applications. >All this flexibility comes at a price. Running a very early beta >release of the software ... I don't expect that either you or I will be beta-testing ever again after this. Beta testing is *SUPPOSED* to be a secretive activity so that the bugs are ironed out *IN PRIVATE* and the final product works properly. Saying that beta software doesn't work very well is both unnecessary and unhelpful: months from now people will be saying "well, they said on the net that A/UX is really sluggish" and it will be YOUR FAULT. >The 'battle for the desktop' now has several contenders, with Mac- >on-UNIX added to NeXTSTeP-on-UNIX, Motif-on-UNIX, OpenLook-on-UNIX, >and Presentation-Manager-on-OS/2 (not to mention Apple's own System >7 which debuts this summer) all fighting to win the GUI (Graphic >User Interface) Wars. In terms of a migration strategy, however, >A/UX 2.0 seems like a real a break-through that will allow users to >move to a multi-tasking operating system without losing their >environment and software investments. The desktop wars are all based on marketing hype. The neatest idea was NeWS, but that now has a reputation as being "sluggish" and in fact the main impetus behind the X11 surge was the prospect of Sun doing their NFS trick again with NeWS. Naturally Dec et al didn't fancy that, so they pulled out all the stops and formed the X Consortium. My personal opinion (another problem about beta testers doing Kiss-and-tell postings to the net is that everything they say is taken as insider information) goes as follows: 1) Sun don't care about you if you haven't got a big SPARC and so, sadly, NeWS will become marginalised and eventually forgotten. 2) X11 will stick because it works, is well designed and fills a need. X toolkits will come in and out of fashion much like hemlines, because there isn't any way to force people to use them and they offer "standards by negotiation" not "take it or leave it". 3) Apple are right to care as much as they do about the Mac toolbox: if anything they have stopped caring enough (look at the abominable mess of different scanner image file formats - think 32 bit Quickdraw will fix that? No Way). 4) A/UX and SunOS are the current innovators in the UNIX interface (MACH is the innovator in UNIX internals, but that's a different story). A/UX 1.1 proved that Apple can run Unix as well as the next Motorola machine, though the IIfx hardware improvements are very welcome. A/UX 2 adds the Mac desktop to UNIX and this is something I want to see my students using, but it is a mixture of Mac APplications and UNIX applications, which the Mac libraries available to UNIX programmers. I'd like to see future A/UX systems doing innovative things with direct manipulation of UNIX ideas like pipes and filters. I suspect that I will now get into serious trouble with the people who suggested me as a beta site, but I couldn't just sit on my hands and let that message go by... -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 01-975 5250 (Fax: 01-980 6533)
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (03/24/90)
In article <1990Mar22.202427.15112@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
-And the MPW Shell patch should be posted.
-(The description of how to figure it out yourself mentioned a debugger --
-which one? MacsBug? The Unix kernel debugger? The latter would be bad since I
-don't have a terminal here.)
Does Jasik's Debugger run under A/UX? Has anyone tried?
Marc Kaufman (kaufman@Neon.stanford.edu)
urlichs@smurf.sub.org (Matthias Urlichs) (03/27/90)
In comp.unix.aux, article <7359@goofy.Apple.COM>, dwb@sticks.apple.com (David Berry) writes: < In article <1990Mar22.152002.15159@athena.mit.edu> vpsingha@athena.mit.edu (Vivek P. Singhal) writes: < > < >Even after reading numerous postings about the power of the A/UX < >operating environment, I still haven't seen the answer to one < >question: under A/UX 2.0, can applications be written that take < >advantage of BOTH the Macintosh toolbox and Unix library calls (e.g. < >fork ())? Can such "hybrid" programs be written with existing tools < >like MPW? Or, are programs that use the Mac toolbox restricted to < >residing in the "compatibility" layer, unable to use the < >multiprocessing (and other) capabilities of Unix? < Yes, a hybrid program can be written to take advantage of < the toolbox and unix libraries both. CommandShell (the by now infamous < terminal emulator) is one such program. The documentation suite includes, < "A/UX Toolbox" which contains complete information on how to do it. The question here seems to be not whether you can write an A/UX binary which happens to use the Toolbox (the original "term" from A/UX 1.0 did that, even), but whether you could write a MacOS application (and/or standalone code resource, like an XCMD/XFCN for Hypercard) which happens to use A/UX system calls, including fork/exec. I, for one, would very much like to convince the MPW Shell (or even Hypercard) to use some Unix facility or other, but the Shell's notion of running a tool (and Hypercard's of loading an XCFN into memory) and A/UX's notion of fork+exec have virtually nothing in common. I suspect that one of the obstacles would be that almost all system calls I would like to use are in libc.a, and MPW's linker has never heard of COFF. One would also have to do something about global variables, right? (Most C library calls use them.) And how about things like sbrk(2)? Lots of not-quite--minor difficulties, but it could be made to work. If enough people need it. (I doubt that.) -- Matthias Urlichs
oberst@phoenix.princeton.edu (Daniel J. Oberst) (03/27/90)
In article <1826@sequent.cs.qmw.ac.uk> liam@cs.qmw.ac.uk (William Roberts) writes: > >Your MacOS/Multifinder environment gets a chunk > >of memory equivalent to your installed RAM. So a 4 MB Mac with A/UX > >2.0 gets a 4MB Multifinder environment, and A/UX's memory management > >keeps it and the MacOS side of the house happy in that space. > > Beta software may change. There's no reason for this arbitrary > limit and I for one want it raise to the size of the swap > space. After all, A/UX itself takes a megabyte or more like all > the other Unix kernels these days, so that "4 Meg" is using > virtual memory anyway. > For what it's worth MacLeak reported (pre-announcement of A/UX 2.0) that it would be able to take advantage of Virtual Memory. Stay tuned!! I only know what I read there. > >All this flexibility comes at a price. Running a very early beta > >release of the software ... > > ... months from now people will be saying "well, they > said on the net that A/UX is really sluggish" and it will be > YOUR FAULT. > OK, OK. I said it was VERY EARLY BETA. That means there is lots of debugging code, non-yet-optimized, etc. Anyway, I would *expect* there to be some overhead to running all this on top of unix. All these GUI's are going to take lots of desktop horsepower. Apple with QuickDraw has a leg up on many of them, and throwing a fast CPU at it can help with the non-graphical work underneith. Will a MacII user take a performance hit running Mac OS applications on A/UX 2.0? I can still use my MacPlus to run Excel 2.2, but at some point you'll want more power, and I suspect the same will be true of MacII users running A/UX 2.0. (or even 1.1) > 4) A/UX and SunOS are the current innovators in the UNIX > interface (MACH is the innovator in UNIX internals, but that's > a different story) The NeXT interface is breaking as much ground and running interference for many of the problems all of these guys will face: o 1 vs. 2 vs. 3 buttons o click-to-type vs. focus-follows-pointer o handling modal dialog boxes in background windows/processes o system set-up and administration, etc. Apple is bringing its wealth of applications right along with it (WITH its GUI). NeXT has to get vendors to develop applications for their GUI. Unix International and OSF (SUN & AT&T vs. DEC, IBM, HP etc.) are trying to figure out how to make or get 3rd party vendors to make GUI applications (SunTools/OpenLook/Motif/NeXT Step). And of course we all know what success OS/2 is having getting software lined up to run on it GUI. The desktop wars may be marketing hype, but people with buy machines and they will buy software & operating systems for them. Most will want applications and then be happy to know about the underpinnings. --"insider information?", no siree. Just one person's opinion. Daniel J. Oberst
amanda@mermaid.intercon.com (Amanda Walker) (03/27/90)
In article <1990Mar26.212747.11274@smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes: > but whether you could write a MacOS application (and/or standalone code > resource, like an XCMD/XFCN for Hypercard) which happens to use A/UX system > calls, including fork/exec. Technically, yes, but there is so far no development environment that supports such hybrid development. For example, the A/UX version of our product (which is now more or less obsolete, since MacTCP is supported under A/UX 2.0) is a Macintosh binary, built with MPW 3.0, that does A/UX system calls to do I/O to UNIX sockets. What we did was a hack--at the time, MACDTS said (somewhat reluctantly :-)) that it was the best approach. It works best with system calls, and not so well with library routines (but most of these are supplied by MPW anyway): Step 1: decide what calls you need. Step 2: extract the object files you need from libc.a using 'ar'. Step 3: disassemble these object files into 68000 assembly code. Step 4: massage the resulting assembly code into a form acceptable to the MPW assembler (this isn't too hard), and assemble into an MPW object file. Step 5: link with your application. As I said, it's a hack, but it works. Amanda Walker InterCon Systems Corporation --
kalash@starnine.UUCP (Joe Kalash) (03/29/90)
In article <1990Mar20.181959.16435@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: > >Is there a decent Mac-like text editor? Or the functional equivalent to the >MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix, >omitted.) I am curious, what is your long list of superb features? I use MPW these days, and I spend my time being annoyed at the features missing from it that I commonly use under UNIX (although MPW is certainly faster, without a question). I rob from the rich and give to the poor I rob from the poor when the rich need more I rob from the rich again, but alas I never give anything to the middle class - Robin Hoodlum Joe Kalash uunet!starnine!kalash kalash@starnine.com Disclaimer: StarNine knows nothing about what I am saying.
urlichs@smurf.sub.org (Matthias Urlichs) (03/30/90)
In comp.unix.aux, article <692@starnine.UUCP>, kalash@starnine.UUCP (Joe Kalash) writes: < In article <1990Mar20.181959.16435@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < > < >Is there a decent Mac-like text editor? Or the functional equivalent to the < >MPW Shell? (Long list of superb MPW shell features, sadly missing from Unix, < >omitted.) < < I am curious, what is your long list of superb features? I use MPW < these days, and I spend my time being annoyed at the features missing < from it that I commonly use under UNIX (although MPW is certainly faster, < without a question). < Equally curious, what UNIX features do you miss from MPW? What I like most about MPW that's simply not there under Unix: - The "selection file" (filename.<Paragraph>). - Mac-like editing. Ever use copy/paste under X Windows? - Metacharacters that are really meta, i.e. have the eight bit set. - Commando. (Yes, that'll be in A/UX 2.0, but when will _I_ get A/UX 2.0 ??) - Selecting something and sending it off to whatever tool wants my input today, simply by pressing "Enter". - (some other people are sure to come up with some more features...) < < Disclaimer: StarNine knows nothing about what I am saying. Neither do I know anything about what _I_'m saying. -- Matthias Urlichs