[comp.unix.aux] A/UX Release 2.0

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