Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site reed.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!pesnta!hplabs!tektronix!reed!bart
From: bart@reed.UUCP (Bart Massey)
Newsgroups: net.micro.mac
Subject: Re: Re: Junkware
Message-ID: <1813@reed.UUCP>
Date: Sun, 18-Aug-85 17:51:20 EDT
Article-I.D.: reed.1813
Posted: Sun Aug 18 17:51:20 1985
Date-Received: Fri, 23-Aug-85 08:16:23 EDT
References: <2957@seismo.UUCP> <481@oakhill.UUCP>
Organization: Reed College, Portland, Oregon
Lines: 30

In article <481@oakhill.UUCP> davet Dave Trissel writes:
>
> In article <2957@seismo.UUCP> mo (Mike O'Dell) writes:
> >
> >Correct me if I'm wrong, but if the little button on the disk is OPEN
> >the disk is write-protected, no??  ...
> 
> Well - sort of.  The problem is that it's only *SOFTWARE* write protected.
> It seems the Mac drives themselves do not inhibit writes no matter what
> the position of the tabs.  The Mac O/S gets a signal about the tab position
> and sets up flags which are supposed to not allow any writes.
> 
> So don't think the tab will protect you from program/machine malfunction.
> (I learned this the NASTY way.)
> 
> Here's hoping future Mac drives are smart enough to just plain refuse to
> write data if the tab says so regardless of what the OS tells it.  Of course,
> banning the bomb (i.e. memory protection so programs cannot clobber the OS)
> is a far bette solution.  Actually, both should be implemented.

I guess!  I CAN'T BELIEVE THIS!  Didn't the @#$% idiots who designed this
mess take hardware 101?  I guess the new DS drives may fix the problem,
and I guess machines with an MMU wouldn't necessarily have it (although
one would have to be awfully careful about what bit-copier software you
let have control of the system address space (how would a bit-copier
work on a memory-managed machine, anyway?)) but it sounds like we're
just stuck for now.  Thanks, Dave, for warning us of this...

				Bart Massey
				..tektronix!reed!bart