tucker@ccvaxa.UUCP (03/02/88)
> * 7-10 MIP SPARC processor (who knows maybe their is a SPARC > in Apple's future. It would make sense they would be > binary compatible with Sun and AT&T...I think not tho' given > their recent alliance with DEC ) Apple already has a good processor (the 68020). Right now SUN and AT&T are defining the portable binary platforms. The SPARC chip was the first one. Both AT&T and SUN have said that the 68030 and 80386 will also be added to the list of standard binary bases. Tim Tucker tucker@xenurus.Gould.COM
hirchert@uxe.cso.uiuc.edu (03/11/88)
As a user of both Macintoshes and a Sun workstation, allow me to offer my
$0.02 worth:
1. On the issue of the 1-button vs. 3-button mouse:
a. The technique of using keyboard modifiers to modify the meaning of a
mouse click gives me at least 4 different mouse buttons. If we allow
the less convenient Caps Lock or the less universally available Control,
we have 6. If we allow combinations of modifiers, we have 32. If we
throw in double clicks, we have 64. Of course, the three button mouse
can use the same techniques and have three times as many, but I've never
seen an application that really needed that many different variations
on clicking at a particular position.
b. When gripping a mouse between my thumb and middle finger, I find it
slightly inconvenient mechanically to shift my forefinger between the
three different buttons. (Part of the problem here is that this shifting
is side to side rather than front to back.) On the one button mouse, no
such shifting is necessary. Instead, modification is done with the
keyboard modifiers (multiple fingers, fingers moving primarily front to
back, with side to side motion performed at the wrist rather than at the
finger). I find this whole process mechanically more natural. (As an
aside, it seems easier to use a trackball or joystick in place of a
one button mouse than a three button - you only need to find a place for
one button and it can be made large enough to hit easily.)
c. For the gentleman who had trouble discovering double clicking, I have
two comments:
i. Every introductory lesson or manual on the Mac that I have seen
teaches pointing, clicking, dragging, and double clicking as the basic
mouse operations. I can only guess that you missed this because you
assumed you already knew how to use a mouse on the basis of your
experience with a computer using a multi-button mouse.
ii. I can't think of anything that can be done with double clicking that
can't also be done with a sequence of single clicks and or drags.
E.g. double click on an icon=click on icon and select Open menu item,
double click on list item=click on list item and click on button or
click on list item and lit Return key. Double clicking is a shortcut
like much (but not all) of the use of the left and middle buttons on
the Sun. (On the Sun, most work can be done with only the right
button, but some confirming clicks must be done with the left or
middle button.)
2. On the issue of the fixed menu bar vs. pop-up menus:
a. I like having a fixed reminder of the classes of things I can do and the
application that is currently receiving keystrokes, fielding disk
insertion events, etc.
b. Some of the Sun applications I use have a menu bar across the top of
their (primary) window. It takes less screen space to display one
menu bar across the top of the screen than to put one at the top of
each of several different windows.
c. I'm not bothered by the distance to reach the menu bar because the
nonlinear mouse tracking makes it easy to get anywhere on even a big
screen with only a small hand motion, but if it bothers you, there is
nothing that precludes pop-up menus in addition to the fixed menu bar.
Indeed, there is an INIT available for the Mac that offers precisely
that capability.
d. All menus on a menu bar are equally accessible. On a pop-up menu, the
top submenus are easier to access than the later submenus.
e. The fixed menu bar provides an obvious place for immediate reaction to
user actions. For example, when selecting a menu, the title can be
immediately highlighted even if some computation or input/output is
necessary before the menu itself can be displayed. Similarly, when a
menu item is selected, the menu disappears immediately as an indication
that the selection has occurred but the title remains highlighted as an
indication that the command is in progress. Contrast this with the Sun
interface where these indicators don't exist. On one diskless Sun node
I used, it was not at all uncommon for it to take 30 seconds before there
was any visible reaction to actions like hitting the right button to get
a pop-up menu. This lack of reaction can all too easily undermine one's
confidence in his or her understanding of the user interface.
3. On the issue of window activation paradigms:
a. I am one of those people that finds it disconcerting that accidentally
bumping the mouse can redirect my terminal input.
b. It is rare that I want to input into a window and don't also want to be
able to the effect of that input on the entire window. In part this
reflects a tendency on the Mac to keep windows no larger than they need
to be see what one wants to see. Where a Sun user might put a big
window in the background and bring it to the front to see the big
picture, the Mac user would tend to have a smaller window and use the
zoom box to accomplish the same task.
c. On the Mac, I tend to move the mouse cursor out of the window in which
I am typing because I find it distracting. On the Sun, I can't do this.
d. On the Sun, I have to move the cursor to the window frame and click to
expose the window and then move the cursor inside the frame to enable
keyboard input. On the Mac, I accomplish the same task by simply moving
somewhere on or in the frame and clicking. Thus, I need fewer mouse
movements and there is less need for precision (since I can hit any part
of the window, not just the frame).
The point of these comments is not to suggest that the Mac interface is
uniformly better than the Sun interface. There are aspects of the Sun
interface that I would like to see incorporated into the Mac interface.
For example, I would love to have the capability of collapsing all the windows
of a running application down to a single icon when I'm not looking at it.
I also recognize that some of this is a reflection of my personal preferences
and work habits and that some of this may be a failure on my part to take
full advantage of the Sun interface. (I work on a Mac daily and on a Sun only
once or twice a week.) Still, I think there is reason to believe that Apple
knew what it was doing when it designed this interface for a multitasking
environment (i.e. the Lisa) and that it is not merely "good enough to get by"
but arguably superior for at least some styles of use (including both novice
and experienced users).
Kurt W. Hirchert National Center for Supercomputing Applicationsladd@uiucdcsp.cs.uiuc.edu (03/16/88)
>I think one point you are both missing out on is that preemptive multitasking >requires hardware support not available on a 68000. It is not compatibility >that stops us from implementing preemption, although it does pose some hairy >problems, but the requirement that we can run on a MacPlus and SE. It may be >that preemptive multitasking is preferable to cooperative multitasking -- this >is the real argument here, at least the really interesting one -- but it isn't >possible on a MacPlus. We are investigating preemption on the MacII. >..... >-Phil Goldman >Apple Computer What a shame. The 68000 could have been a good UNIX processor :-). Dave ladd@a.cs.uiuc.edu uiucdcs!ladd
gillies@uiucdcsp.cs.uiuc.edu (03/25/88)
I believe that virtual memory does very little to solve the memory
headaches for developers. As a former developer, I believe these
headaches are intrinsic to writing bullet-proof software. We spent
half the time alpha testing our machine (with VM) in unusual situations
when some resource (RAM, Disk) was unreasonably low. The software had
to keep working.
Even if you macintosh has a 5 megabyte VM space, it is still necessary
to write software that performs gracefully when the machine exhausts
all 5 megs. This is part of writing professional software in general.
Your software should also do something reasonable when the disk runs
out of free pages. Professional developers worry about such things.
Yes I know it's a pain, but it separates the men from the boys in
software design.
Most software written for UNIX is very unprofessional and I'm not
suprised source licenses are so cheap. When a UNIX box begins to run
out of VM, all hell breaks loose an many programs crash inexplicably.
The same thing happens when the machine exhausts disk space.
There would be hell to pay if this happened to a customer running an
editor they paid real $$$ for. If he lost work because the editor
crashed, I would be inclined to believe he deserved his money back.
Today's Mac+ does give you 800K of RAM to play with. That's a lot
more generous than the typical maxxed-out PC, XT, or AT.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}djb@spacely.Jpl.Nasa.Gov (Daniel J. Burns) (03/26/88)
In article <76000174@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > >I believe that virtual memory does very little to solve the memory >headaches for developers. As a former developer, I believe these >headaches are intrinsic to writing bullet-proof software. I'm taking this to mean you were not a UNIX developer. Virtual memory, in fact, is one of the cornerstones of modern operating system design. Indeed, with some operating systems, the poor software developer has to keep track of things that a decent operating system would take care of for him. This is not the case in UNIX. >[ ... other stuff deleted ...] >Most software written for UNIX is very unprofessional and I'm not >suprised source licenses are so cheap. When a UNIX box begins to run >out of VM, all hell breaks loose an many programs crash inexplicably. >The same thing happens when the machine exhausts disk space. Granted, there isn't as much business and personal productivity software on UNIX platforms as on PC's, but this is changing in step with the user community. >There would be hell to pay if this happened to a customer running an >editor they paid real $$$ for. If he lost work because the editor >crashed, I would be inclined to believe he deserved his money back. And Macs don't crash? Dan Burns Jet Propulsion Laboratory (djb@spacely.jpl.nasa.gov)
gillies@uiucdcsp.cs.uiuc.edu (03/27/88)
I'm not sure I made myself clear. Let me put this in terms of UNIX:
- Have you ever thought about what to do when calloc() returns an error
because it can't find more memory? Does calloc() even return, or does
it crash your program on UNIX?
- Have you ever thought about what to do when your program needs to
write a temporary file, but there's no space in /tmp? No space
ANYWHERE on the disk?
- Have you ever tried to write a UNIX program that *didn't* wire
constants into the size of the C data structures? This is generally a
no-no if you want your program to work in unusual situations.
- Have you ever tried to use a UNIX command for something it wasn't
intended for? Very often, it will crash because some static array in
the C code overflows. And to handle the "most cases", many programs
size their data structures far larger than necessary. The result is
wasted memory and still the software can be flakey.
You may argue that UNIX is easier to program. That's because you're
probably writing lousy code. Sure, you can write lousy code on
the macintosh and life is just as easy. Never assume you run out
of anything, and your code will be truly *simple*.
The Macintosh is built so that you implement contingencies when
resources get low. I believe that many parts of UNIX (stdio) are not.
They just assume it's fine to crash the process.
Remember: EVERY computer system, EVEN WITH VIRTUAL MEMORY runs out of
EVERY resource. If you didn't realize this, now you know.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}howard@cpocd2.UUCP (Howard A. Landman) (03/29/88)
In article <76000174@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: >I believe that virtual memory does very little to solve the memory >headaches for developers. As a former developer, I believe these >headaches are intrinsic to writing bullet-proof software. We spent >half the time alpha testing our machine (with VM) in unusual situations >when some resource (RAM, Disk) was unreasonably low. The software had >to keep working. You have a point for programs which are constantly doing allocation (and maybe deallocation), but not all software falls into this category. >Even if you macintosh has a 5 megabyte VM space, it is still necessary to >write software that performs gracefully when the machine exhausts all 5 megs. Very true, but the virtual limits are usually an order of magnitude farther out than the real memory limits, and that means that any program that falls between those limits becomes much more painful to write without VM. The Mac isn't really THAT much more advanced than the '60s and '70s computers that required the writing of "overlays". The programmer must be acutely conscious of what he wants in memory at any instant, and manually "swap out" stuff. With VM this requires no coding at all, and frequently gives better performance, since demand paging is based on the program's ACTUAL behavior, not what the programmer thought it might do. Further, without VM, running a program whose data structures are larger than the available real memory is impossible. I have one program whose virtual image is 4+ MB, and whose working set is under 200 KB. Rather than being easy to port to the Mac, it is impossible without a major rewrite substituting a file-resident database for a memory-resident one. Without VM this program wouldn't work even on a Mac II with 4 MB; with it it could probably run on a 512 KB Mac. (Somewhat related question: Is there a C compiler for the Mac in which #define N_RECORDS 2000000 typedef char record; /* Allocate memory for database table. */ table = malloc(sizeof(record)*N_RECORDS); /*1*/ if (table == NULL) { FATAL_ERR("Not enough memory to load database."); } /* Fill table from data file. */ status = fread(table,sizeof(record),N_RECORDS,datafile); /*2*/ if (status <= 0) { FATAL_ERR("Problem reading database file."); } else if (status < N_RECORDS) { WARNING("Database was smaller than expected."); max_record = status; } else max_record = N_RECORDS; /* Begin doing real work with in-memory database. */ x = table[index]; /*3*/ has a prayer of working? Even assuming AUX and/or enough real memory? That is, (1) Can you allocate LARGE chunks of contiguous memory?, (2) Can you map them easily to and from files?, and (3) Can you have arrays that are megabytes long and index them simply?) >Your software should also do something reasonable when the disk runs >out of free pages. Professional developers worry about such things. >Yes I know it's a pain, but it separates the men from the boys in >software design. It's ONE of the things that separates the mensches from the schmucks. >Most software written for UNIX is very unprofessional and I'm not >suprised source licenses are so cheap. When a UNIX box begins to run >out of VM, all hell breaks loose an many programs crash inexplicably. >The same thing happens when the machine exhausts disk space. Agreed, but at least you don't usually need to reboot. I've got several programs on my Mac that, if you try to run them under the wrong System/Finder, will crash the whole machine. I can only imagine what this must be like under MultiFinder. I've seen a kids games for the Mac that use a picture font for matching-type puzzles, but doesn't have the font resource in the game file, and doesn't bother to check whether the font exists, or whether any given character happens to exist in whatever the System substitutes for it. Ever try explaining to a 3-year old why two identical squares don't match? I am forced to conclude that most Mac software is no better written than most UNIX software. Your comment about source licenses puzzles me. Are you talking about UNIX programs themselves (i.e., parts of the distribution)? >There would be hell to pay if this happened to a customer running an >editor they paid real $$$ for. If he lost work because the editor >crashed, I would be inclined to believe he deserved his money back. Gee, when my UNIX editor has problems it sends me mail telling me how to recover the file. Pretty friendly if you ask me. All it needs is a fraction of a second warning that the system is going down; easy with signals ... -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET
phil@Apple.COM (Phil Ronzone) (03/30/88)
In article <76000176@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > >You may argue that UNIX is easier to program. That's because you're >probably writing lousy code. Sure, you can write lousy code on >the macintosh and life is just as easy. Never assume you run out >of anything, and your code will be truly *simple*. > >The Macintosh is built so that you implement contingencies when >resources get low. I believe that many parts of UNIX (stdio) are not. >They just assume it's fine to crash the process. >Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois Hmmm - well, I do know that I tried vainly to implement a very large database for the A/UX project using Excel. The database was every single command, system call, subroutine, and file with an attached description and origin etc. Excel couldn't even begin to handle it, nor could any of the other spreadsheets or database packages available through the Apple internal software library. So I went back to using awk and vi. (ugh - vi 700,000 lines sometimes ...). I wanted the Mac superior look and feel, but gee whiz, far too many mac programs have horrible limitations compared to the "lousy" UNIX programs Don complains (??) about. I.e., I disagree with Don. There are limitations, but I'll take a limit of say 50MB swap space for a virtual UNIX system over a 1/2/4 MB Mac OS heap/stack limit any day. -- ------------------------------------------------------------------------------- Philip K. Ronzone, A/UX Technical Manager APPLELINK: RONZONE1 Apple Computer, Mail Stop 27AJ, 10500 N. DeAnza Blvd. Cupertino, CA 95014 UUCP: ...!{sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil