jm7e+@andrew.cmu.edu (Jeremy G. Mereness) (11/18/89)
There has been a lot of talk about an HFS FST, DOS FST, that sort of thing, and the argument is whether it would be supported. From what I have seen, it doesn't matter. If I had the time, I would try going at such a beast myself, as my school is saturated with Macs and Apple File Exchange stinks (15 minutes for 400K on a Mac //). I am busy trying to remain a student and a GS version of Mac/IP. Some fella over at Stanford reasoned that Appletalk packets were flying over the Ethernet through the Gateway, why couldn't Macs send TCP packets through that Gateway to become TCP/IP clients? Apple didn't have an TCP driver for the Mac system. They probably wouldn't have been very hip to developing one, either. So he/they built their own into the program Mac/IP. It was so successful that now Apple, in system 6.0.3, included a wholly new and supported TCP driver with system 6.0.3. The Stanford team then rewrote Mac/IP to work with the new standard. It is unlikely that Apple will ever get around to such a thing for the Apple //gs, so I am writing it myself. System 5.0.6, 5.2, or 114.5 somewhere down the line may make it crash, but I'll either update the program or stick to a system that works. The same applies to FST's: If you have the means and the will to write a HFS FST, then DO IT and don't mind the talk on this net. If you write it, people will use and love it. If it doesn't work with the next system, then people will use the old system until there is an update, or Apple sees the error of its ways. Don't be afraid to hack. It's the American thing to do. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Jeremy Mereness | Support | Disclaimer: | | jm7e+@andrew.cmu.edu (internet) | Free | The above represent my | | r746jm7e@cmccvb (Vax... bitnet) | Software | opinions, alone. | | a student at Carnegie Mellon U. | | Void where prohibited. | -----------------------------------------------------------------------------
mattd@Apple.COM (Matt Deatherage) (11/18/89)
In article <EZN5Ewm00XcP87UIJd@andrew.cmu.edu> jm7e+@andrew.cmu.edu (Jeremy G. Mereness) writes: > >The same applies to FST's: If you have the means and the will to write >a HFS FST, then DO IT and don't mind the talk on this net. If you >write it, people will use and love it. If it doesn't work with the >next system, then people will use the old system until there is an >update, or Apple sees the error of its ways. > >Don't be afraid to hack. It's the American thing to do. > >Jeremy Mereness There's a distinct difference between doing something the system does not do (like writing a new networking protocol or a user toolset for your application) and doing something reserved for the system (like writing an FST or stealing a system toolset number). Although people writing their own FSTs (hacking them out) might find something that's useful to them and others, the fact remains that there are basic differences between file systems, and applying an abstract system to a real, physical file system can result in unforeseen difficulties that would require changes to GS/OS. *Even if this were not true*, there are other problems. If I write an HFS FST that handles GS/OS attributes one way (suppose I keep the file type and the auxiliary type in the file type and creator type fields, instead of doing the filetype translation that Apple's done in Apple File Exchange, DuplicateIIgs and the AppleShare code) and Apple releases an HFS FST that handles these attributes a *different* way, most of the world is going to use Apple's way, especially the major developers. Then people who have been using my FST suddenly have several disks (or worse, a hard drive) full of information that they have no way to translate into something the world uses (you can't let GS/OS translate it; you can't have two FSTs for one volume). >If it doesn't work with the >next system, then people will use the old system until there is an >update, or Apple sees the error of its ways. This argument implies that when there is more than one way to do something, Apple will cave in and adopt the way that the first person did it. This is pretty far from likely. Apple learned their lessons about letting developers dictate the entire course of implementation when DOS 3.3 became unmanageable because the entry points couldn't move. Apple will probably do things the best way they know how, not the way they've always been done. -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
dkl@pro-houston.cts.com (David Karl Leikam) (11/23/89)
In-Reply-To: message from mattd@apple.com In CS-ID: #2843.cortland/info-apple@pro-houston, mattd@apple.com (Matt Deatherage) writes; > There's a distinct difference between doing something the system does not do > (like writing a new networking protocol or a user toolset for your > application) > and doing something reserved for the system (like writing an FST or stealing a > system toolset number). Yes, there's a difference. But _why_ reserve writing FST's, for the system? The toolset numbers are a different case, but the FST's seem like the software analogy to a hardware mass-storage device or disk drive. Does it make any sense to say "Nobody can build a harder for Apple but Apple?" >Although people writing their own FSTs (hacking them out) might find something >that's usefl to thm and others, the fact remains that there are basic >differences between file systems, and applying an abstract system to a real, >physical file system can result in unforeseen difficulties that would require >changes to GS/OS. Well and good, but why can't we call that (changes to GS/OS) a "boundary", past which said third party cannot go, and leave it at that? This seems to me to make good sense: "Here are the FST guidelines and interface points. If what you're trying to do requires any change beyond this, you're S.O.L., as far as Apple Computer is concerned. Other tthan that sort of change, happy hacking." Then, leave it up to the hackers to find a way, or work around the gguidelines as stated. Wouldn't this meet the objection? Unless, of course, you're saying that there's _Nothing_ stable about FST structures and interfaces, in which case, back to my original question: why split 'em out from the OS itself? If they must change every time the OS changes, then what we have are little better than patches, or hacks into the original code. Why dignify this with an implied structure and order that ain't there? >*Even if this were not true*, there are other problems. If I write an HFS FST >that handles GS/OS attributes one way (suppose I keep the file type and the >auxiliary type in the file type and creator type fields, instead of doing the >filetype translation that Apple's done in Apple File Exchange, DuplicateIIgs >and the AppleShare code) and Apple releases an HFS FST that handles these >attributes a *different* way, most of the world is going to use Apple's way, >suddenly have several disks (or worse, a hard drive) full of information that >they have no way to translate into something the wold uses(you can't let >GS/OS translate it; you can't have two FSTs for one volume). In such a case, and if there's a really impossible incompatibility, why wouldn't such a person merely keep using the old FST, and just not install Apple's new one? And as for having multiple volumes/harders full of incompatible files, why exactly would this happen? The whole point of the exercise is to move something over to, say, the Mac, in order to use it there. Suppose this is a font we're talking about, for example. The original GS version is unchanged, and it continues to work just fine with old or new GS/OS. The translated version is over on the Mac, and it works just fine with Finder, regardless of version. Where is the problem in exactly _how_ it got to the Mac? The point is to use this ffont on the Mac, not to make sure you can somehow yank it back. Why would you want to? And if it's adhered to Finder specifications well enough that it's useable, why wouldn't it be _possible_ to pull it back with the new FST, anyway? Am I missing something? UUCP: crash!pro-houston!dkl ARPA: crash!pro-houston!dkl@nosc.mil INET: dkl@pro-houston.cts.com
cwilson@NISC.SRI.COM (Chan Wilson) (11/25/89)
Watching this recurring thread, I wonder: How many of those people out there complaining about the 'close-minded' attitude that Apple has regarding FST's are actually programmers? Think: All ( >:-) you have to do is reverse-engineer the code and determine what the format of an FST is. You've got the code right in front of you... what's stopping you? (Just thought I'd toss some more wood on the flames...) ................ Chan Wilson -- cwilson@nisc.sri.com <or> cwilson@nic.ddn.mil 'A computer operator at SRI International' (X windows hacker) "Nuts to all that X,Y,Z modem mess. I'm gonna build me a FTP emulator." ................