Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: RESOURCES (as in disk-resources) Message-ID: <8805060740.AA19959@cory.Berkeley.EDU> Date: 6 May 88 07:40:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 131 > I found it hard to follow in a few places; you were a bit too terse. >But aside from that, I have a few comments. Yah, I know. Sorry. My intention is to start a discussion which hopefully is a bit more well defined than the IPC discussion, which turned into a huge mess. Let me outline the essential concepts of my idea without any of the technical mumbo jumbo. (1) At the application level ... a program which uses one or more resources, I see an extremely simple interface that allows the program to generate a pointer to a given structure, such as a BitMap structure, where the entire structure has been filled in ... right down to the bit planes themselves, and placed in the proper memory type (MEMF_CHIP for the bit planes). At the simplest level, the programmer will use a resource editor to create such a resource and give a name, say "MyTitleScreen". Then, all the program needs to do to access it run time is: BITMAP *bm = GetRes("MyTitleScreen"); Simple as that. (2) Where are resources kept? I envision that resources will be kept in several places, most noteably in the executable itself but NOT LOADED INTO MEMORY. That is, easily accessable, the user doesn't have to worry about having to copy extranious files along with some executable, and any changes to the resource become part of the executable. Conceivably, the user of the program would be able to use the resource editor and change various defaults that are resources (for instance, he could modify the MyTitleScreen resource). (Technically, placing resources in executables can be done by utilizing the overlay capability which leaves the filehandle, used to LoadSeg() the first overlay segment, open and available). Independant resource files would also exist in various known places... for instance, in S:SYS.RSRC . The GetRes() call would first search the executable, then some local file in the 'current' directory, then S:SYS.RSRC . Thus, a program would have complete access to system standard resources and be able to overide any of the system standard resource names with his own private resource names contained in the executable or local file. In fact, we can put an IFF header on such files (but very little IFF structure). (3) This sounds neat and all that, but how the hell do we define the structure of a resource which can be so complex? A BitMap *is* complex in that it contains POINTERS to BITPLANES. Other system structures are even more complex. A List structure contains pointers into itself (if empty), and if you want a List of Nodes, say, you have the possibility of self-pointers, child-pointers (the 'next' element), and parent pointers (the 'previous' element). Additionaly, various structures need to be in specific types of memory. The bitplanes in a BitMap structure need to be in CHIP while the BitMap structure itself can be in FAST (or whatever is available). The Solution is obvious. First of call, unlike IFF there are a huge number of structures one might want to make into a resource. Most of the structures are taken directly from the Amiga include's (NewWindow, NewScreen, Font, etc...). Thus, part of the resource file must describe the structure of the resources. Fine. So what do we have? We have a "BitMap" structure named "MyTitleScreen", we have the definition of a BitMap structure, and we have the data needed to fill in the memory we allocate. "MyTitleScreen" is the name of the resource, "BitMap" is the structure-name and structure of the resource. "" is the name of some resource, "" is the structure-name and structure of the resource. Get it? All we need is a definition on the format for structure defs and we are home free. A resource editor would be able to edit anybody's resource! And a resource can be as simple as a string or as complex as an entire Menu! Technically, the definition of a structure would simply be a list of structures contained in that structure, terminating with trivial structures such as a 'char' or 'long'. See previous document for more details. RESOURCE ACCESS: The resources that come with a program as part of that program are known to the program. The other wildcard calls I specified would be used mainly by the resource editor which must be able to find arbitrary resources. However, I envision a possible use by application programs. If you chose to have each menu column in a separate resource, you might want to use the wildcarding to get a 'list' of resources for the purpose of building a menu: "MainMenu.??". --- ENHANCEMENTS I envision a couple enhancements for resources that go beyond my explanation above. (1) Shareable resources, where GetRes() would return a pointer to a shared data structure, which goes away only when all references to it go away. Say, the 'default' system Font or prefered screen to open new windows, or whatever. (2) Dynamically sized resources. For instance, you have a resource which is a character array. The structure would be 'char', but the actual resource would be specified to be larger. A BitMap is a prime example: The structure of the BitMap would have only one PLANEPTR, but the data would be dynamically sized to hold N PLANEPTR's. The resource library would extend the meaning of the last sub-structure (the one and only PLANEPTR) in the BitMap structure to cover the additional space. (3) 'no-storage' resources. I.E., if you specify a structure which must be placed in 32K of MEMF_CLEAR|MEMF_CHIP memory. Since you know the memory must be zero'd, there is no need to waste 32K of zero's in the disk file. Talk about useful! -Matt P.S. In terms of simplifying the command set, I intend to remove the requirement that one must obtain a 'handle' to a resource set and supply that in every call. Refer to the previous document. I also had a 'how' argument in many of the calls which specified where to look for the resource ... I intend to remove that as well and add a call 'SetResHow()' or something. This simplifies most calls to a single argument. And if anybody can come up with a better set of function names, lay 'em on me!