[comp.sys.amiga] Resource Segment ... my new project!

dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/29/88)

	Hey people, I've got myself another project!  One thing that
the Amiga does not currently have that would really be nice is a
modifiable resource segment for an executable, and I think I know how 
to do it.

	It must be (1) compatible, (2) should be part of 
the actual executable, and (3) easy to use.  The only problem with making
the resource a hidden part of the actual executable is that you need 
some way of getting a filehandle for the executable so you can get at
the data.  But, guess what??  We have *OVERLAYS*.  AmigaDOS automatically
leaves the filehandle used to LoadSeg() the executable open and accessable.
The most intuitive way to add resources is to have a utility which
modifies the executable, making it into an overlay executable and adding
an extra node (overlay segment) to the end which contains the custom
hunk holding the resources!

	Being an overlay executable, we can then load the resources on
the first call to getresource().  I intend to write a library to handle 
all of this, a resource editor, and a resource compiler.  Essentially, 
the programmer writes the program as usual, but uses getresource() to
retrieve whatever resources he put in the resource file.  After the program
is all linked up, he runs the resource compiler on it to "add" the resource
information.  Then anybody will be able to run the resource editor on it
to modify or add information.

Each resource:
	-Structure name
	-User name (structurename+username = unique name)
	-size of resource
	-memory type required (e.g. MEMF_CHIP, MEMF_PUBLIC, etc...)
	-local relocation information

	The resource editor would still be able to edit unknown resources
since the size is known.  Example of access:

	ptr= getresource("<structurename>[.<username>]", &length)
	ptr= getresource("NewWindow", &length)
	ptr= getresource("TextAttr.default", &length)
	ptr= getresource("TextAttr.myfilerequestor", NULL)
	ptr= getresource("TextAttr.1", NULL)
	ptr= getresource("Font.1", &length)
	ptr= getresource("Font.2", NULL)
	ptr= getresource("Font.3", &length)
	ptr= getresource("BitMap", NULL)

	Where the second argument of the getresource call may be NULL if
you do not care about the length.  A pointer to the structure is returned
or NULL if the resource could not be found.  All the resources are loaded
on the first call to getresource().  The program must make an 
UnLoadResources() call before exiting.

	The format on disk is not an image of the actual structure, due
to the possibility of having pointers.  Pointer information is stored as
an offset to some static data which is resolved when the resources are
loaded into memory.  Thus, when you getresource("BitMap.mygadget", NULL),
you get a real bitmap structure which can immediately be used.

	Anybody have any suggestions or enhancements they would like to
see as I begin working on this?

					-Matt

ali@polya.STANFORD.EDU (Ali T. Ozer) (03/29/88)

In article <8803282224.AA10944@cory.Berkeley.EDU> Matt Dillon writes:
> [... talking about resources ...]
>	Anybody have any suggestions or enhancements they would like to
>see as I begin working on this?

Matt,
Provide a ``resourcefile()'' call which specifies an alternate resource
file name to read the resources from. Then the first ``getresource()''
looks at this file (maybe this file's resource segment). This way during
development you wouldn't need to spend the extra step adding in the 
resources to the end of your executable after every compile/link session.

Ali Ozer, ali@polya.stanford.edu