INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator William J. Berner) (02/21/86)
INFO-MAC Digest Friday, 21 Feb 1986 Volume 4 : Issue 13
Today's Topics:
Multichannel Communications System
Usenet Digest Volume 2 Issue 10
Microsoft File Upgrade
System File Versions.
Re: V4 #9--Common Lisp for Mac
Info-Neon
SS vs DS Disks
Diskette verifier / flaw banisher?
Scavenging Disks
Ram Disks and the Mac Plus ?
INFO-MAC Digest V4 #12
MS-WORD Faux Pas
----------------------------------------------------------------------
Date: 15 Feb 86 21:00:56 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Multichannel Communications System
[ Uploaded from Delphi - Jeff ]
Name: MCS VERSION 1.0A
Date: 15-FEB-1986 13:53 by YVES
Version 1.0a of "Multichannel Communications System". This program will allow
simultaneous Upload, Download and Chat between two Macintoshes using Hayes
compatible modems. It uses X.MS, a windowing protocol similar to X.25 and
MacBinary format for file transfers.
-- Yves Lempereur [YVES]
[This can be found as [SUMEX]<INFO-MAC>MCS.HQX -- BB]
------------------------------
Date: 16 Feb 86 11:04:21 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Digest Volume 2 Issue 10
[NOTE FROM THE MODERATOR:
From now on, I will not post the delphi or usenet digests; rather,
I will post a summary of their contents, and the name of the
SUMEX file they are archived under. --BB]
Usenet Digest Sunday, 16 Feb 1986 Volume 2 : Issue 10
Today's Topics:
A 128K ROM and HFS Question
Re: Mac-modem pin configuration.
Re: A 128K ROM and HFS Question
Question on Hayes Smartmodem 2400 with Mac Plus
LaserWriter use with RamStart
SCSI <-> ethernet ?
of interest in INFOWORLD, Feb 3, 86
of interest in INFOWORLD, Feb 10, 86
Re: LaserWriter use with RamStart
Neeed help with transfering Multiplan to Chart
Re: Internal TextEdit fields
[More notes from moderator:
I have archived this digest in [SUMEX]<INFO-MAC>USENETV2-10.ARC
and have changed the other usenet digest that was archived so
that it follows this naming convention. --BB]
------------------------------
Date: Wed 19 Feb 86 14:38:44-PST
From: DBECK@SRI-KL.ARPA
Subject: Microsoft File Upgrade
Microsoft is offering an upgrade to their File program.
The cost is $10 and promises some improved functionality.
When you receive the product, what you actually get is a quantum
leap in copy protection and minimal upgrading. Doing a Hard Disk Install
(according to them) forever destroys the functionality of the master disk,
since it is a trapdoor process.
I do not believe it proper for Microsoft to involve the user in the
ever escalating game between protection creators and those devoted to
removing that expensive protection. Any suggestions on non-copy
protected File Management programs that are HFS compatible?
...doug beck dbeck@sri-kl.arpa
------------------------------
Date: Wed 19 Feb 86 14:40:22-PST
From: DBECK@SRI-KL.ARPA
Subject: System File Versions.
How does one know what the version number of the System File you are
running? Simple minded question, but I just cannot figure out wher
to look. Sorry. ...doug beck dbeck@sri-kl.arpa
------------------------------
Date: Thu 20 Feb 86 11:03:56-PST
From: Rich Alderson <ALDERSON@SUMEX-AIM.ARPA>
Subject: Re: V4 #9--Common Lisp for Mac
ExperLisp from Expertelligence is reputed to be a subset of Common Lisp for the
Mac, with additional functions for dealing with the Mac interface. (Note that
the Common Lisp people haven't defined any subsets of the language at this
time, so you would want to check into this before buying it.)
There are 3 other versions of Lisp that I can think of for the Mac: MacScheme,
by Semantic Microsystems; Mac PSL (Portable Standard Lisp), from the University
of Utah; and XLisp, available from David Betz at Harvard or the Info-Mac Digest
Archives.
There are in addition two versions (at least) of LOGO: ExperLogo by
Expertelligence, and MacLogo by LCSI(?), the people who produce one of the
better Apple II LOGOs.
There is a version of Common Lisp for IBM PCs and related machines, Golden
Common Lisp, from Gold Hill. I've heard good things about it, but haven't seen
it myself.
Rich Alderson
------------------------------
Date: Thu 20 Feb 86 13:01:18-MST
From: Tony Jacobs <T-JACOBS@UTAH-20.ARPA>
Subject: Info-Neon
Info-Neon is back on line after getting some problems sorted out. If
you should be on the list or want to join, then sent a request to:
Info-Neon-Request@Utah-20
There have been 4 posts so far this year.
News can be sent to: Info-Neon@Utah-20
------------------------------
Date: 20 Feb 1986 1223-PST
From: STERNLIGHT@USC-ECL.ARPA
Subject: SS vs DS Disks
In response to OBRIEN@LL's inquiry about SS vs DS disks, I have
considered this issue at length, and read the conversations on
Compuserve and Info-Mac. The most telling theoretical summary was
that manufacturers don't know, when making the media, which side will
end up facing the head. Thus both sides are made to the same
standards. It is stated, without proof, that SS disks are (take your
choice) DS disks that have failed their certification on the obverse
side, or that SS disks are DS disks that have not been tested and
certified on the obverse side (I suppose depending on the
manufacturer). One respondent on Compuserve suggested that even if
Mr. Maxell and Mr. Sony personally came to his house and buffed his
disk surfaces, he wouldn't trust even DS disks, and backs up
everything he isn't prepared to lose. Apple, in the Mac Plus manual,
warns in RED TYPE against using SS disks as DS. I suppose one issue
is how much it costs if you lose data (in aggravation, if not in
economic loss) compared to the cost of DS disks.
My own experience is that I have formatted about 50 SS disks as DS
disks; three failed initialization and of these, two initialized ok on
the second try. I HAVE ALSO HAD TWO DISK JAMS WITH THE MAC PLUS, ONE
IN THE EXTERNAL 800K DRIVE, AND ONE IN THE INTERNAL DRIVE. Both jams
were not correctible by paper clip in the hole removal, and
necessitated replacement of the drives by a service tech. Both were
with very early ss disks, bought when the 128k Mac first came out;
they were Apple disks. As a result, my policy is as follows:
I won't use white SS disks as DS under any circumstances. I won't use
Maxell disks; the shutters sometimes catch on the disk mechanism as I
remove them. I won't use Memorex disks; I have had bad experience
with them, and the BMUG tests are similarly unimpressive.
I will use those BLUE Sony and Fuji SS disks I have as DS on files I
have backed up. They are all manufactured in the past year and are
likely to be o.k. if they format o.k.
When they are gone, I will use only DS Sony or Apple disks. It is a
false economy to do otherwise. I already have three boxes of them.
Sony DS Disks (original packaging, same as in stores) can be bought by
mail for about $29.50 (plus $3 shipping) per box from a Campbell,
California firm called "Best Computer Supplies" that takes phone
orders, advertises in MacWorld (Feb '86 p.146), and gives a free 30
disk holder with every 3 boxes of disks. It took 3 days from the time
of my phone order for them to arrive by U.P.S. (I have no connection
with them except as a satisfied customer.)
Best;
David
------------------------------
Date: Thu, 20 Feb 86 14:03 PST
From: Dave Platt <Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA>
Subject: Diskette verifier / flaw banisher?
On the subject of diskettes... I have an idea for a utility program that
might be very useful... especially for folks who plan to use single-sided
diskettes in the two-side mode (not recommended by Apple, but some people
have been able to get away with it with relatively high success). I do
not have the facilities to implement such a utility here at my site,
so I'm tossing the idea out in the hope that someone out there will
bite, implement it, and distribute it as shareware.
The problem: diskettes sometimes go bad. For one or another reason
(wear, contamination, manufacturing glitch, etc.), sometimes one or
more sectors on a diskette will become impossible to read or write
reliably. Currently, you can either use these disks anyway [and get
the occasional I/O error and lost data] or throw them away. The same
sort of situation applies when you use a SS diskette in the new 800k
drives, and tell the Mac to initialize it as a DS disk... there may be
a few faulty or marginal sectors on the second side.
As far as I can tell, the "Initialize disk" package in the Mac does
not perform a whole lot of testing when it inits the disk. I've
reinitialized disks that had been causing problems; the initialization
completed just fine, but the problem was still there. There is apparently
no way within the Macintosh File System to identify certain sectors as
"bad", and to prevent their future use.
So... what I envision would be a format/test/flaw utility that would work
exclusively on diskettes. It would:
1- Call the Init Disk package, and erase the entire previous contents
of the disk.
2- Make several write/read passes over the disk (specifiable by the
user, probably). Data patterns would be written & read via direct
calls to the diskette driver, bypassing the file system. Any sector
that is not 100% reliable would be remembered.
3- If any I/O errors occurred in the critical portions of the diskette
(boot sectors if any, volume map, directory), then report that the
disk is unsafe to use, and stop.
4- Reinitialize the disk again [to recreate the volume map & directory
destroyed by the testing]
5- If there are any "bad" sectors on the disk, then create a locked,
protected, and invisible file on the disk; steal the sectors from
the volume map, and link them into the file.
6- Stop.
This procedure would seem to isolate any bad sectors... they would be
bound into a file which would never again be accessed.
Questions and issues that come to mind:
a) I've sometimes noticed that when I delete a number of files from one
diskette, and then copy another file to that diskette, the Finder
seems to be doing a LOT of disk I/O during the copy. I'm not sure
whether it's simply cleaning up the Desktop file [deleting old
INFO resources, etc.] or whether it's compacting the existing files
somehow... perhaps moving their allocation blocks down to the
"front" of the disk, and thus moving the "free" blocks to the "back"
of the disk. If the latter, then my scheme might not work... the
Finder might try to move the bad-sectors file to another place on
the disk, thus defeating the whole scheme. Does anyone know?
b) I'm not sure what tricks will be necessary to ensure that this
scheme will work with both the MFS and the newer HFS. It will
almost certainly require intimate knowledge of the file directory
structure... this is certainly dangerous, and could make this
program incompatible with future versions of the HFS.
Any takers? Comments? Brickbats?
------------------------------
Date: Thu 20 Feb 86 23:40:35-PST
From: Stanley Peters <PETERS@SU-CSLI.ARPA>
Subject: Scavenging Disks
Can anyone help me find out how to retrieve files from a MacIntosh
diskette that was inadvertently "initialized." The disk retained
it's name, but now shows as containing no files. I hope they are
still there, and a clever piece of software exists that will find
them and rebuild the directory or whatever is needed to make them
accessible again. Help or advice will be appreciated.
[You could get a copy of MacTools fro Central Point Software (I've seen
it sold for as low as $22.95). MacTools allows you to perform various
operations on files. More to the (central) point, there is an "undelete
files" option which should help with your problem. --BB]
------------------------------
Date: 21 FEB 86 10:28-EDT
From: KEOUGH%BCVAX3.BITNET@WISCVM.WISC.EDU
Subject: Ram Disks and the Mac Plus ?
Does anyone have patches to one of the popular RAM disk programs
to work on a MacPlus ? The Assimilation Mac Memory Disk puts
INIT resources into the system file if you "create a temporary
disk at startup" which cause an ID=14 bomb. Tony Nelson's
RAMSTART program (at least the version 1.21 I have) does most of
its startup sequence correctly until it copies the system onto the
ram disk, and then produces an ID=03 bomb [more than likely this
happens because it tries to launch the Finder from the ram disk,
but it can't find it (!) because it's up there in a folder and
HFS is in the way ].
Thanks,
Jerry Keough
Boston College
------------------------------
Date: Fri, 21 Feb 86 02:37:54 EST
From: Eric_Shapiro%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: INFO-MAC Digest V4 #12
A recent request:
POSTSCRIPT Language Tutorial and Cookbook ISBN 0-201-10179-3
POSTSCRIPT Language Reference Manual ISBN 0-201-10174-2
(both from Addison-Wesley)
------------------------------
Date: 21 Feb 86 10:44-EST
From: R.Rasulis <ext715%BOSTONU.bitnet@WISCVM.arpa>
Subject: MS-WORD Faux Pas
-----
Here's an interesting faux pas on the part of Microsoft:
Users of MS-Word, examine the cover to your WORD manual.
What do you see? Two people using a Mac. Look very closely at the Mac's
screen. You would expect them to be using WORD, but if you examine the
menu bar, it looks a lot like MacWrite to me...
*eom :- R.Rasulis -:
------------------------------
End of INFO-MAC Digest
**********************