INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (07/30/86)
INFO-MAC Digest Tuesday, 29 Jul 1986 Volume 4 : Issue 93
Today's Topics:
Re: System 3.2/Finder 5.3 bug reports
Dead Keys
Error Messages in MacApp
Mac serial port
Re: Mac serial port
Re: LaserWriter 3.1 bombs with Excel chart.
RedRyder 9.2 Term Emulation Problem
Re: RedRyder 9.2 Term Emulation Problem
Duplicate Resources in System File
Duplicate Resources in System 3.2
using Videoworks animations from another program
Making Folders Invisible on HFS
Re: Efs on a MacPlus
Re: Mac Cache
Disk space
Autoblack documentation
Info about MacEqn wanted.
TOPS by Centram Systems West
----------------------------------------------------------------------
Date: Tue, 29 Jul 86 17:13:01 pdt
From: Larry Rosenstein <lsr%apple.csnet@CSNET-RELAY.ARPA>
Subject: Re: System 3.2/Finder 5.3 bug reports
In article <8607290134.AA04404@ucbvax.Berkeley.EDU> you write:
>
>INFO-MAC Digest Monday, 28 Jul 1986 Volume 4 : Issue 92
>
>From: Paul Christensen <PCHRISTENSEN%rca.com@CSNET-RELAY.ARPA>
>Subject: RE: System 3.2 Bugs
>
>
>My initial experiences with the 3.2 System distribution were very bad: the
>system bombed frequently, files were not copied correctly, and boot blocks
>were not written to disk. I was using a system set downloaded from a popular
>subscriber service. When I copied Apple's actual distribution disks from my
>local dealer, 85% of my problems disappeared!!! Here's why....
>
I believe that a corrupt version of the system software was uploaded to
Compuserve (and perhaps other services as well), but that the problem was
fixed within a few days. These services should now have the correct files
(although I have not downloaded them myself to check).
In addition, you should be able to get the software from a dealer.
>....
>
>I WISH APPLE WOULD GET THEIR ACT TOGETHER, STOP ARGUING
>ABOUT KEYBOARDS AND CABINET COLOR, AND RELEASE STABLE
>SYSTEM SOFTWARE!
Once again, let me repeat. System 3.2, etc. is considered to be the
latest, stable system software. I have been using it for several weeks. I
have not had any crashes with it. If you have any reproducible problems,
let me know.
Here is a bug report form that you can use to submit bug reports for Apple
stuff. (This was downloaded from AppleLink.) The best way to submit a bug
is to mail it to the address on the form. If you mail it to me
electronically, I will try to forward it to the proper group, but depending
on how busy I am, it may take a while. (Using this form, however, will
make it much easier for me to submit the bug report.)
Larry Rosenstein, Apple Computer
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>APPLE-BUGREPORT.TXT
DAVEG
]28-Jul-86 23:08:31-PDT,2172;000000000001
------------------------------
Date: 29 Jul 86 01:01:21 GMT
From: voder!apple!lsr@ucbvax.berkeley.edu (Larry Rosenstein)
Subject: Dead Keys
Sender: info-mac-request@sumex-aim.arpa
{}
A long time ago there was a discussion of using the Option key as Control in
Red Ryder. The problem is that certain option key combinations (eg.,
Option-e) are dead keys and don't generate a character until the next key is
typed.
Contrary to the messages posted at the time, it is very easy to disable
dead keys in the keyboard driver (although I'm not sure that this has been
documented). MacTerminal does it, in fact.
Basically, there are 2 resources (pieces of code, actually) that map raw
keycodes, generated by the keyboard, into ASCII characters. One resource
handles the main keyboard and the other the external keypad. It is
possible to completely replace these resources if you want to modify the
mapping in some unusual way.
Turning off dead keys, however, is very easy and already provided in the
system. Low memory location $29E contains the address of the main mapping
function. The resource begins with a 2-byte BRA instruction, followed by a
1-byte flag.
If the flag is $FF then dead keys are on, if it is $00, then dead keys are
off (ie., typing option-E will give you an accent character immediately).
It's as easy as that. Programs that turn off dead keys should make sure to
re-enable them when they terminate.
It would be trivial to write a desk accessory that allows you to
enable/disable dead keys at any time. Then it might be more convenient to
use the Option key in Red Ryder.
I hope this helps current and future terminal emulators.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
------------------------------
Date: 29 Jul 86 00:55:43 GMT
From: voder!apple!lsr@ucbvax.berkeley.edu (Larry Rosenstein)
Subject: Error Messages in MacApp
Sender: info-mac-request@sumex-aim.arpa
{}
(An aside. In case you were not aware, Apple's news software was broken
since the middle of April, which is why there have been no postings from
Apple since then. The news software is now fixed, so we can receive and
respond to news articles again.)
I thought that I would describe the error handling mechanisms that I have
put into MacApp in order to: (1) show how we are addressing the problem,
(2) give people ideas for their applications, and (3) get some feedback.
We are addressing 2 issues: (1) how to easily detect and recover from
errors and (2) how to display meaningful alerts.
For detecting errors, I have implemented a simple error handling scheme.
(People have told me it is similar to setjmp/longjmp in C, but I am not that
familiar with C to be able to compare it)
The system maintains a stack of error handlers. Any procedure can push a
new handler on the stack; the only requirement is that it pop the handler
off before exiting. If the procedure Failure is called, the system pops the
top handler off the stack, and calls it (after restoring registers, etc.)
The handler will usually do some cleanup and then call Failure itself to
propagate the error.
MacApp has a handler in the main event loop that will catch the error,
report it, and continue. An important thing to note is that since the
error is caught in the main event loop, we can unload most of the segments
at that time, and therefore can be pretty confident about not running out
of memory while reporting the error.
We make it easy to check for errors by defining procedures such as FailOSErr
(takes an OSErr and calls Failure if < 0), FailMemErr, and FailNIL. With
this mechanism you just naturally write statements like
FailOSErr(FSWrite(...)). Also, this mechanism makes your main-line code
cleaner; there are not a lot of IF err <> noErr THEN ... tests in your code.
The Failure procedure takes an error code and a 4-byte message. The message
is looked up in a table (stored in a resource) to get an operation string
(eg., 'save the document'). There is also a special case in which the
message refers to a menu command; then the operation string becomes
'complete the "xxx" command'.
The error code is looked up in 2 tables (also in resources). The first
gives a reason for the error (eg., 'the disk is locked'), and the second a
recovery (eg., 'Eject the disk and move the little tab.'). I have found
only about 7 messages that make any sense to report, but you could use the
Resource Editor to report more specific (or terse) errors.
MacApp puts all these strings together in an alert that reads 'Could not
save the document because the disk is locked. Eject the disk and move the
little tab.'
In most cases, MacApp will supply all the parts of the error message; the
programmer only has to diligently check for errors and call Failure as
needed. In some cases, you will define new operation or reason strings, but
MacApp still takes care of putting them together and displaying the alert.
This whole alert mechanism is triggered by a call to a method, so that you
can completely override it (to do your own lookups) without changing the
MacApp source code.
If you have any questions or comments let me know.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
------------------------------
Date: 28 Jul 86 19:14:32 GMT
From: ucbcad!nike!caip!seismo!gatech!gt-eedsp!owen@ucbvax.berkeley.edu
From: (Owen Adair)
Subject: Mac serial port
Sender: info-mac-request@sumex-aim.arpa
[line eater line eater]
I am looking for info on how to initialize the serial port on the Macintosh
for baud rates below 110 baud. Help!
Any language including basic (snicker snicker)....
--
Owen Adair, Digital Signal Processing Lab, Ga. Institute of Technology
uucp ... !{akgua,allegra,hplabs,ihnp4,seismo,ulysses}!gatech!gt-eedsp!owen
Disclaimer: My employer is not responsible for, nor does it care, what I
say here or anywhere else.
------------------------------
Date: 29 Jul 86 16:30:48 GMT
From: ucbcad!nike!sri-spam!mordor!jdb@ucbvax.berkeley.edu (John
From: Bruner)
Subject: Re: Mac serial port
Sender: info-mac-request@sumex-aim.arpa
>I am looking for info on how to initialize the serial port on the Macintosh
>for baud rates below 110 baud. Help!
According to *Inside Macintosh*, the baud rate is established by
performing a SerReset on the driver. The low 10 bits of the parameter
specify the baud rate (the 6 bits control character size, parity, and
stop bits). This 10-bit number is a timing constant. Although Apple
provides the values for the standard baud rates from 300 to 57600,
they don't indicate how these values are computed.
(Aside: This was a really poor design decision. Not only is the
programmer interface horrible, but these magic numbers are tied to
the serial chip and clock rate used in the Macintosh. If Apple ever
wants to use different hardware then we'll all lose (again). They
should have used, say, 5 bits to encode all possible baud rates and
used a table lookup in the serial driver to determine the correct time
constant.)
I don't have a copy of the data sheet for the Zilog 8530, but it appears
that the baud rate constants obey the formula
(2 * 57600) - 600
time_constant = round ( ----------------- ) - 2
baud_rate
According to this, the time constant for 110 baud should be 1040.
Since the field in the SerReset() argument is only 10 bits wide, the
maximum time constant that can be specified is 1023.
The discrepancy is 17/1040 or 1.6% Multiplying by 11 (start bit,
8 data bits, 2 stop bits), this means that the Macintosh will differ
from true 110 at the end of the last stop bit by 0.18 bits.
(BTW, 134.5 baud is possible, if anyone wants that. :-)
I hacked up a copy of my UW program to allow it to run at the lowest
possible baud rate. From my understanding of the way that UARTs work, I
expected it to be able to receive OK at 110 (since they try to sample
near the middle of the signal bits, allowing for some slop). As I
expected, I was able to talk to the VAX here. (Life at 110 baud is
really depressing.)
I don't know whether or not the Mac can communicate with the standard
110 baud device, the model 33 Teletype (assuming that the current-loop
vs. EIA issues are dealt with). I do not know what sort of tolerance
the [AK]SR-33 has to timing errors. (I fear that it won't be very
tolerant, since it is mechanical and it "knows" that its line frequency
is exactly 60Hz.) A secondary effect of the Mac running slightly fast
is that there will effectively be 1.8 stop bits instead of 2.
I assume that the Mac uses the Z8530 in divide-by-16 mode. If so,
it may be possible to reduce the baud rate by a factor of 4 by
putting the chip in divide-by-64 mode. However, you'll have to
write to the device register directly, and I can't speculate about
how that will work if the serial driver is also periodically
writing the register.
I suppose you could use external clocking to achieve a lower baud
rate.
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
------------------------------
Date: 28 Jul 86 20:55:48 GMT
From: ucbcad!nike!caip!im4u!ut-sally!seismo!rochester!ur-tut!jtyd@ucbv
From: ax.berkeley.edu (Ty Dibble)
Subject: Re: LaserWriter 3.1 bombs with Excel chart.
Sender: info-mac-request@sumex-aim.arpa
In article <869@tekcbi.UUCP> larryh@tekcbi.UUCP (Larry Hutchinson) writes:
>
>Like the subject line says. The LaserWriter file was from a dealer and had
>been used for quite some time with no problems. Excel had no problems printing
>worksheets. Reverting to 3.1b9 fixed the problem! Any comments?
>
>Larry Hutchinson, Tektronix, Inc. PO Box 500, MS 02-305, Beaverton, OR 97077
>{ decvax,allegra }!tektronix!tekcbi!larryh
Although probably this was not Larry's problem, it is -IMPORTANT- to note that
the various Laserwriter Files are NOT!!! compatible. That is>if you are using
a particular version of LaserWriter you can NOT start using another version
without rebooting the LaserWriter and loading in the new LaserWriter File. Yes
it is documented but is hidden more than necessary.
In short you can not have different people working with different versions of the LaserWriter Files compatibly. Good Luck.
J. Ty Dibble
jtyd
------------------------------
From: caip!unirot!gjb@seismo.CSS.GOV
Date: Tue, 29 Jul 86 02:28:45 edt
Subject: RedRyder 9.2 Term Emulation Problem
I have had the opportunity recently of using RedRyder 9.2 (which, by
the way, is the best terminal emulation program for the Mac) on a
9600 BPS line. I first noticed a problem when using TOPS20 EMACS:
When displaying screens of text, all the text comes out indented to
about the middle of the screen. I also noticed this problem at 4800
BPS. The next day, I discovered it at 1200, so it can't be just a
problem with the high speed.
So far, RedRyder 9.2 works fine at 9600 BPS with some rather
screen-intensive programs for TOPS20, including Rogue and a game that
shows animated films. It also works fine with Unipress EMACS (a
version of Gosling EMACS). I've never had this problem with SmartCom
II, which I used to use until I got RedRyder.
I suspect this is an idiosyncrasy between TOPS20 EMACS and RedRyder.
Could someone else try this out (there aren't a whole lot of DEC-20s
around these days) and see if they have the same problem? It's
annoying. Also, does anyone know how I can get in touch with Scott
Watson, the author of RedRyder, without actually having to use a
phone? That would be so archaic...
-Greg
------------------------------
Date: 29 Jul 86 03:00:30 GMT
From: decwrl!herdeg@tallis.dec.com@ucbvax.berkeley.edu (Mark Herdeg,
From: DTN226-6520)
Subject: Re: RedRyder 9.2 Term Emulation Problem
Sender: info-mac-request@sumex-aim.arpa
...
>9600 BPS line. I first noticed a problem when using TOPS20 EMACS:
>When displaying screens of text, all the text comes out indented to
>about the middle of the screen. I also noticed this problem at 4800
>BPS. The next day, I discovered it at 1200, so it can't be just a
>problem with the high speed.
...
>I suspect this is an idiosyncrasy between TOPS20 EMACS and RedRyder.
>Could someone else try this out (there aren't a whole lot of DEC-20s
>around these days) and see if they have the same problem? It's
...
I can verify that I've observed the same thing. Red Ryder now emulates a
VT100 perfectly for everything I've tried except TOPS-20 EMACS. I've
observed the same behavior--lines with strange indentions at the middle
or even far right of the screen. I assumed it was some kind of strange
optimization using one of the advanced VT100 cursor control functions
which Red Ryder doesn't emulate exactly right. I usually just use VT52
emulation when I'm running emacs on TOPS-20.
You can communicate with Scott Watson on Genie. You get a free account
when you send in your Red Ryder registration, and then it's only $5.00
per hour evenings and weekends. The latest versions of RR can also be
downloaded from there.
Mark Herdeg
------------------------------
Date: 29 Jul 86 02:12:59 GMT
From: uwvax!husc6!endor!mazur@ucbvax.berkeley.edu (Eric Mazur)
Subject: Duplicate Resources in System File
Sender: info-mac-request@sumex-aim.arpa
This is something that has come up before, but I would like to have more
info.
The new ROMs contain several resources that used to be (and *still* are) in
the System file. In this month's MacUser the 'MacTeam' answers a question
from a reader who wonders what resources he can remove from the System file.
According to the article the resources that are both in ROM and in the System
file are:
DRVR 2, 3, 4, 9, and A
SERD 0
MDEF 0
WDEF 0
PACK 4, 5, and 7
CURS 1, 2, 3, and 4
FONT Chicago
The article does not guarantee that this list is complete, but "it's more
accurate then Technical Note #57". [This note is missing from my set, so I
could not check].
But then comes a sentence that makes me worry: "Theoretically you could remove
these, but Technical Support doesn't recommend doing so. There may well be
some applications that expect to find these as RAM-based resources." [What
good is it then to have them in ROM?!].
Has anyone removed these resources? Did you encounter any problems?
I have a related question concerning PACK 0. David Dunham (how can I reach
him from Usenet?) told me my problems with MiniWriter were due to the
presence of the PACK 0 resource in the System file. So I removed it, but
I got a whole series of new problems. Printing didn't work, the system
bombed now and then. I ended up putting it back and most of the problems
went away. What is PACK 0 for? I tried finding a reference in Inside Mac,
but couldn't find any. Throw it out too, or leave it?
Eric Mazur
_A_R_P_A_-_N_E_T: mazur@harvard.harvard.EDU
_B_I_T_N_E_T: mazur@harvunxh.bitnet
_U_U_C_P: /----- mazur
/ /--- _d_a_s_y!mazur
{seismo,harpo,ihnp4,linus,allegra,ut-sally}!_h_a_r_v_a_r_d! ------
\ \___ _l_a_s_e_x!mazur
\_____ _m_o_l_p_h_y!mazur
------------------------------
Date: Mon, 28 Jul 86 23:11 EDT
From: Paul Christensen <PCHRISTENSEN%rca.com@CSNET-RELAY.ARPA>
Subject: Duplicate Resources in System 3.2
In response to Kathleen Huddleston's question:
> I have upgraded my Mac with the new ROMs and new system (3.2). I also
> am using a HD20 in addition to the 800K drive. Do I need the HD20
> driver in my system folder on the Hard disk, or is this already
> bundled in the ROMs or System 3.2? Also, I have heard that AppleTalk
> is in the new System and new ROMs. Therefore, do I need the separate
> Apple Talk driver as well? While I'm at it, do I need the software
> version of the Chicago font in my System Font file?
>
> If I can remove any of these, it would be nice to do so.
Apple's 128K ROM includes many resources and packages previously part of the
system file. For a VERY complete description of the contents of the new 128K
ROM found on the MacPlus and the Mac512enhanced, see Apple's Macintosh
Technical Note #57: "Macintosh Plus Overview" Written January 8, 1986.
Apple's new 128K ROM has MANY improvements and additions over the previous
64K ROM. Generally, many stable routines previously included in the system
file were recoded and placed in the ROM, vastly increasing speed.
The entire Hard Disk 20 driver, which includes HFS, is in ROM. The only
purpose of the Hard Disk 20 document is to provide Macintosh owners with the
old (64K) ROM the ability to run HFS and the HD20. Since this is in the new
ROMs, you may remove it from your system folder.
Unfortunately, Apple had made a full compatibility commitment to the 512K
machine and had to produce system files that worked on both the old (64K ROM)
and new (128K ROM) Macintoshes. That is why the following resources are still
included in the system file. Darin Adler, author of the "NoQuiche" INIT
resource suggests that the following resources may safely be removed from the
system file without ill effect:
DRVR 2 '.Print' (in ROM)
DRVR 9 '.MPP' (Apple Talk, in ROM)
DRVR 10 '.ATP' (Apple Talk, in ROM)
FONT 0,12 (Chicago Font, in ROM)
MDEF 0 (standard scrolling MDEF, in ROM)
PACK 4,5 (SANE floating point packages, in ROM)
PACK 7 (binary-decimal package, in ROM)
PTCH 105 (patch for old 64K ROM)
PTCH 28297 (patch for MacWorks)
WDEF 0 (standard WDEF, in ROM)
Apple's tech note #57 also lists the following resources as being in the new
ROM:
DRVR 4 '.Sony'
DRVR 3 '.Sound'
SERD 0 (serial drivers)
CDEF 0 (button)
CDEF 1 (scroll bar)
*** HOWEVER, my suggestion is that you NOT remove these resources from the
system file. First of all, whenever Apple releases a new system, your work
will have gone to waste, and you'll have to remove these resources again.
Secondly, your system file will in no way work under the old 64K ROM.
Thirdly, the grand total of the above-listed resources is only about 35K,
certainly no real gain when using a hard disk or 800K disk.
I recommend that you only remove the Hard Disk 20 document from your system
folder, since you are using a Mac Plus. Generally, it's a good idea not to
remove resources that Apple has chosen to include in their system file.
- Paul Christensen
CSNET Address: PCHRISTENSEN%HENRY@RCA.COM
------------------------------
Date: 28 Jul 86 20:54:00 GMT
From: ucbcad!nike!caip!seismo!mnetor!utzoo!utcs!oscvax!ron@ucbvax.berk
From: eley.edu
Subject: using Videoworks animations from another program
Sender: info-mac-request@sumex-aim.arpa
We are using the Videoworks package from Hayden Software to create
animations on the Mac. We would like to be able to display animations
that were created with Videoworks from another Mac program that we will
write ourselves. Does anybody know of anyway to do this? I heard
somewhere that the people that wrote Videoworks also have some kind of
routine or resource that you can put into your program that will display
Videoworks documents. Has anybody ever heard of such a thing and if so
where could I get it? Calling Hayden Software directly came up empty.
The "About Videoworks..." menu item mentions a company called MicroMind
Inc. Does anybody know how I could get in touch with this company
directly? Hayden wouldn't even divulge this highly classified piece of
information.
Thanks,
--
Ron Janzen
Ontario Science Centre, Toronto
...!{allegra,ihnp4,decvax,pyramid}!utzoo!oscvax!ron
------------------------------
Date: 29 Jul 86 02:28:48 GMT
From: ulysses!gamma!epsilon!mb2c!jed@ucbvax.berkeley.edu (John
From: Duncan)
Subject: Making Folders Invisible on HFS
Sender: info-mac-request@sumex-aim.arpa
...
Is it possible to make a Folder on HFS "invisible"? If so, how. This could
be the start of at least some form of security for hard disk owners -- eg.
before you power off your machine, you activate a DA that secures the system
by making all of the highest level folders and documents invisible. When you
reboot, the startup application would ask for your password which would be
stored in an invisible file. No password, nothing to see. Even booting up
with a normal floppy would not appear the desktop. Sure, I know it can be
beat, but its a start and would keep novice snoopers away.
Any other security ideas would be greatly appreciated. For example, do any
of the SCSI hard drive manufacturers offer a keylock power-on switch?
John Duncan (mb2c!jed) Michigan Bell (313) 424-1167
------------------------------
Date: 28 Jul 86 21:40:00 GMT
From: ucbcad!nike!caip!pyrnj!mirror!prism!authorplaceholder@ucbvax.ber
From: keley.edu
Subject: Re: Efs on a MacPlus
Sender: info-mac-request@sumex-aim.arpa
If EFS is what I think it is (using a VAX to act as a File Server for the
mac) , how can I get this for our installation ? I am not really concerned
about the bugs, as long as there is the potential for getting at the source
code too!
We have a few macs, and they could stand hooking up to the VAX to perhaps
use the solitary laserwriter we have there....
THANKS!
brian
----
brian {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA, 02140
Telephone: 617-661-0777 extension 141
(((((((( * ))))))))
------------------------------
Date: 29 Jul 86 04:35:00 GMT
From: tektronix!reed!bart@ucbvax.berkeley.edu (Bart Massey)
Subject: Re: Mac Cache
Sender: info-mac-request@sumex-aim.arpa
In article <2017@calmasd.CALMA.UUCP> cjn@calmasd.UUCP (Cheryl Nemeth) writes:
> Does the cache do an automatic write-through all the time?
As near as I can determine, the answer is no.
> It seems like
> it would be very dangerous to use if it doesn't.
Yup, I and others don't ever enable it. It's frightening to think how a
non-write-through cache works with novice users, who don't know enough
to turn it off... How hard would it really have been for apple to
make the write-through *optional*, like the cacheing itself?
Bart Massey
UUCP: ..tektronix!reed!bart
------------------------------
Date: Tue, 29 Jul 86 11:29 PDT
From: PUGH%CCX.MFENET@LLL-MFE.ARPA
Subject: Disk space
I am trying to calculate where my hard disk went (it's only been a month!) and
something doesn't quite seem right. I have traversed the HFS structure and
added up all the file sizes for the entire disk and still come up short a Meg
from the number that Get Info returns. What I am using are the ioFlPyLen and
ioFlRPyLen fields returned in a CInfoPBRec returned from the PBGetCatInfo call.
This gives me the physical size of the data and resource forks, which should
be the complete size of the file. However, something seems to be missing.
Are there tag blocks that I need to add on or something? Any gurus feel like
filling the rest of us in?
Jon
------------------------------
Subject: Autoblack documentation
Date: Tue, 29 Jul 86 12:12:54 -0800
From: Kathleen Huddleston <gregory@ICSE.UCI.EDU>
Autoblack was posted, but the documentation was not. Here it is:
[ note from moderator: Since the autoblack application was never a DA
it has been renamed as:
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-AUTOBLACK.HQX
the docs file is now posted and is called:
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-AUTOBLACK.DOCS
DAVEG
]28-Jul-86 17:38:00-PDT,1306;000000000001
------------------------------
Date: 28 Jul 86 14:59:42 GMT
From: ucbcad!nike!topaz!husc6!ut-sally!seismo!mcvax!nikhefh!i91@ucbvax
From: .berkeley.edu (Fons Rademakers)
Subject: Info about MacEqn wanted.
Sender: info-mac-request@sumex-aim.arpa
I would like to have some more information about MacEqn.
Is this program comparable with the Unix eqn ?
If so, where can I get it ?
Regards,
Fons Rademakers.
NIKHEF-H, National Institute for Nuclear and High-Energy Physics.
UUCP: {decvax,cernvax,okstate,garfield,philabs,seismo}!mcvax!nikhefh!i91
p-mail: Nikhef-H \ /
Kruislaan 409 \__________/
P.O. Box 41882 / \
1009 DB Amsterdam - Netherlands / \
[ note from moderator: The MacEqn equation processor is a product
of Software for Recognition Technologies, 110 University Park
Rochester, NY. 14620 716-461-0923
DAVEG
]29-Jul-86 06:04:03-PDT,838;000000000001
------------------------------
Date: Tue, 29 Jul 86 08:53 EDT
From: Thomas D. Schardt <K3TDS%SCFVM.BITNET@WISCVM.ARPA>
Subject: TOPS by Centram Systems West
I am interested in networking Macs, PCs, and PC compatibles with a
LaserWriter and some kind of harddisk. A friend mentioned TOPS, a
product of Centram Systems West. I would like to hear from anyone
who has seen and/or used TOPS.
Thomas D. Schardt BITNET: K3TDS@SCFVM
Goddard Space Flight Center ARPANET: K3TDS%SCFVM.BITNET@WISCVM.WISC.EDU
------------------------------
End of INFO-MAC Digest
**********************