info-mac@uw-beaver (info-mac) (07/13/84)
From: Richard Furuta <Furuta@washington.arpa>
1) 4-Jun ihnp4!utzoo!henry@Be Re: keyboard query
2) 4-Jun G.TI.DAK@UTEXAS-20.A Re: MS-BASIC 1.0 Bugs
3) 4-Jun Seymour Folder and File info again.
4) 4-Jun princeton!tilt!down!
5) 4-Jun Kenneth Clark Home-Brew Fat Macs?
6) 4-Jun Andrew Sweer VT100 Origin Mode in MacTerminal
7) 6-Jun Tony Siegman Complaint Re Mac Footprint and Cabling
8) 6-Jun Pentti Kanerva MacTerminal emulation of DEC VT1xx
9) 7-Jun Donna Auguste at CMU mac as word processor?
10) 7-Jun Bill Croft SUMEX MacC UNIX Development Kit
11) 9-Jun KSPROUL@RUTGERS.ARPA Communication to a MAC...
12) 9-Jun Mark H. Nodine Re: mac as word processor?
13) 9-Jun Copied Disks Not Identical
14) 9-Jun David H M Spector Copying the Guided Tour Disks
15) 9-Jun David H M Spector Trash Can Quirk
16) 11-Jun Re: Trash Can Quirk
17) 11-Jun David H M Spector Problem with MacPaint and 2 disks
18) 11-Jun Don Johnson Benchmarks for Macintosh and Lisa
19) 11-Jun Mike Schuster resource files
20) 11-Jun wert.pa@XEROX.ARPA Re: Trash Can Quirk
21) 11-Jun Jeff Rosenschein MS-BASIC bug? A short tale of woe....
22) 11-Jun Jeff Rosenschein Error message on trying to eject disk
23) 11-Jun Bill Croft posting instructions for copying 'protected'
24) 14-Jun Bill Croft SUMACC sites
25) 14-Jun Steven I. Ross P Code
Message 1 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 08:34:27
Return-Path: <ihnp4!utzoo!henry@Berkeley>
Received: from UCB-VAX.ARPA by SUMEX-AIM.ARPA with TCP; Sat 2 Jun 84 16:49:32-PDT
Received: by UCB-VAX.ARPA (4.28/4.27)
id AA08095; Sat, 2 Jun 84 16:47:10 pdt
From: ihnp4!utzoo!henry@Berkeley
Date: 2 Jun 84 18:42:56 CDT (Sat)
Message-Id: <8406022342.AA12288@ihnp4.ATT.UUCP>
Received: by ihnp4.ATT.UUCP; id AA12288; 2 Jun 84 18:42:56 CDT (Sat)
To: info-mac@SUMEX-AIM.ARPA
Subject: Re: keyboard query
ReSent-date: Mon 4 Jun 84 08:34:27-PDT
ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
We all owe the Macintosh design team a vote of thanks for having the
courage to build a small keyboard, without a built-in numeric pad and
150 function keys. It is clearly fashionable to enlarge keyboards to
(and, in some cases, beyond) the limits of sanity. It also confers a
marketing advantage, since people who don't know any better (and quite
a few who should!) take the same more-is-better view of keyboards as
they do of lists of software "features". One has to look harder and
harder to find a terminal or microcomputer with a convenient-sized
keyboard bearing a reasonable number of keys. Thank you, Apple!
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Message 2 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 08:34:29
Return-Path: <@SU-SCORE.ARPA:G.TI.DAK@UTEXAS-20.ARPA>
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Sat 2 Jun 84 22:25:08-PDT
Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Jun 84 22:22:35-PDT
Date: Sun 3 Jun 84 00:24:01-CDT
From: G.TI.DAK@UTEXAS-20.ARPA
Subject: Re: MS-BASIC 1.0 Bugs
To: B.BPE%LOTS-A@SU-SCORE.ARPA
cc: info-mac@SU-SCORE.ARPA
In-Reply-To: Message from "B.BPE%LOTS-A@SU-SCORE.ARPA" of Wed 30 May 84 21:02:14-CDT
ReSent-date: Mon 4 Jun 84 08:34:29-PDT
ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The solution to the problem of CALL MOVETO(6,9):PRINT "bb" blanking too
many character is to change the penmode to OR fro COPY i.e CALL PENMODE(1).
I used the distructive nature of backspace to ensure that the space is blank.
I have used this technique to produce a blinking cursor.
Regards, Donald A Kassebaum
-------
Message 3 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 08:34:33
Return-Path: <@RUTGERS.ARPA:JOSEPH@RU-BLUE.ARPA>
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Sun 3 Jun 84 13:59:43-PDT
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 3 Jun 84 16:57:09 EDT
Date: 3 Jun 84 16:58:24 EDT
From: Seymour <JOSEPH@RU-BLUE.ARPA>
Subject: Folder and File info again.
To: info-Mac@SUMEX-AIM.ARPA
ReSent-date: Mon 4 Jun 84 08:34:31-PDT
ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
(sorry about previous incomplete message)
Hi folk,
In regards to the claimed shortsightedness of the Mac development
team on their handling of disk directories in memory and the way
folders are stored and updated, please check into this further.
I read an article somewhere, unfortunately for all of us I can't
remember where, that went into relative depth on how the Mac Hard disk
would be implemented. It stated that the Hard disk would be a fairly
intelligent device on its own and would not use the Mac's memory for
the large directory and file information. It would somehow
communicate with the mac in packets, the mac requests a certain folder
or file and the hard disk worries about getting it. I don't know if
this is how the Davong or Tecmar disks are built, but this is how the
Mac development group intended it.
If anyone else has a better pointer to this article I cannot find or
knows anything more about how Apple plans to implement hard disks on
the Macintosh, please let us know.
Seymour Joseph
-------
Message 4 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 08:34:35
Return-Path: <@seismo.ARPA:princeton!tilt!down!honey@seismo.ARPA>
Received: from seismo.ARPA by SUMEX-AIM.ARPA with TCP; Mon 4 Jun 84 05:43:26-PDT
Return-Path: <princeton!tilt!down!honey@seismo.ARPA>
Received: by seismo.ARPA; Mon, 4 Jun 84 08:41:25 EDT
From: princeton!tilt!down!honey@seismo.ARPA
Message-Id: <8406041241.AA00927@seismo.ARPA>
Date: 4 Jun 1984 07:55-EDT
To: info-mac@seismo.ARPA
ReSent-date: Mon 4 Jun 84 08:34:35-PDT
ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
/***** down:net.micro.appl / mhuxt!evans / 3:19 pm May 30, 1984*/
Manx Software will be releasing their Macintosh C very soon -- they will
now take your name and put it on a mailing list. Does anyone have any
specifics yet? If you want to get on their mailing list try them at:
(201) 530-7997
Steve Crandall
ihnp4!mhuxt!evans
/* ---------- */
Message 5 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 16:23:29
Return-Path: <clark@AEROSPACE>
Received: from aerospace.ARPA by SUMEX-AIM.ARPA with TCP; Mon 4 Jun 84 13:10:30-PDT
Date: Mon, 4 Jun 84 13:02:20 PDT
From: Kenneth Clark <clark@AEROSPACE>
To: byard @ dca-eur
CC: info-mac@sumex-aim, clark@aerospace
Subject: Home-Brew Fat Macs?
In-reply-to: Your message of 2 June 1984 10:28 GMT
ReSent-date: Mon 4 Jun 84 16:23:29-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I would be game for trying to convert my Mac to 512K but:
1) Some skill would be required by owners because the memory chips
are soldered in (no chip sockets), and de-soldering 16 chips without
distroying the circuit board is non-trivial.
2) It voids our warranty...
3) Would not we need a modified Finder and/or Toolbox ROM to make effective
use of the extra memory?
Now of course if Apple would make available an official upgrade kit to
qualified user groups...
Message 6 -- ************************
Mail-From: PATTERMANN created at 4-Jun-84 16:23:31
Mail-From: SWEER created at 4-Jun-84 14:28:18
Date: Mon 4 Jun 84 14:28:18-PDT
From: Andrew Sweer <SWEER@SUMEX-AIM.ARPA>
Subject: VT100 Origin Mode in MacTerminal
To: Info-Mac@SUMEX-AIM.ARPA
ReSent-date: Mon 4 Jun 84 16:23:31-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
It looks like there is a subtle bug in the way MacTerminal
emulates a VT100. I've been using MacTerminal version -0.15X, 4/18/84.
The bug shows up when doing "reverse windowing" in TVEDIT, a display
editor devoloped at Stanford.
According to the VT100 documentation, Setting or Resetting the
Origin Mode (via ESC [?6h and ESC [?6l respectively) is supposed to move
the cursor to the new home postion. It does on a real VT100, but not
on the Mac. This causes an ensuing Reverse Index (ESC M) to fail because
the cursor is not left at the top margin, thereby avoiding the scrolling
down operation.
Andy
-------
Message 7 -- ************************
Mail-From: PATTERMANN created at 6-Jun-84 08:27:42
Return-Path: <SIEGMAN@SU-SIERRA.ARPA>
Received: from SU-SIERRA.ARPA by SUMEX-AIM.ARPA with TCP; Tue 5 Jun 84 11:53:31-PDT
Date: Tue 5 Jun 84 11:50:55-PDT
From: Tony Siegman <SIEGMAN@SU-SIERRA.ARPA>
Subject: Complaint Re Mac Footprint and Cabling
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Wed 6 Jun 84 08:27:42-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Great pride attaches to Mac's small footprint -- only "x" inches wide
and "y" inches deep. In fact, I have a shelf just "y" inches in depth right
beside my desk...obviously a great place to put the Mac.
Except, those big rigid cable connectors sticking out behind the Mac
(and most other terminals and PCs) add effectively at least 2", and closer
to 3" to the required depth. We need all this hardware to attach 3 or 4
tiny wires?!?!
In addition, if you happen to be carrying your Mac around the house
with the cables attached, and you catch one of those connectors on a piece
of furniture or the edge of a doorway, it breaks off the whole connector
receptacle, in a manner that's most excruciatingly difficult to repair...
My vacuum cleaner neatly rolls up and stores its own cords; so does
my slide projector. With all the sophistication involved in the design of
these computers and terminals, when is some elementary product design
ingenuity going to be applied to simple cable connections that come out the
bottom of the machine, or a slot or a little enclosure, or something!!!
Apple, are you listening...?
-------
Message 8 -- ************************
Mail-From: PATTERMANN created at 6-Jun-84 17:16:55
Mail-From: PKANERVA created at 6-Jun-84 10:54:15
Date: Wed 6 Jun 84 10:54:14-PDT
From: Pentti Kanerva <PKANERVA@SUMEX-AIM.ARPA>
Subject: MacTerminal emulation of DEC VT1xx
To: Info-Mac@SUMEX-AIM.ARPA
cc: PKanerva@SUMEX-AIM.ARPA
ReSent-date: Wed 6 Jun 84 17:16:55-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
This letter is for the people writing a VT100 emulatior for the
Macintosh computer:
Would it be possible to extend it into a VT131 or VT132 emulator?
The VT13x has commands for inserting and deleting characters in a line,
which the VT100 does not have. These commands are used by host-based
full-screen text editors such as TVEDIT and EMACS. On the VT100 these
editors insert and delete in a line by rewriting the line from that
point on, which is painfully slow if you edit at home over a 300-baud
line, and slow even at 1200 baud.
The VT131 could be the first choice for the emulation, as it has
the necessary commands but is simpler than the VT132. Local editing,
special fields, and page transmit in the VT132 makes it a complicated
terminal to emulate. Both the VT131 and the VT132 are compatible with
the VT100. The difference between the VT100 with the Advanced Video
option and the VT131 is not very great.
- Pentti Kanerva
-------
Message 9 -- ************************
Mail-From: PATTERMANN created at 7-Jun-84 13:32:24
Return-Path: <DA81@CMU-CS-A.ARPA>
Received: from CMU-CS-A.ARPA by SUMEX-AIM.ARPA with TCP; Wed 6 Jun 84 23:02:24-PDT
Date: 7 June 1984 0150-EDT
From: Donna Auguste at CMU-CS-A
To: Bboard.Maintainer@CMU-CS-A
Subject: mac as word processor?
Attention: macintosh bboard
ReSent-date: Thu 7 Jun 84 13:32:24-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I would like some information about use of the MacIntosh for creating,
formatting, and printing text documents. What are MacWrite's strong
points and weak points? Are there other word processor alternatives
available for the MacIntosh now or on the horizon? Are there printers
and printer-interfaces that can cope?
Please reply to Auguste@CMU-CS-A. Thanks.
Message 10 -- ************************
Mail-From: PATTERMANN created at 7-Jun-84 13:32:27
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 7 Jun 84 02:37:29-PDT
Date: Thu, 7 Jun 84 02:37:16 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMEX MacC UNIX Development Kit
ReSent-date: Thu 7 Jun 84 13:32:27-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Our SUMEX MacC / UNIX development environment is finally ready for
beta release. Below I have reproduced some sections of the
full 'manual'. If you are interested I suggest you first FTP
the manual from <info-mac>sumacc.txt (login: 'anonymous') and
read it carefully. For those with nroff/troff access, the
file 'sumacc.ms' will produce a much nicer looking typeset version.
-----
1. Introduction
This 'short' note describes the current state of our
UNIX/C development environment for the Macintosh, SUMacC
("some-max"). At present the release must still be con-
sidered in a beta test stage. Although all the test pro-
grams we have tried so far operate correctly, there are no
doubt some minor bugs still lurking somewhere inside.
We are distributing this package under the condition
that it may be "used" but not "sold" without our
permission. This software is under a Stanford copyright
which must be retained on all copies of this software. Any
fixes or enhancements made to the package should be
reported back to us, for incorporation into future
releases. While we will attempt to fix bugs and provide
new features, no warrantee is expressed or implied. You
are basically on your own.
Since this is a beta release, and since we are not
equipped to duplicate massive amounts of tapes and disks, we
are limiting distribution to those who can use the Arpanet
to FTP a copy from our SUMEX-AIM host, or from another
nearby host on the Arpanet. To facilitate this, we ask that
anyone picking up a copy be willing to act as a redistribu-
tion point. Send a note to croft@sumex giving the pathname
and anonymous FTP login to retrieve a copy from your host.
I will post a note to info-mac a few days after release sum-
marizing where folks can pickup a copy.
2. Prerequisites
The package is currently only setup for a VAX running
4.1 or 4.2 BSD UNIX. It should be convertable to any other
UNIX box having a 68000 C compiler.
We assume you have some release of the Apple MacTermi-
nal program. This is used to download a printable hex file
from the VAX to your Mac disk.
Since we don't have the resources to duplicate Sony
disks for everyone outside the Stanford community, we also
assume you have access to a Lisa (Mac Workshop) development
system. This is used, one time only, to put a program on
your Mac disk (called fromhex ) that takes the printable hex
output from MacTerminal, and turns it into binary resource
file (fork). Below in the Downloading section, we discuss
possible alternatives. In any case, it's simply handy to
have at least one Lisa system available occasionally, since
this is how new software is released from Apple.
3. Contents of the Kit
The following directories/files are in the distribu-
tion:
sumacc.ms This file, in -ms macro format.
Makefile Master makefile that calls Makefile's in sub-
directories.
cc42 C compiler binaries for 4.2 BSD.
cc41 C compiler binaries for 4.1 BSD.
ccsrc C compiler source (if provided).
h Macintosh header files, copied to
/usr/include/mac.
lib Macintosh library files.
cmd Resource maker and other Macintosh related com-
mands.
test Some Macintosh C test programs.
man Manual pages.
ws Reference copy of most of the sources distri-
buted with the Lisa Workshop.
4. Installation
5. Test Programs
The C test programs provided are:
MacScrawl
A primitive text/drawing program that was used to test out
the Quickdraw and Event Manager routines. Its commands
are single keyboard characters; examine the source code
before trying to use it. Try the 'm'agnifying lens to
zoom in and out on sections of the screen and/or the lens
itself. In one-to-one mode there is some interesting
stuff going on at the bottom of screen memory.
Grow
This is a straight translation of the Pascal Grow program
provided in the Workshop. Windows, events, menus, Tex-
tEdit, and desk accessories are all exercised. As an exer-
cise, you might runoff a listing of grow.c and grow.p.ws
(in the same directory) to compare how the Pascal was
translated to C.
Insane
This tests the SANE IEEE 80 bit floating point package and
numeric conversion. Floating operations seem to average
about 1 millisecond (well you can't say it isn't accu-
rate...).
6. Typical Compilation Cycle
7. Current State of Downloading
8. Future State of Downloading
9. Toolbox Programming
9.1. Argument Passing
9.2. Handle Dereferencing
9.3. Pascal Bird-Nest Soup
9.4. String Utilities
9.5. Heap vs. C Bss
9.6. Pascal Toolbox Calling on C Routines
9.7. Floating Point
10. Compiler Sources
The normal distribution contains only sources for the
code we have written here at SUMEX. Since the compiler is
based on the Bell Labs (Johnson) Portable C Compiler, we
must be careful about distributing copies of this. It's also
unclear to me what good the compiler/assembler/loader will
do for you, since it's a large and somewhat crufty amount of
code. As an interim policy we will make these sources
available to other Universities if there is enough interest.
However don't ask unless you plan some active development in
this area.
11. Currently Unimplemented
Overlays; MacPrint interface and linkage; Graf3D (but
see lib/TODO for a hint on how to convert this).
-----
The package currently is available as a 2 megabyte tar file located
on <info-mac>sumacc.tar. At this moment it is available both
on SUMEX-AIM (California) and COLUMBIA-20 (New York), so you
should pick the host closest to you. It would be appreciated if
you performed the file transfer during off hours as it takes
about a half-hour under best conditions. At two in the afternoon
it would probably take much more time than this and be an annoying
additional load on our overburdened systems. If more than one
group in your area wants a copy, please try to coordinate things
so you only get it from us once.
The hosts mentioned above are not UNIX hosts, so you must be
extra careful in performing the file transfer to ensure you
get all eight bits. On your side you must set the transfer
mode to "TENEX" or "TYPE L 8" (ask your FTP guru if unsure).
We picked these distribution hosts because they happen
to have direct Arpanet connections (as opposed to routing
through gateways).
If you take a copy, please send me (croft@sumex) a note so I
can put together a list of users. In a few days I can post this
list to info-mac so that it becomes more likely for you to
find a copy in your area.
Stanford users may drop by our SUMEX office (Med Ctr, TB105) where they
can borrow a copy of our SUMACC Sony disk for duplicating on their own
machine.
Good Luck!
--Bill Croft
Message 11 -- ************************
Mail-From: PATTERMANN created at 9-Jun-84 15:54:43
Return-Path: <KSPROUL@RUTGERS.ARPA>
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Fri 8 Jun 84 07:13:51-PDT
Date: 8 Jun 84 10:11:49 EDT
From: KSPROUL@RUTGERS.ARPA
Subject: Communication to a MAC...
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Sat 9 Jun 84 15:54:43-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I want to be able to down-load (up-load) object code to a mac from other
computers, mainly my (dont laugh) APPLE IIe... I have a VERY good
68000 assembler on the APPLE and can write 68000 programs,, Now
all I need to be able to do is to load the object code into the machine.
My current idea is to write a BASIC program that does this, but I would
rather do it a better way.. I also want to use the Motorola S2--- hex
format, but this is not required...
Any help would be appreciated
(I do have a copy of Inside Mac, but havent been able to read it much).
Keith Sproul
Ksproul@Rutgers.arpa
-------
Message 12 -- ************************
Mail-From: PATTERMANN created at 9-Jun-84 15:54:45
Return-Path: <mnodine@bbnh>
Received: from bbn-unix.arpa by SUMEX-AIM.ARPA with TCP; Fri 8 Jun 84 14:37:40-PDT
Received: from BBNH.ARPA by BBN-UNIX ; 8 Jun 84 11:34:05 EDT
Date: Fri, 8 Jun 84 11:01:50 EDT
From: Mark H. Nodine <mnodine@BBN-UNIX.ARPA>
Subject: Re: mac as word processor?
In-Reply-To: Your message of 7 June 1984 0150-EDT
To: Donna Auguste@cmu-cs-a.arpa
Cc: mnodine@BBN-UNIX.ARPA, info-mac@sumex-aim.arpa
ReSent-date: Sat 9 Jun 84 15:54:45-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I have actually been quite pleased the MacWrite word processing capabilities.
I have used a number of screen-oriented editors (as well as some line-oriented
ones) and have enjoyed the user interface of MacWrite. I also have
considerable experience with a large number of text-justifying systems.
Some of the strengths:
(1) It is quite consistent in the way it handles things. You don't find a
lot of (unpleasant) surprises that happen when a system either tries to be
smarter than you want it to or not as smart as you would wish.
(2) The most commonly used features such as paragraph indenting and word
alignment/rearrangement are done completely automatically and predictably.
(3) The ability to mix graphics with text is an enormous boon.
(4) The WYSIWYG philosophy is generally helpful, particularly with such
things as page boundaries and word alignment.
(5) The imagewriter in high quality, non-tall adjust mode with the Geneva 10
font (the only font for which I have any experience) is amazingly good for a
dot-matrix printer -- I even used it for a final copy of my resume.
(6) There is a large variety of fonts, sizes and styles available. In
particular, the outline and shadow styles are things I have never seen
elsewhere. The Cairo (hieroglyph) font is interesting.
(7) It's fun. I believe that things are much more easily learned and
retained if they are fun to use.
Weaknesses:
(1) There is a minimum margin size which cannot be passed. This is
something like 1" on the left and 1 1/4" on the right.
(2) Although I have not tried any large documents (yet), I am told that
there are problems when MacWrite gets close to its memory limits. Very
large documents have to be broken into several files. This is probably not
a problem if your chapters tend to be a size that fit in memory, but
otherwise...
(3) There are still a couple of bugs even in the upgraded version of
MacWrite which pertain to things which are outdented getting lost when
printing in high quality mode. Presumably Apple will fix these since they
have been mentioned before on Info-Mac.
(4) There are some cases where the WYSIWYG philosophy does not work very
well. The major case I can think of has to do with formatting of
mathematical equations. In this case, the style used by TEX or the eq
preprocessor for nroff/troff is probably preferable.
(5) It is impossible to create tables with vertical lines short of
creating them in MacPaint and pasting them in. This creates problems if you
need to edit them...
(6) As far as I can tell, you cannot have a picture from MacPaint on the
same line as MacWrite text. This means you must have
<text...>
<picture>
<text...>
Occasionally something else is desired. Oh well.
(7) The mouse is perhaps somewhat overused.
I still really like MacWrite, and would probably have been willing to use it
for my thesis if the Mac had been available then.
Cheers,
Mark
Message 13 -- ************************
Mail-From: PATTERMANN created at 9-Jun-84 15:54:48
Return-Path: <OTHB@SRI-KL.ARPA>
Received: from SRI-KL.ARPA by SUMEX-AIM.ARPA with TCP; Sat 9 Jun 84 11:47:53-PDT
Date: Sat 9 Jun 84 11:45:56-PDT
From: <OTHB@SRI-KL.ARPA>
Subject: Copied Disks Not Identical
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Sat 9 Jun 84 15:54:48-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Try this:
- Boot your Mac from disk A containing the new Disk Copy utility.
- Run it and make a copy of disk A onto a blank disk B.
- Quit from the copy program and it will request you insert disk A.
- Insert disk B instead (presumably an exact copy of A) and it rejects it.
It would appear that Copy does not produce an identical copy of
the source disk. Is this a bug or a feature? Perhaps there is a counter
incremented that will prevent you from making copy number 1001... Anyone know?
- Jon Spear
-------
Message 14 -- ************************
Mail-From: PATTERMANN created at 9-Jun-84 15:54:50
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Sat 9 Jun 84 13:27:03-PDT
Date: 9 Jun 84 16:23 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Subject: Copying the Guided Tour Disks
Message-ID: <1615A0109.01CB002B.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Sat 9 Jun 84 15:54:50-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I am bot sure if this has been mentioned yet, but...
The Guided Tour disks (both of them) may be copied using DiskCopy that comes
with the second version of the Finder. I usually write_protect the originals,
just to be on the safe side. The copies work fine.
Also, I just got my second drive, does anyone know if the is/will be a version
of DiskCopy for multi-drive systems, DiskCopy seems to me to be a heck of a lot
faster than usual way copy copying stuff on a two drive system....
David HM Spector
NYU Systems Group
________________________________________.
|ARPAnet: SPECTOR@NYU-CMCL1 |
|USEnet : ...floyd!cmcl2!acf4!spector|
| -+-+-+- |
|Any opinions expressed herein are my own|
|and should not be considered those of my|
|employer. |
________________________________________.
-------
Message 15 -- ************************
Mail-From: PATTERMANN created at 9-Jun-84 15:54:51
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Sat 9 Jun 84 13:32:01-PDT
Date: 9 Jun 84 16:28 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Subject: Trash Can Quirk
Message-ID: <1615A75D4.01CB002B.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Sat 9 Jun 84 15:54:51-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I found an interesting aspect of the finder and the trash can last night.
I have three disks on the desktop, I decided to "throw away" one of the ones
I didn't need att the moment by dragging it to the trash, after a moment
I thought better of it, and decided to retrieve it from the trash,
when I opened the trash, it wasn't there. There was over 100Kb free, so
I don't think that the finder suddenly needed the space.
I thought that any object that was "the last thing thrown away" could be
recovered, does this not apply to disks?
David HM Spector
NYU Systems Group
________________________________________.
|ARPAnet: SPECTOR@NYU-CMCL1 |
|USEnet : ...floyd!cmcl2!acf4!spector|
| -+-+-+- |
|Any opinions expressed herein are my own|
|and should not be considered those of my|
|employer. |
________________________________________.
-------
Message 16 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:06
Return-Path: <OTHB@SRI-KL.ARPA>
Received: from SRI-KL.ARPA by SUMEX-AIM.ARPA with TCP; Sat 9 Jun 84 18:24:27-PDT
Date: Sat 9 Jun 84 18:22:12-PDT
From: <OTHB@SRI-KL.ARPA>
Subject: Re: Trash Can Quirk
To: SPECTOR@NYU-CMCL1.ARPA
cc: info-mac@SUMEX-AIM.ARPA
In-Reply-To: Message from "David H M Spector <SPECTOR@NYU-CMCL1.ARPA>" of Sat 9 Jun 84 16:28:00-PDT
ReSent-date: Mon 11 Jun 84 22:28:06-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I don't recall that the ability to throw away a disk icon is a documented feature, but it appears to work like this: When you insert a new disk, all
directory information is read into RAM. You have probably noticed that
sometimes the Mac runs out of memory and tells you it is throwing out one
or more disks. When you throw away a disk icon, you are merely freeing the
RAM that was holding the disk's directory. Since the disk still has a (?)
faithful copy of it's directory, you can read it back in if desired, and
there is therefore no need to allow you to take it back out of the trash
(except, perhaps, for consistancy...).
Which reminds me, there were some bugs in the old version of the
finder (haven't checked the new one yet) related to throwing disks away.
You could modify the INFO entry for a file on a disk that is not in the
drive at that time, throw away the disk icon, and never have the INFO
recorded. In this case, the finder should ask you to reinsert that disk
before allowing you to throw it away or only let you change INFO entries
on the currently inserted disk.
-Jon Spear
-------
Message 17 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:08
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Sat 9 Jun 84 19:17:35-PDT
Date: 9 Jun 84 22:13 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Subject: Problem with MacPaint and 2 disks
Message-ID: <1617A1864.028F0030.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Mon 11 Jun 84 22:28:08-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
When MacPaint is "launched", it seems that it has to have around 32Kb of
free space on its home disk inorder to start up, regradless of how much
free space is available on another disk.
For example, if you have your MacPaint on the internal drive, along with
some other applications, and on your EXTERNAL drive, you have the documents
on which you wish to work, you will never be able to get into MacPaint if there
isn't enough free space on MacPaint's home disk. You can select your Paint
documents from the external drive, thus invoking MacPaint on the INTERNAL drive
and you will get something on the order of:
" The disk is getting full, please delete some files or
change disks"
MacPaint will then take you back to the finder. The IS NO WAY to change disks
unless you are *already* inside MacPaint.
Has anyone else seen this happen? All I had in the internal drive was
Write/Paint, the System Folder, and the Empty Folder ( Total 388K ),
There were a number of large fonts, i.e., Ciaro, and Toronto 12, 14... in
the system file, removing those made things better.
Enevtually, though MacPaint should be made smart enought to know that there is
space on another disk, and use that space for its workfiles...
David HM Spector
________________________________________.
|ARPAnet: SPECTOR@NYU-CMCL1 |
|USEnet : ...floyd!cmcl2!acf4!spector|
| -+-+-+- |
|Any opinions expressed herein are my own|
|and should not be considered those of my|
|employer. |
________________________________________.
-------
Message 18 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:10
Return-Path: <dhj@rice.ARPA>
Received: from rice.ARPA by SUMEX-AIM.ARPA with TCP; Sun 10 Jun 84 16:04:10-PDT
Received: by rice.ARPA (AA14437); Sun, 10 Jun 84 17:54:20 CDT
Date: Sun, 10 Jun 84 17:54:20 CDT
From: Don Johnson <dhj@rice.ARPA>
Message-Id: <8406102254.AA14437@rice.ARPA>
To: info-mac@sumex-aim.ARPA
Subject: Benchmarks for Macintosh and Lisa
Cc: dhj@rice.ARPA
ReSent-date: Mon 11 Jun 84 22:28:10-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
As part of an extensive set of benchmarks, the Macintosh and Lisa
machines were subjected to study. These benchmarks differ significantly
from the others in several important respects. The fundamental
difference in this benchmark procedure was that the language used was
PASCAL while the others were written in C. Furthermore, a comparison
the floating point results is difficult. The Macintosh and Lisa are
based on the Motorola 68000 and have no hardware support for
floating-point computations. The floating-point software package
provided by Apple Computer, SANE (Standard Apple Numerical
Environment), does NOT support computations with the standard formats
of single and double precision. Rather, an extended format allocating
80 bits per floating point word is used. Thus, more precision is
obtained than in all other benchmarks. The results are summarized
below; the numbers indicate the time taken for each high-level language
instruction. The numbers in parentheses are the performance ratios: the
ratio of the time taken for a standard computer to that taken by the
machine of interest. Thus, a computer taking half the time of the
standard to execute a given expression would have a performance ratio
of two for that operation. The standard used here was a Texas
Instruments Professional Computer without 8087 support. Note that the
TI-PC is essentially the same as an IBM PC but with a slightly faster
clock (5 MHz versus 4.77).
Personal Computer Benchmarks
TEST TI-PC TI-PC Macintosh Lisa
w/8087 MacWorks
16-bit Integer Operations (USEC)
J=I+K 13.5 5.6 (2.41) 7.2 (1.88)
J=I*K 49.0 11.4 (4.30) 16.0 (3.06)
J=I/K 57.0 26.7 (2.13) 37.7 (1.51)
32-bit Integer Operations (USEC)
J=I+K 50.0 7.6 (6.62) 8.1 (6.17)
J=I*K 184.0 75.5 (2.44) 86.9 (2.12)
J=I/K 1282.0 438.6 (2.92) 526.7 (2.43)
Floating-point Operations (USEC)
X=Y+Z 859.5 282.5 (3.04) 536.1 (1.67) 601.2 (1.43)
X=Y*Z 1469.0 286.0 (5.14) 527.7 (2.78) 606.2 (2.42)
X=Y/Z 9179.0 305.5 (30.05) 1374.4 (6.68) 1696.7 (5.41)
Computational Benchmarks (MSEC)
SQRT 50.0 4.6 (10.87) 2.1 (23.4) 2.8 (18.0)
SIN 31.8 8.8 (3.61) 15.6 (2.04) 18.3 (1.73)
EXP 36.2 6.8 (5.32) 20.5 (1.77) 24.2 (1.50)
LOG 60.5 6.7 (9.03) 22.7 (2.67) 26.9 (2.25)
On the average, the Macintosh was 1.21 times faster than the Lisa
(implying a virtual clock speed of 6.07 MHz). Also note that the SANE
software has a VERY fast square root routine according to these
measurements (only 0.15 that of a VAX 750 with a floating point
accelerator!!).
If you are interested in the full report on my benchmark study,
just ask. If the demand is small, it shouldn't take long for you to
receive your copy. However, note that it focusses on minicomputers
more than on micros.
Don Johnson
EE Department
Rice University
dhj@rice
Message 19 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:12
Return-Path: <MIKES@CIT-20>
Received: from CIT-20.ARPA by SUMEX-AIM.ARPA with TCP; Mon 11 Jun 84 09:15:45-PDT
Date: 11 Jun 1984 0912-PDT
Subject: resource files
From: Mike Schuster <MIKES@CIT-20.ARPA>
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Mon 11 Jun 84 22:28:12-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Is it possible to read from and write to the resource fork of some file using
MS-BASIC?
Mike
(mikes@cit-20)
-------
Message 20 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:14
Return-Path: <wert.pa@Xerox.ARPA>
Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Mon 11 Jun 84 12:44:29-PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUN 84 12:32:07 PDT
Date: 11 Jun 84 12:31:29 PDT
From: wert.pa@XEROX.ARPA
Subject: Re: Trash Can Quirk
In-reply-to: <1615A75D4.01CB002B.1984@CMCL1.NYU-CMCL1.ARPA>
To: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
Cc: info-mac@SUMEX-AIM.ARPA
ReSent-date: Mon 11 Jun 84 22:28:14-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The disk icons on your desk are not files, therefore they do not follow
the rules for throwing away files. What they represent is memory from
the system heap, which is why you get "Not enough memory" errors when
you have too many disk icons. When you throw disk icons away, the memory
is immediately reclaimed, as it should be. It has nothing to do with the
finder needing disk space.
scott
Message 21 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:16
Mail-From: ROSENSCHEIN created at 11-Jun-84 12:47:51
Date: Mon 11 Jun 84 12:47:51-PDT
From: Jeff Rosenschein <ROSENSCHEIN@SUMEX-AIM.ARPA>
Subject: MS-BASIC bug? A short tale of woe....
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Mon 11 Jun 84 22:28:16-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
After extensive editing of a file in MS-BASIC, I saved the file and
quit. Much to my surprise, I found that my file, whose icon was still
present on the screen, now occupied 0K of memory. After a little
searching, I found that the System file in the System Folder was now
an MS-BASIC program icon. Although GET-INFO showed that the System
file occupied its usual 82K, I was able to load it into MS-BASIC,
where it proved to be none other than my original file!
So apparently what happened was that the System file had been destroyed
and replaced with my file; the icon was updated to reflect the
(inadvertant) change, but not the icon location (it was still in the
System Folder), nor the icon name (it was still "System"), nor the
icon size information.
I managed to undo the damage by copying the System file, trashing the
original and bringing over a new copy of the System from another disk.
Then I loaded this (pseudo)-System file copy into MS-BASIC, making a
trivial change (probably unnecessary) and saving the result under my
original file name. My file now had the correct size information.
Then I trashed the (pseudo) System file copy.
I don't know if this is a bug in MS-BASIC or the System (I was using
the latest release of the latter). I also have no idea what
circumstances might have caused it.
--Jeff Rosenschein
-------
Message 22 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:18
Mail-From: ROSENSCHEIN created at 11-Jun-84 12:49:06
Date: Mon 11 Jun 84 12:49:05-PDT
From: Jeff Rosenschein <ROSENSCHEIN@SUMEX-AIM.ARPA>
Subject: Error message on trying to eject disk
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Mon 11 Jun 84 22:28:18-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Has anyone gotten a message something like
"There is not enough memory to eject the System
Disk. Please put a dimmed disk into Trash..."
when, in fact, there *are* no dimmed disks? The message seemed to
occur after copying a file onto the disk in question, ejecting it,
turning the machine off/on, and then just using the disk normally. I
got rid of the problem using the old "Hold the option and command keys
down while inserting the disk"-trick. I'm using the latest version of
the Finder; perhaps the error cropped up because of the MS-BASIC
problem I mentioned in the last message.
I think someone may have already reported this phenomenon months ago,
but I'm not sure.
--Jeff Rosenschein
-------
Message 23 -- ************************
Mail-From: PATTERMANN created at 11-Jun-84 22:28:20
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Mon 11 Jun 84 15:22:49-PDT
Date: Mon, 11 Jun 84 15:22:46 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: posting instructions for copying 'protected' software
Cc: croft, pattermann
ReSent-date: Mon 11 Jun 84 22:28:20-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Info-mac has received several messages from folks explaining how to
copy 'protected' software. We cannot release such messages for several
reasons:
First, it would open both you (the sender) and Stanford (the resender)
to lawsuit action by the software company.
Second, have you really thought out what happens when a copy-protection
scheme is exposed? That's right, the schemes get more and more arcane
with disk speed changes, encrypted sector numbers, etc., etc. Very soon
the protection scheme begins to interfere with the usability and
reliability of the distribution disks. With the Macintosh this is even
more critical since resource files, fonts, the finder, etc. must operate
smoothly in a non-paranoid fashion.
Exposing the scheme is also self-defeating, since the company will soon
change it and thus you will no longer be able to copy the disks.
So please stop sending us such messages. If you want to 'crack' a
protection scheme, consider it as a puzzle you have solved yourself;
if people can't figure out how to crack it on their own (or if they are
simply honest), then they SHOULDNT be copying it.
--Bill Croft & Ed Pattermann
Message 24 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:20
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Tue 12 Jun 84 15:30:39-PDT
Date: Tue, 12 Jun 84 15:30:45 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMACC sites
ReSent-date: Thu 14 Jun 84 08:54:20-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
(this file is stored in [SUMEX-AIM]<info-mac>sumacc.sites)
----
Here is a list of sites and contact people who have fetched a copy
of SUMACC. If you are looking for a copy, try to find someone in your
area who already has it. Some of the people below have also volunteered
to make a SMALL number of tape and/or disk copies for others in the area;
these folks are marked with 'diskcp' or 'tapecp'. Please contact them
first before sending any media.
siteperson@site
Name:Organization:Misc:FTP pathname
croft@sumex
Bill Croft:Stanford SUMEX::<info-mac>sumacc.tar
mikes@cit-vax
Mike Schuster:CALTECH:diskcp, has converted fromhex to FORTH!:
hamachi%ucbkim@Berkeley
Gordon Hamachi:Berkeley::
furuta@washington
Richard Furuta:UofWashington:disktapecp for Seattle area:
kfd@aids-unix
Ken Dove:AIDS::
bajaj@uci-750a
Anil Bajaj:UCIrvine::
dagobah!jks@berkeley
John Seamons:Lucasfilm Ltd.:tapecp:
cal@su-star
Calvin Teague:Stanford radio-astron:up under VMS EUNICE!:
croft@diablo
Bill Croft:Stanford HPP/SUMEX::/usr/local/mac/*
jw-peterson@utah-20
John Peterson:UofUtah::
mike@rice
Mike Caplinger:RiceU:tapecp:
jsq@ut-sally
John Quarterman:UTexas::~ftp/pub/sumacc/sumacc.*
cower@columbia-20
Rich Cower:ColumbiaU::<info-mac>sumacc.tar
farber@udel-ee
Dave Farber:UofDelaware (csnet/arpanet)::
sob@harvard
Scott Bradner:Harvard::
lee@rochester
Lee Moore:UofRochester::public/sumacc.tar
bukys@rochester
Liudvikas Bukys:UofRochester::bukys/uucp/sumacc.*
Max.Henrion@cmu-ri-isl1
Max Henrion:CMU::
Robert.White@cmu-cs-gandalf
Robert White:CMU (Apple tech rep)::
boyle%mit-oz@mit-mc
Joe Boyle:MIT-PREP::/u/bandy/*
johnson@mit-xx
Paul Johnson:MIT LCS::
spitzer%pco@cisl
Charlie Spitzer:MIT MULTICS::
dbrown@hi-multics
Drew Brown:Honeywell Multics::
ddj%brown.csnet@csnet-relay
Dave Johnson:Brown (csnet/bitnet):doesnt have it yet:
us.alan@cu20b
Alan Crosswell:Columbia:for bitnet access mail to eacus@cuvmb:
Message 25 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:18
Return-Path: <SIR@MIT-XX.ARPA>
Received: from MIT-XX.ARPA by SUMEX-AIM.ARPA with TCP; Tue 12 Jun 84 04:04:42-PDT
Date: Tue 12 Jun 84 07:06:23-EDT
From: Steven I. Ross <SIR@MIT-XX.ARPA>
Subject: P Code
To: info-mac@SUMEX-AIM.ARPA
cc: sir@MIT-XX.ARPA
ReSent-date: Thu 14 Jun 84 08:54:18-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Does anyone know if Macintosh Pascal uses standard P code? Is there such
a thing as standard P code. Is there documentation anywhere on the subject?
-- Steve
-------
-------