home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
177.lha
/
Deemu_v1.0
/
deemu.doc
< prev
next >
Wrap
Text File
|
1988-04-28
|
9KB
|
282 lines
PRELIMINARY PRELIMINARY PRELIMINARY PRELIMINARY PRELIMINARY PRELIMINARY
DEEMU
USER MODIFIABLE EXECUTABLE EMBEDDED DATA
Matthew Dillon (SNAIL)
891 Regal Rd.
Berkeley, Ca. 94708
USA
dillon@ucbvax.Berkeley.EDU (APRANET)
...!ihnp4!ucbvax!dillon (USENET)
30 July 1988
Includes:
CONFIG -V1.00 of my config program
CLOCK -V1.00 of my really-small non-intrusive clock program
(which uses DEEMU for window placement)
DEEMU.DOC -Docs on DEEMU
SCRIPT.TXT -Example script of configuring the clock executable
MAKEFILE
CONFIG.C
CLOCK.C
This document describes DEEMU, which allows end users to modify various
parameters of a program by directly modifying the executable in question
through standard programs. This is what happens:
(1) The programmer embedds a DEEMU structure at the very beginning
of his initialized data hunk. Since the C startup module usually
contains only BSS declarations, a simple C declaration at the
beginning of your first module will suffice.
** THIS HAS BEEN TESTED WITH AZTEC C. COULD SOMEBODY PLEASE
TEST IT WITH LATTICE?
(2) The user comes along and can modify various DEEMU entries in the
executable to customize the program to his needs.
Thus, the programmer need not put any extra code into his program to
allow the user to modify parameters from the program. Additionaly,
the script or initialization files that would otherwise have been
required are now nonexistant, making the user's enviroment that much
more streamlined and clean.
STRUCTURE FORMAT
The programm should put the following declaration at the beginning of
his first C (or assembly, or whatever) module:
long Deemu[] = {
'STRT', 0,
(other DEEMU entries)
'END ', 0
};
Note that the name of the array is arbitrary. This is an array of
longwords consisting of a START entry, intermediate entries, and an
END entry. The format of each entry is:
long type; -longword describing the structure type
uword flags; -RESERVED, SET TO 0
uword bytes; -# of bytes
char data[bytes] + PAD0 -The structure data, padded to a WORD BOUNDRY
The CONFIG program (yours, mine, anybody's) will check for 'STRT', 0 at
the beginning of every DATA HUNK in the program until it finds one,
then verifies the entire structure all the way to the 'END ', 0 is
correct, then prompts the user with the various structures allowing him
to modify them.
The user gets very nice descriptive prompts for structure types that
CONFIG knows about. The user can still modify structures CONFIG does
not know about, but will not get the descriptive prompts.
ALL STRUCTURES ARE WORD ALIGNED. That is, if a structure is not word
aligned it should be padded with a 0 at the end to make it so. Thus,
EVEN WHEN THE #BYTES IS NOT WORD SIZED, the #bytes is extended to a
longword boundry to find the next DEEMU entry: bytes = (bytes+1)&~1
Fields within the structure need not be word aligned. This allows you
to embed standard Amiga structures.
STANDARD STRUCTURES
Since this is the first release, only a couple custom structures have
been defined so far.
NOTE #1: The entire structure need not be entered. It is perfectly
acceptable to cut out the tail ends of structures that you
do not want to bother with. For instance, you might have
the following for a NewWindow structure:
'NW ', 10, (short leftedge, topedge, width, height,
ubyte detpen, blockpen)
OR
'NW ', 9, (short leftedge, topedge, width, height,
ubyte detpen)
+ one byte padding.
In this case, the CONFIG program only prompts for those
fields that exist.
NOTE #2: Structures may be longer than the 'standard' size. For
future compatibility. The DEEMU program will prompt for
these fields but will not be able to give descriptions of
them to the user.
STRT { The START structure, must be the first DEEMU structure.
long type = 'STRT';
word flags= 0;
word size = 0;
};
END { The END structure, must be the last DEEMU structure.
long type = 'END ';
word flags= 0;
word size = 0;
};
TEXT {
long type = 'TEXT';
word flags= 0;
word size = N
char prompt[A]; N = A + B. This includes the \0 after each string
char contents[B];
};
The contents string need not be exactly B long, but may terminate
with a \0 before it reaches the maximum allowed length. In this
case the extra bytes at the end may be garbage.
The contents string is thus limited to N-strlen(A)-2 character bytes,
not including the \0.
THE PROMPT STRING MAY NOT BE MODIFIED BY THE USER. SEE CLOCK.C FOR
EXAMPLE USAGE OF 'TEXT'.
NOP {
long type = 'NOP ';
word flags = 0;
word size = N;
};
No operation. The data, if any, can be modified, but will probably
not be used by the program.
DATA {
long type = 'DATA';
word flags = 0;
word size = N;
};
Program dependant data. Contents and ordering are defined by the
program. The documentation for the program will tell you which
word means what (the CONFIG program prompts for the data in WORD
sized chunks).
TRCT {
long type = 'TRCT';
word flags = 0;
word size = N;
short pri;
short cpu;
long chipmem;
long generalmem;
};
Task/Resource Control. Dynamic specification of the task priority.
pri:
Specify the task priority. If bit 8 ($100) is set, an absolute
priority is given in the low byte. If bit 8 is clear, a
priority relative to the startup-priority is given. (i.e. a
1 means, 1 over my priority when I started up).
cpu: 0-FFFF
Specify how much of a CPU hog this program can be, in
percentage (FFFF=100%). Most programs ignore the field.
chipmem/generalmem:
some value representing the maximum #bytes of memory you want
this program to use. These fields do not apply to most
programs but could come in useful in, say, a disk cache program
or something like that.
NOTE that there is no specification for 'fast' memory. chipmem
refers to specific CHIP allocations the program makes, and
generalmem refers to non-specific allocations the program might
make.
NW {
long type = 'NW ';
word flags= 0;
word size = N; (usually 8 or 10 bytes.. partial NewWindow structure)
(A partial NewWindow structure)
};
struct NewWindow NW;
'NW ', (0-sizeof(NewWindow))L, <data>
The NewWindow structure. However, the contents of LeftEdge,
TopEdge, Width, and Height, are allowed to be NEGATIVE.
TopEdge < 0 : specify right edge relative to screen right
LeftEdge < 0 : specify bottom edge relative to screen bottom
Width <= 0 : specify width relative to screen Width
Height <= 0 : specify height relative to screen height
The programmer should do a sanity check of parameters after
adjusting them properly. The GetScreenData() should be used to
retrieve screen information.
For instance, specifying -1, -1 places the window as follows:
ActualLeftEdge = Screen.Width - Nw.Width - 1;
ActualTopEdge = Screen.Height- Nw.Height- 1;
SPECIFYING 0 FOR THE Nw.Width and/or Nw.Height should cause the
window to be openned to its fullest size in that dimension.
IF YOU USE THE 'NW ' DEEMU STRUCTURE, YOU MUST BE ABLE TO HANDLE
THESE SPECIAL CONDITION!
EXAMPLE
short Deemu[] = {
'ST','RT', 0, 0,
'NW',' ', 0, 9, -16, -8, 64, 32, -1, 0,
'TE','XT', 0, 16, 'HI', '\0T', 'ES', 'T.', 0, 0, 0, 0,
'EN','ND', 0, 0
};
We have a STRT structure of 0 length (it MUST be 0 length).
We then have the first 9 bytes of a NewWindow structure:
short LeftEdge = -16;
short TopEdge = -8;
short Width = 64;
short Height = 32;
char DetailPen= -1;
NOTE: The NW structure is padded to a word boundry with a 0, this
0 is *NOT*, I repeat *NOT* the char BlockPen; specification, which
normally comes after DetailPen.
And, before the END we have a 'TEXT' entry with the prompt "HI" and
the contents "TEST". The user is allowed to modify the contents and
up to 12 characters (not including the \0) may be used. For TEXT, no
more than 128 bytes total should be allocated.
LIMITATIONS
Currently the config program only checks the first 32 longwords of
each DATA hunk. This is done mainly to prevent the possibility that
non DEEMU data might look like a DEEMU header, but also taking into
account that the linker might put some amount of data in the hunk
before it gets to the DEEMU data.
The Aztec linker (don't know about the others) sticks stuff before
your own (jump tables when using the small code model). If your
program is big enough, the DEEMU data might be out of reach. The
solution is to place the DEEMU data in its own hunk, which can be
accomplished with a little more work and various linker options.
Future CONFIG programs will fix the problem.