Path: utzoo!attcan!uunet!jarthur!usc!apple!mattd From: mattd@Apple.COM (Matt Deatherage) Newsgroups: comp.sys.apple2 Subject: Re: DOS 3.3 FST Summary: Bad ideas don't improve with age Message-ID: <42624@apple.Apple.COM> Date: 3 Jul 90 22:54:38 GMT References: <218@fawlty.towers.oz> Organization: Apple Computer Inc, Cupertino, CA Lines: 92 In article <218@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >More importantly, I have worked out the calling protocols etc, so >it now seems quite likely that I could get the thing fully functional, >given enough time, even without any documentation. >A read only, single file open at a time, limited FST seems very likely. > >As I said in a previous post, there are two entry points. >One of these is just a GS/OS call passed on to the FST with the >X register = call number times 2. So for volume calls ($0008) you >get X = $0010. >The most important bit of info to get then becomes the direct page usage. >This info comes from several areas, including the GS/OS reference which >tells you how a driver should be called. >Other stuff, which comes mainly from disassembly includes: >$36 = device number, so this needs to be copied to $00 for the device call. >$32 = address of parms to class 1 call. >I use $80 for my own purposes (should be safe, as PRO.FST uses it). 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. Your FST, though, would probably eat disks for lunch. Not good. >If anyone out there has any of the Direct Page usage for GS/OS I would >really appreciate some mail. > All this stuff is unguaranteed and dangerous at best. We've just finished internally adding new parameters to some system calls, and all the FSTs had to be revised to take the new parameters accordingly. This is another reason why we keep this stuff in-house. >BTW, I was amazed at the amount of mail I got which had a general theme >of 'This is too difficult' or 'Too much is undocumented'. >This can be done, and if Apple won't do it then one of us had better. "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. 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. With two FSTs all of the file-system specific information (including option_list contents, handling of GS/OS abstract file system features that don't fit in a file system, handling of VCRs and FCRs (which the system will use without calling your FST to do it) during block writes, caching capabilities, etc.) is going to be different. This means you can no longer interpret file-system dependencies based on the file_sys_ID field, and this is not acceptable. Some programs would work correctly with one FST and not others; you'd have to reboot to switch programs. This also is not acceptable. >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." >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." >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. >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. >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." ============================================================================