[comp.sys.apple2] DOS 3.3 FST long LONG

johnmac@fawlty.towers.oz (John MacLean) (07/06/90)

Nice to have you back on the net Matt.
I especially appreciate the depth of the response; it is certainly refreshing.
I could send this by mail, but I do believe there is enough interest in
FSTs to continue posting.

In article <42624@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes:
>In article <218@fawlty.towers.oz> johnmac@fawlty.towers.oz (John Mac) writes:
>
>GS/OS direct page is used through FSTs, SCM, and other Apple internal GS/OS
>components through a series of equates that are used to build the entire
>OS.  We could change one file and do a rebuild of the system and the entire
>system would continue to work. 

Some things cannot be changed, such as the driver calls, GS/OS calls,
and some parts of the direct page, since they are all documented.
Some things can, like the interface between GS/OS and the FST, the
rest of the direct page, and the FST header, since they are not documented.
Some things are quite likely to change, like some of the system service
calls, and their parameters, etc.

I guess if I (or anyone else) chooses to use these undocumented areas, then
there is a calculated risk that they will fail on future revisions of
system software.
With careful coding (using as few direct page locations as possible, not
using system service routines but rather your own routines etc), you can
really minimise these risks.
But, until Apple gives us either the documentation, or the FSTs, if we
want these features, they are risks that we are forced to take.

> [if Apple changes anything]
> Your FST, though, would probably eat disks for lunch.  Not good.

So to would all existing FSTs from Apple.
I would label my FST as a System 5.02 FST, just as you would.
If someone attempts to use my 5.02 FSTs, or Apples 5.02 FSTs, with a later
revision of the system software that is their problem.
Of course Apple has the advantage that they can test and release their
revised FSTs at the same time as the System Software.
I am likely to have a delay of a couple of months.

>"Oh my gosh,the capability has been present for two years and Apple hasn't done
>it yet.  They must not like Apple II people."  You know better than this, John.

I never said Apple does not like Apple II people.
Of course I know better than that.

>There's a lot more to releasing an FST than throwing some code together and
>hoping it works in general cases for all users of the OS. This is tricky stuff.
>>If nothing else, knowing that there are 'bad' FSTs out there might kick
>>Apple into releasing full-blown ones.
>Two FSTs for a given file system are worse than none. etc.

Exactly, and it is for this reason that Apple has to work very hard to make
FSTs available. It is also my justification for saying that if I (or someone
else) gets an FST working, Apple will want to have it squashed. Your reaction
brings this point out loud and clear.

>>Seeing how the things are implemented, I know I could get a fully
>>working FST out in the order of a couple of weeks full time (given
>>some minimal documentation).
>I'm glad you think so.  I wouldn't want to use it on real media.  I heard
>someone tell me once they could write the equivalent of ProDOS 8 in a couple
>of weeks, also.  My comment remains:  "Yeah, right."

I honestly believe I could put together an FST an get it out, as I put it,
in this time period. I also believe I could put together a ProDOS 8 compatible
operating system in a couple of weeks (with the interface specs and device
drivers provided).

You say "Yeah, right", because Apple could not do it. That is not because
Apple does not have skilled Engineers, it is because they have a reputation
to hold onto, they have millions of users out their, they can not afford to
let bugs slip through and thus must apply exhaustive tests.
I'm sure you could write the code just as well and just as fast (if not
faster and better) than I could; that's part of your job after all.
This of course leads to your next response:

>>You would think Apple could find the resources ....
>Programming resources aren't as tricky as testing resources.  If such a critter
>ever does get released, it has to be perfect the first time or "Apple doesn't
>care enough about the Apple II to fix the bugs."

This sums things up well.

> [Stuff about AE 3.5" drive deleted]
>>If they provide a driver, a MS_DOS FST would be just as easy now as well.
>>When we have MS_DOS, DOS 3.3, ProDOS, HS, MFS, AppleShare, and HFS FSTs,
>>we will all have a pretty awsome OS.
>
>This assumes the AE 3.5 drive reads MFM-formatted disks, which doesn't seem
>to be the case.

The adds tell me this is the case (it is superdrive compatible), but I have
yet to see it perform.

>
>>I bet you could sell GSs just as file transfer machines, running the finder.
>>I estimate that one person could probably get all of these going in a
>>couple of months.
>
>Nice try, but still wrong.  It only seems easy to you because you don't know
>all the stuff that's going on.  I don't mean to sound arrogant, but it's not
>as easy as disassembly would indicate.

Again, I said "one person could get these things going", I did not say that
Apple could get these things to a point where they could be released.
I recognise the difference, and I think it is important for others to.

>
>>John MacLean
>============================================================================
>Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are
>Developer Technical Support, Apple II |  not necessarily those of Apple
>Group.  Personal mail only, please.   |  Computer, Inc.  Remember that."
>============================================================================

I hold the belief that FSTs for the Macintosh will eventually win the Mac
the largest share of the business market.
Sharing data is THAT important.
People are going to buy a machine that allows direct (transparent) access
to everyones data.
The power to access ProDOS / MFS / HFS / High Sierra / MS_DOS / AppleShare /
and UNIX file systems transparently is an incredible thought.
Implementing all of these on one machine will isolate the machines future
from the low level file structure that eventually wins out.

Even on the Mac, Apple has the advantage that almost all catalog access
goes through the standard file toolset, and read/write/format/seek calls
are "fairly" file system independent anyway.
How much time have you wasted converting data and files?
I can measure mine in man-days or even man-weeks.

I love the IIGS, and would really like to see it have these capabilities
first (before the Mac), but it seems unlikely.
Apple obviously does not have the resources to do it on the II just yet,
I hope they will some day.
There are many people out here (including myself) who would really like
to work on these sorts of things, would probably do so very cheaply,
and are quite capable of supporting them.
Apple has several options for permanent or contract resources if they
ever decide it is worthwhile.

Until Apple does something, I can hardly be blamed for trying to do these
things myself.
I recognise the risks, but a read-only single file open at a time DOS 3.3
FST seems possible, so I will continue to work on it.

Regards, John MacLean.
-- 
This net: johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac             Fax:   +61 2 427 7072
Snail:    Tower Technology, Unit D 31-33 Sirius Rd,     Home:  +61 2 960 1453
          Lane Cove, NSW 2066, Australia.