Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: RESOURCES (as in disk-resources) Message-ID: <5895@well.UUCP> Date: 7 May 88 01:30:43 GMT References: <8805040914.AA24466@cory.Berkeley.EDU> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 104 Summary: Looks good -- more details please Stuff about resource files: > PRELIMINARY DOCUMENT. COMMENTS PLEASE! > In general, the main idea is to be able to specify all sorts of useful > information, both for the program which uses the resources, and for the > user to ALLOW HIM TO MODIFY the resources. IFF does not cut it, as > you will soon see. Generally, it looks like a really great idea. It would be really useful even just for programming purposes to be able to define things in a better way than static structures, or custom code to build dynamic structures. Contrary to your claim, however, I did not see how IFF doesn't cut it. IFF just provides a standard way of storing chunks of bytes in a file -- you get to say what the chunks mean. I don't see why you can't wrap up what you've devised into a CAT or LIST of FORM RSRC or something like that. You don't have to like it, but it IS the standard after all. > A basic requirement is to remove ALL WORK from the application program > which uses the resources. Right attitude. > That is, the program should be able to > simply GetRes(handle, "titlebitmap") and the call would return a > completely resolved BitMap structure for use in its title screen. > Structures which the programmer used to have to build by hand in > static declarations can be made into resources and resolved > automatically. This sounds really great, but things got a little opaque after this point in the document. Can you explain a little more about the internals of your design? Given that I only kind of half understood it, my remaining comments may or may not be meaningful. > how: bitmask of search areas (0 highest priority). Usually > -1 is specified. : > area: 0 resources contained in this executable > 1 specified resource file (default:procname.rsrc) : : Hmm. How are you going to get at the resources stored *in the executable*? Also, will GetRes() end up searching every level for things? How do you plan to keep this fast (especially with the current DOS)? > RESINFO: > Resource Information. NOTE that the resource data block is for Interesting, but not very illuminating. How about some more about this? > STRINFO: > Information about a structure. Any referenced or subreferenced > structures are included. All structure ID's are renumbered > according to their entry #, starting at ID 1. I take this to mean that each STRINFO refers to one complete structure, and that any structure pointers that a structure contains are resolved by using the ID tags internal to this instance of STRINFO. Sounds semi-reasonable, I suppose, if this is actually what you meant. > [0] = # of entries. Each entry takes 2 array spots. > [1] = master structure name [2] = structure format > [3] = structure name [4] = structure format Does this mean that if structure A contains a pointer to structure B, then the STRINFO for A contains the format for A and for B? What if you want to refer to structure B by itself, do you need a separate STRINFO for that as well? Seems innefficient and prone to problems. If the "structure format" for the same structure appears several places you'll need checkers to make sure all the structure definitions are the same. Why not have each structure defined exactly once and refered to only by reference from then on? > the structure format is not defined in this document. Get it on paper quick if you haven't already. >STRUCTURE FORMAT, GENERAL CAPABILITIES: > Structure ID's are tagged in bits 15 and 14 as follows: ... > 01 - parent pointer (rest of ID not used) What if two higher-level structures point at this struct? How does it tell which is the parent? Seems like you need to use the ID for this case as well. >RESERVED STRUCTURE NAMES: An awful lot here. How big is the resource file which defines all these going to be, and how fast will it be to read? My fear in looking at this is that the resouce.library (?) will have to be a mini-compiler and reading all the structure definitions will take the kind of memory and time that a compiler takes. Obvoiusly, since I don't know the internals my fears are probably ungrounded. Please say something about efficiency issues in your future postings. Good work! -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)