johnmac@fawlty.towers.oz (John MacLean) (09/11/89)
Remember this from Dave Lyons: >Device drivers are a long-standing and fairly traditional concept. Their >implementation in GS/OS is stable, so that any properly-written device > driver will continue to work with future versions of the System Software. >Device drivers interact with the system in permanently-defined ways (the >implementation can be *extended*, but it can't ever change radically). >File System Translators aren't quite like that. With each System Software >revision, changes may be required to any or all of the existing File System >Translators, and other parts of the system may need to be revised to deal >with a file system which previosly had no FST. >Since defining for all time how FSTs work could limit the choices in designing >any future versions of GS/OS, the policy on FSTs is that Apple writes them all. I have heard this before on my long quest for FSTs - I do not understand (believe?) this justification. My understanding is that GS/OS calls FSTs, and the FSTs call the device drivers. Thus there are 3 interfaces: - Application to GS/OS: cannot be changed for compatibility - GS/OS to FST: this is what apple does not want us to know about - FST to device driver: cannot be changed as you stated Surely what an FST does is well enough defined to provide details of the second interface (there are already 4 FSTs that I know of). Support for open a file, write to a file, read from a file, get a directory entry, translate a filename etc, etc must be provided. At worst an extendable interface should be provided (eg: number of parms for this call as in GS/OS, and or the flexibility to add more calls). With such an interface there would be no expansion problems (at least minimised). Apple must be using such an interface simply for there own development purposes. I have a genuine need for FSTs (MAC, DOS 3.3 and custom FSTs) for The Graphic Exchange (GS/OS version), and must take a backward step by not providing direct support for DOS 3.3, Macintosh, and Newsroom. I have the code to implement FSTs if I only new the interfaces - and it should be a fairly simple job. Apple has not provided FSTs for MAC or DOS 3.3 and will not release the doc's so I cannot write my own - I am frustrated ... Why has Apple released a CD-ROM FST and an Appleshare FST but has not provided DOS 3.3, or MAC (MAC should be very simple given the back end of the Appleshare FST could be copied)? I would think there are more users out there that have access to DOS 3.3 and MAC disks than there are that have CD-ROMs or Appleshare networks connected to there GSs - so priorities are at question ... Are there any comments or suggestions from the viewers to ease my frustration ... John MacLean -- Internet: johnmac@fawlty.towers.oz.au Phone: +61 2 427 2999 UUCP: uunet!fawlty.towers.oz.au!johnmac Fax: +61 2 427 7072 Snail: Tower Technology 31-33 Sirius Rd, Lane Cove, NSW 2066, Australia.
farrier@Apple.COM (Cary Farrier) (09/29/89)
In article <404@fawlty.towers.oz> johnmac@fawlty.towers.oz (John MacLean) writes: >Why has Apple released a CD-ROM FST and an Appleshare FST but has >not provided DOS 3.3, or MAC (MAC should be very simple given the >back end of the Appleshare FST could be copied)? It's not that simple, because the Appleshare FST knows nothing about the HFS disk structure used on Macintosh volumes. The AppleShare FST is a front end to a protocol called AFP (AppleTalk Filing Protocol), which is a high level network protocol consisting mainly of commands such as "create a new file" or "duplicate this file". These commands are sent to a file server via AppleTalk, which then does what it pleases with them. The file server doesn't need to be a Macintosh, it just has to know how to speak AFP. Cary Farrier -- +--------------+-------------------------+ | Cary Farrier | farrier@apple.com | +--------------+-------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/30/89)
In article <4454@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: > It's not that simple, because the Appleshare FST knows > nothing about the HFS disk structure used on Macintosh > volumes. Ah, but the Appleshare/HFS translator on the Mac does! IIGS : appleshare : HST ^ ^ use the Mac's have this Not that I think that's a good way to implement it; I don't. I'd rather have the DOS 3.3 FST first, because most Mac disks are not of use in the IIGS environment.
mmunz@pro-beagle.cts.com (Mark Munz) (10/01/89)
Network Comment: to #11083 by gem.mps.ohio-state.edu!ginosko!aplcen!haven!adm!smoke!gwyn@tut.cis.ohio-state.edu -> -> I'd rather have the DOS 3.3 FST first, because most Mac disks -> are not of use in the IIGS environment. -> Ah, but there is a major use. Many people use both the IIGS and a Mac. It could be a Home/Work thing, or a Work/Work, or whatever, but people need to be able to read each others disks. The Mac can read Prodos disks with the help of AFE. I only hope the IIGS will be able to read Mac disks with the help of a Converter and Mac FST. --Mark Munz
blackman@phoenix.Princeton.EDU (Scott Michael Blackman) (10/02/89)
Does anybody remember the old MacTrans GS program, which converts (old) Macintosh MFS formatted disks? I pulled that out and found it wouldn't read past the second device in the SmartPort chain, so I rewrote the interface to use the new SmartPort interface. Now, it is very easy on my IIgs to use the conversion, and I always keep a few MFS disks around to save stuff on, when I'm working on a Mac. Easy conversions, right there, and it doesn't take up time on the Mac. The update includes (spacious and prob. unnecessary) error checking and removal of the two-device limit. Unfortunately, I haven't been in contact with the author, and I don't know if he would want modified copies of his program running around. Would anybody be interested in the fix? and is it OK for me to send it out? ________________________________________________________________________________ Scott Blackman, 103 Forbes College / Princeton University I have just discovered a proof of / blackman@phoenix.Princeton.EDU Fermat's Last Theorem! But it's / blackman@phoenix.UUCP, blackman@PUCC too long to fit in this .sig... / ...allegra!princeton!(phoenix|pucc)!blackman