The application DOR(s) may now be placed wherever is convenient (the contain relative data structure pointers), and if there is more than one, chained together via the brother links. An application DOR contains various information relevant to running the application, and may also contain pointers to menu topic help information. The format of an application DOR is as follows:
| 3 bytes | 0 0 0 | Extended pointer to parent | ||||||||||||||||
| 3 bytes | x x x | Extended pointer to brother (this will be 0 0 0 if this is the only application on the card or the last in a chain) | ||||||||||||||||
| 3 bytes | 0 0 0 | Extended pointer to son | ||||||||||||||||
| 1 byte | $83 | DOR type, application ROM | ||||||||||||||||
| l byte | x | Total DOR length | ||||||||||||||||
| 1 byte | '@' | Key to info section | ||||||||||||||||
| 1 byte | x | Length of info section | ||||||||||||||||
| 2 bytes | 0 0 | Reserved for future expansion | ||||||||||||||||
| 1 byte | 'x' | Application key letter, i.e. the letter used in the square sequence to enter the application. If several applications share a letter, then the first is entered by []x, the next by []Zx, the next by []ZZx, etc. A maximum of ZZZZ is possible. However, a bug in v3.0 of the operating system doesn't allow for more than []ZZx. | ||||||||||||||||
| 1 byte | x | continuous RAM size required, in 256-byte pages (eg. 32 for 8K). This is relevant only to bad applications. This byte ranges from 1 to 160 (160*256=40K). See the section below on bad applications. Use 0 to make your application the default size, which is 8K on an unexpanded machine and 40K on an expanded one, or if your application is good. | ||||||||||||||||
| 2 bytes | 0 0 | This is an estimate of environment overhead, ie. how much memory is needed to save the state of the application each time it is exited. OZ will 'learn' from experience how much is actually required anyway, so this feature is best ignored. | ||||||||||||||||
| 2 bytes | x x | Unsafe (ie. not preserved over pre-emption) workspace size required in bytes (low byte, high byte). | ||||||||||||||||
| 2 bytes | x x | Safe (ie. preserved over pre-emption) workspace size required in bytes. These workspaces are allocated from the system half of segment 0, downwards from $1FFD, unsafe workspace at the top. They are used when it is important that the workspace is not bound to awkward segments, but rather remains stable in the logical address space. Note that both safe and unsafe workspace draw from the 2K area of memory from $1800 to $2000. This area is also used for the application stack, mailboxes, and some system stack. Therefore you must make sure that all these demands do not exceed the limited supply of available memory. It is probably advisable to limit safe and unsafe workspace to not much more than a couple of pages at the most. | ||||||||||||||||
| 2 bytes | x x | Entry point for application code (16bit local address). Must be in segment 3. Remember low byte, high byte order. | ||||||||||||||||
| 1 byte | x | Desired binding of Segment 0 on entry. | ||||||||||||||||
| 1 byte | x | Desired binding of Segment 1 on entry. | ||||||||||||||||
| 1 byte | x | Desired binding of Segment 2 on entry. | ||||||||||||||||
| 1 byte | x | Desired binding of Segment 3 on entry. Usually you will want to bind the bank containing the code for your application to segment 3 and probably set the other banks to zero. If the application is a bad one, then certain segments will be bound to RAM on entry, depending on the size of continuous RAM selected. The desired binding of such segments must be set to zero to avoid conflict (RAM is paged in after application is created therefore overriding explicit bank references). | ||||||||||||||||
| 1 byte | x | Application type byte 1. Set it to a combination of the following bits. Note the bits are not all orthogonal, eg. if 4 is set 8 must be too.
| ||||||||||||||||
| 1 byte | x | Application type byte 2. Given by combination of:
| ||||||||||||||||
| 1 byte | 'H' | Key to help section | ||||||||||||||||
| 1 byte | x | Length of help section | ||||||||||||||||
| 3 bytes | x x x | Extended pointer to topics | ||||||||||||||||
| 3 bytes | x x x | Extended pointer to commands | ||||||||||||||||
| 3 bytes | x x x | Extended pointer to application help | ||||||||||||||||
| 3 bytes | x x x | Extended pointer to token base ($000000 for no token, $FFFFFF for system tokens). | ||||||||||||||||
| If no menus, help or diamond sequences are required then the above should all point to three zeros. E.g. an extended pointer to the beginning of the current application DOR would be suitable (it always contains three zeros). | ||||||||||||||||||
| 1 byte | 'N' | Key to name section | ||||||||||||||||
| 1 byte | x | Length of name | ||||||||||||||||
| x bytes | 'xxxx',0 | Null-terminated application name. If this too long then it will look rather odd in the Index. 12 characters is about the maximum sensible length. Screen driver codes is allowed in the name (e.g. bold). | ||||||||||||||||
| 1 byte | $FF | DOR terminator byte. |