gt0t+@ANDREW.CMU.EDU (Gregory Ross Thompson) (09/15/89)
> p.s. Why even make an AppleTalk FST?
Because some people use it. I happen to have a use for it. If you really
want to transfer files from a mac disk, use MacTransGS, or AFEx.
-Greg T.shankar@SRC.Honeywell.COM (Subash Shankar) (09/18/89)
In article <EZ409X200Ui0Q7C1Va@andrew.cmu.edu> gt0t+@ANDREW.CMU.EDU (Gregory Ross Thompson) writes: > ...If you really >want to transfer files from a mac disk, use MacTransGS, or AFEx. ^^^^^^^^^^^ What is MacTransGS? (hopefully something that runs on the GS) --- Subash Shankar Honeywell Systems & Research Center voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar
blochowi@rt3.cs.wisc.edu (Jason Blochowiak) (11/17/89)
In article <5205@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >In article <2634.cortland.info-apple@pro-houston> dkl@pro-houston.cts.com (David Karl Leikam) writes: >> [I deleted his article - he was asking about FSTs reason for existance] > *Using* an FST is _not_ the same as *writing* an FST! One of the >intracacies of creating an FST involves how closely it interacts with >the rest of the OS. Sometimes these details change in an OS revision. When >this happens, we can update the FSTs, but we can't update a 3d party FST. If everything were "the way it should be" GS/OS and the FSTs wouldn't be interdependent like they (apparently) are. GS/OS would serve as a front end, basically, to the FSTs. The application would make a call to GS/OS, which would figure out if 1) A device driver should handle the call, 2) GS/OS itself should handle the call, or 3) A FST should handle the call. Just as GS/OS provides some primitives for device drivers, it would provide some primitives for the FSTs - say, keeping track of lists of open files, which FST is responsible for them, etc. If the interaction were nice and neat (not an impossibility), then 3rd party FSTs would become completely possible. I'm not aware of the details regarding the time requirements the OS design crew was under, but that's not what bugs me. What bugs me is that it seems that the folks from Apple that are active on the net are saying "There's nothing wrong with this." Perhaps I'm misinterpreting what they're saying, or perhaps it's just a defensive reaction - I dunno. But, if someone from Apple were to say "Yes, by gosh, the way FSTs were implemented was a design botch." I, for one, would shut up about them (except, perhaps for a "Well, now the mistake has been recognized, will it be fixed?" ;). Of course, despite the fact that FSTs, as implemented, don't provide a file system panacea, they still are useful in terms of letting the user select the amount of memory/disk space that will be used by them (as Dave Lyons, methinks, pointed out). Anyone with the urge to flame me should probably do so by email. > [Deleted paragraph with an analogy] >Cary Farrier -- Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp "Education, like neurosis, begins at home." - Milton R. Sapirstein
steven@enel.ucalgary.ca (Steven Leikeim) (12/06/89)
In article <3762@puff.cs.wisc.edu> blochowi@rt3.cs.wisc.edu (Jason Blochowiak) writes: >In article <5205@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >> *Using* an FST is _not_ the same as *writing* an FST! One of the >>intracacies of creating an FST involves how closely it interacts with >>the rest of the OS. Sometimes these details change in an OS revision. When >>this happens, we can update the FSTs, but we can't update a 3d party FST. > > If everything were "the way it should be" GS/OS and the FSTs wouldn't >be interdependent like they (apparently) are. They cannot be completely independent. GS/OS needs to know something about the filesystem that it is working on so that it can create absolute pathnames from relative pathnames if necessary. As well, there may be some dependancy here where GS/OS needs to know what sort of pathname separator (eg "/") to use when automatically starting a program. As an example of this, can you create a file with a "/" in the filename under UNIX. Without resorting to patching the disk, you can't do this. Under GS/OS you can't create a file with both a ":" and a "/" in it. > GS/OS would serve as a front >end, basically, to the FSTs. The application would make a call to GS/OS, which >would figure out if 1) A device driver should handle the call, 2) GS/OS itself >should handle the call, or 3) A FST should handle the call. Just as GS/OS >provides some primitives for device drivers, it would provide some primitives >for the FSTs - say, keeping track of lists of open files, which FST is >responsible for them, etc. If the interaction were nice and neat (not an >impossibility), then 3rd party FSTs would become completely possible. > Unfortunately, interactions between FST's and GS/OS are not likely to be neat. There are a large number of factors to consider here. The factor of file attribute handling has been discussed by others. Filename construction however, is probably more of a problem. Currently GS/OS - ProDOS FST does not differentiate between the files "testing", "Testing", "TESTING" or even "TeStInG". Clearly, there may be a problem here in dealing with file systems where the file names above refer to 4 different files. How about file systems that permit "Illegal characters" in filenames. On some filesystems you can have a space in a filename. GS/OS - ProDOS FST doesn't allow this. How do you handle control characters in filenames??? Finally, we have to deal with the length of filenames. GS/OS - ProDOS FST currently limits filename segments to 15 characters (I think). We may have to deal with filesystems which permit more than this. DOS 3.3 for instance allows 31 character file names. Actually, DOS 3.3 has allows most of what I have described above. There are probably other considerations that I have missed here, but this is enough for one day. Some of what is listed above may be moot as I do not have any knowledge about how GS/OS and FST's interact. This is why I used the terminology "GS/OS - ProDOS FST" in this article. Some of the above might only require code in the FST but some of it may require changes to GS/OS itself. > Anyone with the urge to flame me should probably do so by email. No flames here. Just some information for some, hopefully, reasoned discussion on this topic. Maybe we can come up with some ideas that Matt or Dave or whoever can go to their bosses at Apple and say, "Maybe we should try this". Who knows, stranger things have happened. > Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp > "Education, like neurosis, begins at home." - Milton R. Sapirstein Steven Leikeim | University of Calgary | There are lies, damned lies, Department of Electrical Engineering | and statistics. .uunet!{ubc-cs,utai,alberta}!calgary!enel!steven
cwilson@NISC.SRI.COM (Chan Wilson) (12/09/89)
In article <2200@cs-spool.calgary.UUCP> steven@enel.UCalgary.ca (Steven Leikeim) writes: >In article <3762@puff.cs.wisc.edu> blochowi@rt3.cs.wisc.edu (Jason Blochowiak) writes: >>In article <5205@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >>> *Using* an FST is _not_ the same as *writing* an FST! One of the >>>intracacies of creating an FST involves how closely it interacts with >>>the rest of the OS. Sometimes these details change in an OS revision. When >>>this happens, we can update the FSTs, but we can't update a 3d party FST. >> >> If everything were "the way it should be" GS/OS and the FSTs wouldn't >>be interdependent like they (apparently) are. Humph. They have to be interdependent. Sure, you can set up a nice stable area for device drivers to use, and not change it, but eventually you're going to run into walls. Look, it's really simple. Whenever you have a new, updated version of the OS, you make damned sure your 3rd party people get a pre-release copy. If the 3rd party is at all concerned with their market share, they'll make damned sure their device driver works (and ships?) with the new OS. A concept I'd like to see appear at Apple would be the inclusion of a 'contrib' disk or two. Things like Shrinkit, BinScii (updated, that is. Not the garish thing it is), Kermit, Zlink, what have you. Don't tell them to go down to the local dealer-- your customer may be in Russia. Package it with the Apple. Apple's lawyers have the concept of "We take no responsibility for this" down pat, so... >>Responsible for them, etc. If the interaction were nice and neat (not an >>impossibility), then 3rd party FSTs would become completely possible. Well, if GS/OS was documented, that would help. But then again, that's equivilant to getting Unix source. But, entry points/system calls would be usefull. > Currently GS/OS - ProDOS FST does not >differentiate between the files "testing", "Testing", "TESTING" or even >"TeStInG". Clearly, there may be a problem here in dealing with file >systems where the file names above refer to 4 different files. Hmm. I think that's a restriction on the ProDos FST. Frankly, I'd like to see a HFS FST, so I can format a drive in HFS and use spaces, option-letters, and be descriptive. >> Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp >Steven Leikeim | 'lil old me: ................ Chan Wilson -- cwilson@nisc.sri.com <or> cwilson@nic.ddn.mil 'A computer operator at SRI International' "I think, therefore...uh...I should be?" ...UUCP/GS in research phase. More to come...