TMPLee@DOCKMASTER.NCSC.MIL (05/18/89)
(This in response to Dave Lyon's response to my question) Thanks for the answers, but they don't make me feel very comfortable. Will there or will there not be a usuable, reliable, incremental hard drive backup package available on System Disk 5.0 or available at the same time that can handle extended files? Also, will the problem of the Finder on 4.0 continually polling my PC Transporter's drive have been fixed in the Finder on 5.0? AE insists that the problem is Apple's, not theirs, and it is the reason why I have to stay with the old Finder (3.0 or so System disk) which presumably would have the same problem with extended files that ProDos 8 does since it doesn't know anything about them. And I really don't see why you can say it is better to have new extended files that ProDos8 can't use than not to have them at all; that's only your opinion. TMPLee@dockmaster.ncsc.mil
dlyons@Apple.COM (David Lyons) (05/18/89)
In article <890518011751.127016@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >(This in response to Dave [Lyons'] response to my question) > >Thanks for the answers, but they don't make me feel very comfortable. >Will there or will there not be a usuable, reliable, incremental hard >drive backup package available on System Disk 5.0 or available at the >same time that can handle extended files? I haven't written one. Ask the people who have written backup utilities whether they are updating their products to work with extended files. (Have you investigated the ProSel 16 utilities? I think there's supposed to be an incremental backup utility on there--I've never tried to use it.) >And I really don't see why you can say it is better to have new extended >files that ProDos8 can't use than not to have them at all; that's only >your opinion. Okay, it's my opinion. Shall I stick "In my opinion," onto the beginnings of all my sentences? (Or maybe I should sign all my messages with something like "My opinions are my own...." :-) >TMPLee@dockmaster.ncsc.mil --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
farrier@Apple.COM (Cary Farrier) (05/18/89)
In article <890518011751.127016@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >And I really don't see why you can say it is better to have new extended >files that ProDos8 can't use than not to have them at all; that's only >your opinion. It is not just an opinion. Resource forks allow you to separate code from data very easily, thus allowing users to customize existing programs very easily (any body who has used ResEdit on the Macintosh knows what I am talking about), and it allows developers to re-use their data in a more efficient manner. Not to mention that a developer can create one program, and that program can be easily translated into an internationally marketable product, because all the text belonging that the application uses can be stored in the resource, and can be modified in a couple of minutes for each country, instead of re-compiling an entire product and having to maintain a zillion different versions (Can you imagine if you had a program sold in 10 different countries, and you had to fix the same bug 10 times?!). Cary Farrier
delaneyg@wnre.aecl.CDN ("H. Grant Delaney") (05/18/89)
I'm afraid I have to go along with Dave Lyons. The arguement that because ProDOS 8 can't reed the resourse forks doesn't wash with me. It sounds too much like the people I see who still haven't changed to ProDOS because it can't read their DOS 3.3 Programs. If we expect top see the IIGS+ or what ever and get all the advantages of new and better things we have to live with change. I agree that a backup program is a necessary at the time of release. But maybe that part of the reason we all got notice of it's release in advance. In the past Apple has not given us the time to prepare for changes. I think the announcement of GS/OS 5.0 and Mac 7.0 is a step in the right direction. Grant
blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (05/19/89)
In article <890518011751.127016@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >And I really don't see why you can say it is better to have new extended >files that ProDos8 can't use than not to have them at all; that's only >your opinion. Of course it's his opinion! However, it's a shared opinion... Having forked files will make life MUCH easier for developers (actually, it's more related to what they're used for, but that's beside the point), which will make for better software for the end-user. Glen Bredon's Backup & Restore don't do incrementals, but they're fast enough so that doesn't matter much... >TMPLee@dockmaster.ncsc.mil ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------
mattd@Apple.COM (Matt Deatherage) (05/19/89)
<890518011751.127016@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >(This in response to Dave Lyon's response to my question) > >Thanks for the answers, but they don't make me feel very comfortable. >Will there or will there not be a usuable, reliable, incremental hard >drive backup package available on System Disk 5.0 or available at the >same time that can handle extended files? Also, will the problem of the >Finder on 4.0 continually polling my PC Transporter's drive have been >fixed in the Finder on 5.0? AE insists that the problem is Apple's, not >theirs, and it is the reason why I have to stay with the old Finder (3.0 >or so System disk) which presumably would have the same problem with >extended files that ProDos 8 does since it doesn't know anything about >them. > I hasten to remind those in netland worried about extended files that they have been present in GS/OS, and in the ProDOS FST, ever since release. That's nine months since release, and even longer since seeding so many developers have been aware of this for a *long* time. Some have revised their programs to support extended files, others have not. Those that haven't will probably feel a twinge of regret. A standard GS/OS file utility *will* operate on extended files, even without modification, but it will not duplicate or operate on the resource fork without change. For example, APW's "copy" command will copy an extended file, but only the data fork. Not knowing about the resource fork (since it was written before GS/OS), it will only copy the data fork. This differs from ProDOS 8, which can't open extended files at all. A backup utility was not announced as part of the system software, t specifically answer your question, but please stop thinking extended files are an incredible nuisance and the end to life as we know it. It's not true. PC Transporter's problems are not Apple's fault, except in a very minimal sense of the word "fault". The Finder makes DStatus calls to the drives to determine their state, since in Apple II land we can eject disks without the operating system knowing about it. The generated driver for the PC Transporter responds to these by going to disk. The Finder wouldn't do this if the drives correctly identified themselves through SmartPort as 5.25" drives, but they don't, so the Finder has no way to know not to poll the drives. I've seen at least one person patch the PCT pre-boot to fix a couple of AE's bugs in it (such as this one), and the 4.0 Finder works just fine with it. The patches have been given to AE, which so far hasn't seen fit to distribute them to the installed base at large, apparently hoping Apple will fix their problems for them (I guess, based on what you said). >And I really don't see why you can say it is better to have new extended >files that ProDos8 can't use than not to have them at all; that's only >your opinion. > It's mine, as well. 16-bit software will usually handle the extended files in at least a minimal, one-forked kind of way, instead of ProDOS 8 which can't deal with them through normal operations. So run 16-bit software. It's the same kind of opinion that thinks an HFS FST would be useful, even though ProDOS 8 couldn't read those disks at all. There are a good number of 16-bit utilities out there which duplicate and enhance the functions of the ones you use under ProDOS 8. If you don't run 16-bit software for some reason, perhaps you'd be happier with a IIe and a TransWarp card. It's cheaper than a standard IIgs and faster. However, most IIgs owners expect (and receive) enhancements and new operating systems, and realize that all of these features can't be backwards compatible. I still think it's pretty neat that GS/OS can recognize ProDOS 8 programs on ProDOS or AppleShare disks and load P8, *an entirely different operating system*, so the program can execute, and then restart itself when the program quits. That kind of integrated backwards compatibility doesn't show up all that often, and it just can't always happen that smoothly. There are such things as growing pains. >TMPLee@dockmaster.ncsc.mil ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------
delton@pro-carolina.UUCP (Don Elton) (05/19/89)
Network Comment: to #2764 by obsolete!TMPLee%dockmaster.arpa
ProDOS 8 can't use resource files anyway since they are GS/OS objects
(applications or data files or whatever). The only real limitation with this
incompatibility would be that a P8 program that didn't use block access
wouldn't be able to copy or backup the files. A P8 program that knows about
the special format of forked files could always read the index blocks and get
to the data anyway though. There's also no real reason why P8 couldn't be
updated to include the two types of OPEN present in GS/OS though again only
programs written after this change would be able to use the files.
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111gwyn@smoke.BRL.MIL (Doug Gwyn) (05/20/89)
In article <31026@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >It is not just an opinion. It certainly is! I've heard all the arguments for forked files before, and I still don't like them. I think it's the biggest OS design botch since file types.
lwv@n8emr.UUCP (Larry W. Virden) (05/20/89)
Maybe I am missing something, but it seems like basically resource forks are just for making certain types of programming a little bit easier. Is this basically it? I mean, I could write my program to read in all the text from a text file, or put all the output text into a single module which could be replaced with other languages - that would be no problem. I could write my programs with the dialog placements in a particular module which, using a program like genesys could be edited and recreated quite easily. So this is another programming construct to make life easier in some cases. Not that that is bad - but it isnt adding truely new functionality to the user as such, right? As for a lot of the replys to several of the expressed concerns about resource files, my own reply is - it seems a shame to cause existing, fully functional programs to no longer function for a programming construct. For instance, I assume that I will not be able to upload or download forked files with TIC, I wont be able to move them or copy them with ECP8, kermit wont be able to up or download the files, Zlink is out of luck, cat.doctor (and the other prosel tools except for mr.fixit) wont be able to be blanketly used on disks with forks on them, etc. In other words, most of the utility software that I have paid for or have available for use will not work. Instead, I have to find substitutes written in GS/OS for the software to use at least for this special case. AND, I then have to wait until the authors of the GS/OS versions get around to updating to handle forked files. Or, I can go on working as I am not and just realize that there will be features on my GS that I wont be able to use for a year or so. -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 n8emr!lwv@cis.ohio-state.edu (Internet) 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) The world's not inherited from our parents, but borrowed from our children.
labc-3dc@e260-3f.berkeley.edu (Andy McFadden) (05/21/89)
In article <1103@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >So this is another programming construct to make life easier in some cases. >Not that that is bad - but it isnt adding truely new functionality to the >user as such, right? Resource editors give the user a great deal of flexibility... check out ResEdit on the Mac sometime. >As for a lot of the replys to several of the expressed concerns about >resource files, my own reply is - it seems a shame to cause existing, fully >functional programs to no longer function for a programming construct. What? Just because Copy II Plus can't deal with the files doesn't mean anything... >For instance, I assume that I will not be able to upload or download forked >files with TIC, I wont be able to move them or copy them with ECP8, kermit >wont be able to up or download the files, Zlink is out of luck, cat.doctor >(and the other prosel tools except for mr.fixit) wont be able to be blanketly >used on disks with forks on them, etc. In other words, most of the utility >software that I have paid for or have available for use will not work. Wrong! Where there's a will, there's a way. You can either a) download them in two pieces (splitting/joining programs shouldn't be hard to write), or b) use the new version of ShrinkIt that is coming Real Soon Now. >Instead, I have to find substitutes written in GS/OS for the software to >use at least for this special case. Yeah, like Cat Doctor GS (part of ProSEL-16). >AND, I then have to wait until the authors of the GS/OS versions get around >to updating to handle forked files. Since Apple is usually pretty good about letting developers know the general direction they're heading, I don't think you will have long to wait. Andy Nicholas has promised a version that handles forked files, and I'm sure that ProSEL-16 will be able to. Fact is, until the new GS/OS system disk is released, nobody can use them anyway. >Or, I can go on working as I am not and just realize that there will be >features on my GS that I wont be able to use for a year or so. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden labc-3dc@widow.berkeley.edu (expiring soon) < Two more days 'til I'm outta here... >
samt@pro-europa.cts.com (Sam Theis) (05/22/89)
Network Comment: to #2667 by pnet01!crash!purdue.edu!haven!adm!smoke!gwyn Doug Gwin writes: | It certainly is! I've heard all the arguments for forked files before, | and I still don't like them. I think it's the biggest OS design botch | since files types. Gee Doug, don't you really mean since ProDOS came out and wasn't DOS 4.0. I can't wait to hear you wail and nash your teeth over HFS.FST when (if ever) it comes out. Progress seems to be hard on some. Sam
jazzman@claris.com (Sydney R. Polk) (05/22/89)
From article <1103@n8emr.UUCP>, by lwv@n8emr.UUCP (Larry W. Virden): > > Maybe I am missing something, but it seems like basically resource forks are > just for making certain types of programming a little bit easier. Is this > basically it? I mean, I could write my program to read in all the text from > a text file, or put all the output text into a single module which could > be replaced with other languages - that would be no problem. I could write > my programs with the dialog placements in a particular module which, > using a program like genesys could be edited and recreated quite easily. There are two main reasons for writing a program using resources. 1. It is much easier to localize a program in another language using resources. This means that when all of the strings change, the code does not have to be recompiled. Somebody who doesn't have to know a lot about the code can change the strings themselves and let the programmers work on other things. Also if any dialogs have to be reworked, or menus, etc., it is much easier to do this in a resource editor. To give an example, when programming the GS without resources, a complex dialog witha lot of buttons, check boxes and text can take three days to get the appearance right because the program has to be recompiled every time a button is moved one pixel down. 2. Having resources will make programming the GS a lot more like programming the Mac, thus, at least Apple hopes so, attracting some experienced Macintosh programmers to the machine. I pity the poor Mac programmer who tries this. This machine has a lot more traps for the programmer than the Mac. Having resources is EXTREMELY useful for writing GS/OS applications, and that is why they are there. Someone could make a lot of money writing a file utility package that is completely compatible, but I don't have the time or the inclination. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
dlyons@Apple.COM (David Lyons) (05/23/89)
In article <1103@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >Maybe I am missing something, but it seems like basically resource forks are >just for making certain types of programming a little bit easier. Is this >basically it? Having resource forks doesn't let you do anything you couldn't have done with them. On the other hand, they let you do things faster and typically with less code. Sure, your programs *could* read everything you might ever want to custoze out of separate files--but they don't! >As for a lot of the replys to several of the expressed concerns about >resource files, my own reply is - it seems a shame to cause existing, fully >functional programs to no longer function for a programming construct. >For instance, I assume that I will not be able to upload or download forked >files with TIC, I wont be able to move them or copy them with ECP8, kermit >wont be able to up or download the files, Zlink is out of luck, cat.doctor >(and the other prosel tools except for mr.fixit) wont be able to be blanketly >used on disks with forks on them, etc. In other words, most of the utility >software that I have paid for or have available for use will not work. Uploading and downloading does not need to change. Only packing/unpacking needs to change. If you're unpacking something with a resource fork, you'll probably end up doing it under GS/OS with an unpacker that knows about extended files. Glen Bredon has already updated MR.FIXIT and BEACH.COMBER to deal with extended files. I don't know if any other ProSel 8 utilities can deal with them, but I assume that ProSel 16 utilities can deal with at least the data forks of extended files. >AND, I then have to wait until the authors of the GS/OS versions get around >to updating to handle forked files. It's not like resource forks are a surprise to developers--the forks have existed since System Disk 4.0, which was released to the public in September 88. Although the format of the info stored in resource forks was not defined until System Disk 5.0, there has been nothing stopping developers for the last 9 months or so from writing and testing packers/unpackers and other utilities to work with resource forks. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 >n8emr!lwv@cis.ohio-state.edu (Internet) >75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) >The world's not inherited from our parents, but borrowed from our children. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (05/23/89)
In article <8905211958.AA07187@crash.cts.com> pnet01!pro-nsfmat!pro-europa!samt@nosc.mil writes: >Doug Gwin writes: [Isn't it Gwyn?] > | It certainly is! I've heard all the arguments for forked files before, > | and I still don't like them. I think it's the biggest OS design botch > | since files types. > Gee Doug, don't you really mean since ProDOS came out and wasn't DOS 4.0? I doubt it. > I can't wait to hear you wail and nash your teeth over HFS.FST when (if ever) >it comes out. Dunno when, but I bet it will. >Progress seems to be hard on some. Please - there's a difference between progress and progress at the cost of incompatibility. >Sam Having seen him post on a number of things, I don't think he's being a sentimentalist - I think he's critizing a design choice. There are a number of different broad philosophies as far as OS design goes, and Apple seems to have gone off on their own (pardon the pun) road. I can see both sides of the issue - on one hand, a resource fork doesn't do anything that can't be done by some other means (like a separate file, perhaps with a similar name to the application), but (on the other hand) it does insure that the resources will be there (yaknow, if the file is there, the resources are as well). That last bit is fairly important given the way that they designed the Mac's OS. I'm personally ambivilent about them - I am VERY happy that the gs will finally have resources (not at all unsure about that one), but I agree to a point with Doug about the particular way that Apple chose to implement them... Btw, I'm not a sentimentalist either - I much prefer ProDOS to DOS 3.3, and I prefer GS/OS to ProDOS 16. ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------
nicholaA@moravian.EDU (05/23/89)
>Maybe I am missing something, but it seems like basically resource forks are >just for making certain types of programming a little bit easier. Is this >basically it? I mean, I could write my program to read in all the text from >a text file, or put all the output text into a single module which could >be replaced with other languages - that would be no problem. I could write >my programs with the dialog placements in a particular module which, >using a program like genesys could be edited and recreated quite easily. In addition, part of the precept of resources is that they _transparently_ add this functionality to a gs/os program. The is no need to have a bunch of configuration files lying around which must be worried about by the user. That is, to most average users, it makes life easier. >So this is another programming construct to make life easier in some cases. >Not that that is bad - but it isnt adding truely new functionality to the >user as such, right? It adds new functionality in that it (usually) makes the user's life easier. Also, because it makes a programmer's life easier, we can crank out more of these slick programs that everyone likes, so in essence this provides more functionality to the user because there will be more programs available to use. >As for a lot of the replys to several of the expressed concerns about >resource files, my own reply is - it seems a shame to cause existing, fully >functional programs to no longer function for a programming construct. >For instance, I assume that I will not be able to upload or download forked >files with TIC, I wont be able to m>ove them or copy them with ECP8, kermit >wont be able to up or download the files, Zlink is out of luck, cat.doctor >(and the other prosel tools except for mr.fixit) wont be able to be blanketly >used on disks with forks on them, etc. In other words, most of the utility >software that I have paid for or have available for use will not work. it will work. it just won't work with forked files. it's not like the day you use your first forked file the earth will stop moving. >Instead, I have to find substitutes written in GS/OS for the software to >use at least for this special case. yes, you probably will. And, as an author of gs/os stuff, i hope you *DO*. >AND, I then have to wait until the authors of the GS/OS versions get around >to updating to handle forked files. Not necessarily. In most cases older software doesn't know about resource forks, and doesn't bother with them, and the same for the user. The few instances where a program will have to updated is when they move data from one place to another. (by copying, moving, telecom, whatever) >Or, I can go on working as I am not and just realize that there will be >features on my GS that I wont be able to use for a year or so. Yep. The choice is yours. At some point if *YOU* want to use the new features that will be available, *YOU* have to make a choice. It's *YOUR* responsibility. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/24/89)
In article <8905211958.AA07187@crash.cts.com> pnet01!pro-nsfmat!pro-europa!samt@nosc.mil writes: >Doug Gwin writes: > | It certainly is! I've heard all the arguments for forked files before, > | and I still don't like them. I think it's the biggest OS design botch > | since files types. > Gee Doug, don't you really mean since ProDOS came out and wasn't DOS 4.0. No, I mean since file types. ProDOS was overall a considerable improvement over Apple DOS 3.3. > I can't wait to hear you wail and nash your teeth over HFS.FST when (if ever) >it comes out. Why would I do that? I have some Mac disks I'd like to copy files from. >Progress seems to be hard on some. Especially when they refuse to learn from others' experience. The UNIX experiment demonstrated conclusively the advantages to simple, regular, wart-free structure. Meanwhile, OS designers keep adding warts.
cdm@pro-freedom.cts.com (Carl Macdonald) (06/02/89)
Network Comment: to #4714 by unknown
Well lets see what kind of hash I can make of this. On the Macintosh the
resource forks are usually used to store anything that goes on the screen,
such as text, dialog boxes, etc. This is actually easier to use than it sounds
because the Mac toolbox allows access to the resource fork, such as a tool
that draws a dialog box on the screen from the resource ID you give it. The
big advantage to this is that if you want to change the appearence of the
screen, say for example to make a French or German version of the software,
you make the changes and not have to change or recompile any source code.
As for the implimentation on the GS, I understand that the file itself will
still be the same, it will just have some header information giving the
offsets to the begining of the data and resource forks.
Carl MacDonald, programmer
Central Point Software
DISCLAIMER: All opinions expressed here are my own, not those of my employer
or anyone else, living or otherwise.
UUCP: crash!pnet01!pro-freedom!cdm
ProLine: cdm@pro-freedom
ARPANet: crash!pnet01!pro-freedom!cdm@nosc.mil
InterNet: cdm@pro-freedom.cts.com
Do what you want with my Macintosh, but don't even THINK about touching my
Apple 2!farrier@Apple.COM (Cary Farrier) (06/02/89)
In article <8906020837.AA22047@crash.cts.com> pnet01!pro-sol!pro-newfrontier!pro-freedom!cdm@nosc.mil writes: >Network Comment: to #4714 by unknown > >Well lets see what kind of hash I can make of this. On the Macintosh the >resource forks are usually used to store anything that goes on the screen, >such as text, dialog boxes, etc. Actually, *anything* can be a resource. Your program is actually a resource of type CODE, usually id 0. >because the Mac toolbox allows access to the resource fork, such as a tool >that draws a dialog box on the screen from the resource ID you give it. The >big advantage to this is that if you want to change the appearence of the >screen, say for example to make a French or German version of the software, >you make the changes and not have to change or recompile any source code. The GS toolsets now support this type of operation, also. For example there is a new version of NewWindow() called NewWindow2() which will accept a variety of inputs, including resource id's. > >As for the implimentation on the GS, I understand that the file itself will >still be the same, it will just have some header information giving the >offsets to the begining of the data and resource forks. Possibly, but that is on the block level of the disk only. No one except the person who wrote the ProDOS FST has to worry about that. Cary Farrier
dlyons@Apple.COM (David Lyons) (06/03/89)
In article <8906020837.AA22047@crash.cts.com> pnet01!pro-sol!pro-newfrontier!pro-freedom!cdm@nosc.mil writes: >[...] >As for the implimentation on the GS, I understand that the file itself will >still be the same, it will just have some header information giving the >offsets to the begining of the data and resource forks. > >Carl MacDonald, programmer >Central Point Software Under GS/OS, files can be extended or not. Nonextended files ("standard" files, I think) just have one fork, the data fork, like always. On ProDOS disks, these have storage type 1, 2, or 3 (seedling, sapling, or tree). Extended files have two forks, the data fork and the resource fork. As far as the OS is concerned, these are symmetrical--each fork can be OPENed, READ, CLOSEd, etc. independently. For copying and archiving, etc, this is fine, but only the Resource Manager should try to interpret the contents of the resource fork. Extended files which happen to be stored on ProDOS disks have storage type 5. Only the ProDOS FST & certain disk utilities need to know the details there. (For the curious: the key block for an extended file on a ProDOS disk contains something like a miniature directory entry for each fork, including a storage type of 1, 2, or 3 for each fork.) As Cray pointed out, *anything* can be stored in the resource fork; on the Mac, even code is stored there. Code can also be stored in GS/OS resource forks, but it will be less common than on the Mac. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.