Path: utzoo!attcan!uunet!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: Re: MacTransGS (Really: AFE has NO excuse)
Message-ID: <1990Mar6.124520.2130@spectre.ccsf.caltech.edu>
Date: 6 Mar 90 12:45:20 GMT
References: <17670@boulder.Colorado.EDU> <NAGENDRA.90Mar2193644@bucsf.bu.edu> <14221@phoenix.Princeton.EDU> <1990Mar4.074955.8430@ux1.cso.uiuc.edu> <39185@apple.Apple.COM>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 53

dlyons@Apple.COM (David A. Lyons) writes:

>In article <1990Mar4.074955.8430@ux1.cso.uiuc.edu> cs122aw@ux1.cso.uiuc.edu (Scott Alfter) writes:
>>On the subject of Apple File Exchange, I think the way the HFS-->ProDOS
>>conversion is set up is criminal.  It takes FOREVER to copy a large file
>> [...] If Apple is using this as a tactic to get
>>people to move to the Mac, I think they'll cause people to wear out a lot of
>>Mac 3.5" drives first. :-)

>First, even given a higher-up with a "convert the II users" plan, I don't
>see how "Give them a way to convert Mac files into ProDOS files, but make
>it Really, Really Slow" is the plan they would come up with.

I'll keep my mouth shut. It's hard to answer that without some major flames
that I can't expect you to answer for.

>Second, I don't know any Apple engineers who would be willing to slow down
>their product on purpose.

So maybe they were inept. Or figured, oh, no one will ever want to go from a
Mac to ProDOS now will they? So why write it correctly when no one will ever
use it?

Please don't defend the author of the driver on virtue of his/her being an
Apple employee. Apple's employees do make mistakes. Even then, it is hard
to see how it could be possible that any disk driver would need to seek track 0
EVERY TIME IT WRITES A BLOCK!!! I seriously doubt that anyone can come up with
a valid reason for doing so on a write that does not also require it on a
read which (of course) has no such problem.

>Realistically, it's an engineering trade-off:  there's never a shortage of
>things that need to be done, and there are always optimizations that could
>be made.  Maybe people use AFE to copy large files to ProDOS disks more
>than was anticipated.

That's not the point; ANY FILE, size does not matter, is subject to this
treatment. If I got my hands on the source code I am willing to bet quite a
bit that I can figure out how to fix it. Of course, I'd have to sign gobs of
non-disclosure agreements in blood if I ever got the chance to do it...

>I have hope that it will be sped up in the future (I use it a fair amount
>myself).

Personally, I don't see how you put up with it. It has driven me to write my
own program (Basic/ML of course) to dump a disk into a big text file so I can
extract downloads from the disk image (HFS, you see, writes nice contiguous
strips when there is no fragmentation) instead of waiting for AFE to work out
the 3.5 drive and having to shut off the screen saver. Now that I have a
version of MacTransGS that works, rest assured that I will be using it and a
400K MFS disk and NOT AFE.

Todd Whitesel
toddpw @ tybalt.caltech.edu