WGML Binary Device Files
Table of Contents
The binary device file format is used for two distinct purposes:
- To encode :DEVICE, :DRIVER, and :FONT blocks.
- To provide a directory file.
The directory file is used to allow device names of up to 78 characters to be used, even on file systems which restrict file name length (i.e., FAT). The 78-character limit is documented in the WGML 4 Reference.
The attributes that are used to build the entries in the directory file are discussed in Common Attributes.
The decoded structures in the binary device files are expressed in a "sort-of C struct" form which should make the structure found clear to anyone reading this Wiki. They may or may not be valid "C" code.
These are not the structs that are used in the code. The binary device files contain many count bytes and designators which simply are not needed by wgml after the binary device file has been parsed. Indeed, in many instances, their only role in parsing the binary device file is to be read and checked to be certain that they have the correct value.
Fields are referred to in these ways:
- If the field is part of the struct under discussion, the field name is used by itself.
- If the field is part of another struct, then the struct name is prepended with . as a separator.
- If the field is part of an instance of another struct (that is, of a field in yet another struct) then the parent field's name is prepended with . as a separator.
The last two cases are distinguishable: struct names start with capital letters, field names start with lower case.
Many of the discussions of the specifics of the binary device file format include notes on the actual form of the source code accepted by gendev 3.33 and gendev 4.1. This section is intended to summarize common rules discovered governing that form, so that they need not be repeated in each section and sub-section.
All of the statements made here were confirmed by actual test. Many of them match statements made in the WGML 4 Reference or the README file produceable from the WGML 3.33 Update and should be taken as confirming the documentation, not as new discoveries. Those which contradict the documentation or which provide information not included in the documentation are new discoveries.
These statements apply unless otherwise noted in the discussion of a particular block:
- Although the documentation and all available source files show each entry on its own line, this is not required and multiple elements can be placed on the same line.
- The attributes which are present can appear in any order.
- For blocks that include both attributes and sub-blocks, all of the attributes which are present must appear before any sub-block or this error message is seen:
AT--001: Required attribute not found.
- Blocks which produce CodeBlocks (:VALUE, etc) must not be empty or this error message appears:
SN--034: Expecting text before termination tag.
These statements apply unless otherwise noted in the discussion of a particular block:
- Except for character and string values, each character may be upper or lower case individually. This applies to tags, attribute names, and predefined attribute values. NOTE: it is yet to be determined if character and string values match regardless of case.
- Characters can be entered as such but must be delimited when used as an attribute value; if not delimited then either this message:
SN--001: Number is too large or contains invalid characters
or this message:
AT--002: Missing attribute value
appears, apparently depending on whether or not the character entered can be interpreted by gendev as a "number". NOTE: if the character happens to be a decimal digit, then it will be indistinguishable from and so taken as a decimal number.
- Characters used in :INTRANS, :OUTTRANS, and :WIDTH blocks are neither attributes nor attribute values, and should be entered without delimiters.
- Characters can be entered as decimal numbers, with no delimiters or prefixes.
- Characters can be entered as hexadecimal numbers, with no delimiters but with a $ prefix.
- Decimal or hexadecimal numbers (used to represent characters) which are delimited are treated as one or more characters.
- If more than one character is entered, then this error message appears:
AT--007: The attribute value cannot have more than one character
- Character strings can always use delimiters.
- Character strings with no embedded spaces do not need to be delimited in most contexts; the known exception is that the value of attribute font of the :BOX or :UNDERSCORE block must be delimited if a character string is used, presumably to distinguish them from a font number, or this error message results:
SN--001: Number is too large or contains invalid characters
- Undelimited character strings with embedded spaces produce this error message:
AT--001: Required attribute not found
Since more than one attribute can be placed on the same line, the first word after the space cannot be distinguished from the next attribute name.
These statements apply to both character and string delimiters:
- Either single or double quotes may be used.
- The quote on each end must be the same type (single or double), or this error message appears:
AT--005: Missing or invalid closing quote on attribute
Further experimentation with one attribute, font_out_name1, showed that
$B5$C4'fred'$C3
was encoded by gendev as
$B5$C4fred$C3
just as if the entire string were delimited or, since it does not have spaces, no delimiters were used at all. More intriguingly,
'testfon_outname1'$C5
was encoded by gendev as
testfon_outname1
suggesting that gendev treats a closing delimiter as the end of the string. These details will have to be further explored when gendev is being recreated.
There are some differences between version 3.33 and version 4.1. This section provides a summary. For more information, see the sections discussing the details of the binary device file format.
- The file headers are different.
- The directory files are slightly different.
- These numeric attributes are encoded as two-byte unsigned integers in version 3.33 and as four-byte unsigned integers in version 4.1:
For :DEVICE blocks: 3.33 upper limit 4.1 upper limit
page_width $CCCF $7FFFFFFF
page_depth $CCCF $7FFFFFFF
horizontal_base_units $CCCF $7FFFFFFF
vertical_base_units $CCCF $7FFFFFFF
For :PAGESTART blocks:
x_start $CCCF $7FFFFFFF
y_start $CCCF $7FFFFFFF
For :PAGEOFFSET blocks:
x_start $CCCF $7FFFFFFF
y_start $CCCF $7FFFFFFF
For :FONT blocks:
line_height $CCCF $7FFFFFFF
line_space $CCCF $7FFFFFFF
scale_basis $7FFFFFFF $7FFFFFFF
scale_min $7FFFFFFF $7FFFFFFF
scale_max $7FFFFFFF $7FFFFFFF
char_width $CCCF $7FFFFFFF
For :DBOX, :HLINE, and :VLINE blocks:
thickness (not determined)
- The :WIDTH block comes in two sizes, and the larger size is different in version 3.33 than it is in version 4.1.
The order in which items appear in a binary device file does not depend on the order in which the various components of the encoded block appear in the source file. It does not matter if the order in the source file is fixed or if it can vary.
The order shown for all fields of all structs shown is the only order in which those fields appear. All of these fields are required in the sense that, if they are not present, the file contains a clear indicator that they are not present, which is to say that all fields are present, if only vistigially. This is the reason that a file error or premature end-of-file while reading a binary device file is the same as an error in the format: the format requires that all fields be present, if only vistigially, so their complete absence is a formatting error.
Parsing a binary device file involves reducing it to semantically meaningful units, and the bulk of this page (and associated pages) deals with those units in detail. These units are composed of semantic elements, which can be classified into three groups:
- Character data, which can hold any byte value.
- String data, which cannot include null bytes.
- 8-bit, 16-bit, and 32-bit unsigned integers.
Unless otherwise noted in the detailed discussions, character data has these properties:
- Each character has its own unique significance, even when multiple characters appear in sets.
Unless otherwise noted in the detailed discussions, string data has these properties:
- The significance of a string lies in the entire string taken as a unit, not in the individual characters.
- Most strings are preceeded by a count byte; any "terminating null" in this case is part of the next semantic element.
- Some strings are instead terminated by a null byte, which is part of the string considered as a semantic element in the binary device file.
Unless otherwise noted in the detailed discussions, integers have these properties:
- The values are unsigned.
- 8-bit values are used to count the number of following bytes, which may be character or numeric data as well as strings or even sementic units containing several semantic elements.
- Internal data, such as counts of repeated semantic units, are encoded by 16-bit values.
- Attributes which are encoded as 16-bit values in version 3.33 are encoded as 32-bit values in version 4.1.
The basic tool in analyzing the binary device file format was a small set of test source files. These files changed so rapidly that no attempt was made to preserve their various versions.
Attributes with character or string values were located in the binary device file by providing them with a known value in the source file and looking for it in the binary device file, and then changing it in the source file to confirm that the value found in the binary device file also changed.
Attributes with numeric values were located using the decimal equivalents of such values as "0x1111", "0x2222" and so on for 16-bit integers and "0x11111111", "0x22222222" and so on for 32-bit integers (note that each attribute was given a distinct value) and then looking for those values in the binary file. Once the location were found, since I am using a x86 processor which stores integers in "little-endian" format, values such as "0x1122" or "0x11223344" were used to confirm that they are, in fact, stored as integers and not just as arrays of bytes.
The remaining unsigned integers are produced by gendev all on its own, so it is not possible to be certain that they are, in fact, unsigned integers. It is, perhaps, a personal bias that I identify these as integers rather than as arrays of bytes. Unless a big-endian version of one or more binary device files appears, it will never be possible to be certain that these identifications are correct.
As each major type of binary device file was analyzed, the corresponding test file was reworked to form a set of test files which could be used with wgml to determine which CodeBlocks are invoked at what points in creating the output file. This was used to determine, for those :INIT blocks which produce multiple CodeBlocks, the order in which the CodeBlocks are invoked. This led to the interesting discovery that they are invoked by wgml 4.0 in the order given in the source, and that the CodeBlocks encoding :FONTVALUE blocks are invoked multiple times, which, insofar as the struct used for parsing is concerned, meant that each CodeBlock had to be identified as encoding a :VALUE block or a :FONTVALUE block as well as having their order preserved. I expect this sort of investigation to be very helpful when the time comes to produce the output side of wgml.
Here is what wdump -b produces when applied to the wgmlst.cop file in ow\docs\doc\whelp:
0000: 02 0C 00 0B 56 34 2E 31 20 50 43 2F 44 4F 53 04 V4.1 PC/DOS
0010: 02 00 00 00 01 02 08 77 68 65 6C 70 64 72 76 08 whelpdrv
0020: 57 48 45 4C 50 44 52 56 01 01 05 77 68 65 6C 70 WHELPDRV whelp
0030: 05 57 48 45 4C 50 00 00 00 00 00 00 00 00 00 00 WHELP
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Examining other binary device files shows that every binary device file has a header with this structure:
COPHeader {
uint8_t count = { 0x02 };
uint16_t version;
uint8_t text_version_length;
char text_version[ text_version_length ];
uint8_t type;
};
The field count gives the number of bytes in the field version. It can, however, also be used as a "magic value", since any file starting with a different byte cannot be a binary device file.
The the field version differs between version 3.33 and version 4.1:
- version 3.33: 0x000a
- version 4.1: 0x000c
and so is taken to encode the file version. Testing shows that gendev and wgml from one version will not work with binary device files produced by gendev from the other version.
The field length contains the length of the field text_version.
The field text_version differs between version 3.33 and version 4.1:
- version 3.33: V3.33 PC/DOS
- version 4.1: V4.1 PC/DOS
and clearly contains human-readable text giving the version number.
The field type is also a count field, but the values it can contain can also be used to indicate the type of the file:
- version 3.33: 0x02: directory file
- either version: 0x03: device/driver/font file
- version 4.1: 0x04: directory file
while the true significance of the value is:
- 0x02: a two-byte count of directory entries
- 0x03: a three-byte discriminator ("DEV", "DRV" or "FON")
- 0x04: a four-byte count of directory entries
Ending the header with what is, in fact, the count byte for the next field may appear strange. This does make sense when parsing the file is considered: if the function parsing the header simply indicated that it was working on a valid binary device file, each calling function (and there are four of them) would then have to determine for itself whether or not that file was a directory file. It is simpler and more efficient to make this determination in the function parsing the header.
The research program cfcheck.exe has verified that all available binary device files have either 0x02, 0x03, or 0x04 as the value of the count field type. Research programs cfparse.exe and copparse.exe have thoroughly exercised the header parsing code.
Take another look at the contents of the wgmlst.cop file in ow\docs\doc\whelp:
0000: 02 0C 00 0B 56 34 2E 31 20 50 43 2F 44 4F 53 04 V4.1 PC/DOS
0010: 02 00 00 00 01 02 08 77 68 65 6C 70 64 72 76 08 whelpdrv
0020: 57 48 45 4C 50 44 52 56 01 01 05 77 68 65 6C 70 WHELPDRV whelp
0030: 05 57 48 45 4C 50 00 00 00 00 00 00 00 00 00 00 WHELP
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
At first glance, the file (after the header) is as simple as this:
DirFile {
uint32_t count;
DirEntry entries[count];
};
The file illustrated is a version 4.1 directory file. Comparison with a version 3.33 directory file gives this structure for the version 3.33 directory file:
DirFile {
uint16_t count;
DirEntry entries[count];
};
At this point, the page Directory File Format might be worth examining. It explains the actual format currently found in the directory file ow\docs\gml\syslib\wgmlst.cop.
The value of the field count is the number of entries, at least, that is what it clearly contained in the directory files I produced with either version of gendev (the directory file discussed in Directory File Format is, as in so much else, an exception to this).
The compact directory file entries are the defined name/member name pairs which it is the entire purpose of a directory file to provide. They have this structure:
CompactDirEntry {
uint16_t type = < 0x0101 | 0x201 | 0x401 >;
uint8_t defined_name_length;
char defined_name[defined_name_length];
uint8_t member_name_length;
char member_name[member_name_length];
};
The extended directory file entries have this structure:
ExtendedDirEntry {
uint16_t metatype = 0x0001;
uint16_t type = < 0x0101 | 0x201 | 0x401 >;
uint8_t defined_name_length;
char defined_name[defined_name_length];
uint16_t marker = 0x0001;
uint8_t member_name_length;
char member_name[member_name_length];
uint16_t preview = < 0x0101 | 0x201 | 0x401 >;
};
These fields are common to the two structures:
uint16_t type = < 0x0101 | 0x201 | 0x401 >;
uint8_t defined_name_length;
char defined_name[defined_name_length];
uint8_t member_name_length;
char member_name[member_name_length];
The values of the field type have these values:
- 0x101 for a binary device file encoding a :DEVICE block.
- 0x201 for a binary device file encoding a :DRIVER block.
- 0x401 for a binary device file encoding a :FONT block.
The program cfparse.exe has confirmed that, in each case where the binary device file exists, the type and the Discriminator are consistent with the interpretations given above.
The fields defined_name_length and member_name_length provide the number of characters in the associated string.
The field defined_name encodes the value of the attribute defined_name and field member_name encodes the value of the attribute member_name. These attributes are discussed in the section Common Attributes.
These fields are unique to the extended structure:
uint16_t metatype = 0x0001;
uint16_t marker = 0x0001;
uint16_t preview = < 0x0101 | 0x201 | 0x401 >;
- The field metatype indicates that this is an extended rather than a compact DirEntry structure.
- The field marker always has the same value, but it is not clear why it is needed.
- The values of the field preview have the same meaning as the values of the field type but match the value of the field type field of the following DirEntry.
The page Directory File Format should be consulted if more information on the extended structure is needed.
The entire point of a device library is to provide files encoding information used by wgml to format a document for a particular device. The term used for all such files up to this section has been "binary device file". However, now that the directory file has been examined, the term "binary member file" will be used to refer to any of the three remaining types of binary device file. Thus, up to this point, the terms "directory file" and "binary member file" refer to the two main varieties of binary device files.
The three types of binary member files, each corresponding to a particular source code block, are:
- A device file describes the device.
- A driver file provides code which, when executed, will produce the proper commands to control the device.
- A font file describes a particular font, usually for use with a specific device or set of devices.
When these terms are used by themselves, they should be understood to refer to the concepts rather than any specific file. When source or binary is prepended, then they should be understood to refer to the source format or to the binary format (respectively). When file is appended, then the they should be understood to refer to an actual file containing either the source or the binary data, unless "source" or "binary" is prepended to indicate that the reference is specific. Thus, in this section, a "binary device file" is a binary member file which encodes a :DEVICE block describing the device.
Since both version 3.33 and version 4.1 headers use the same type byte (0x03) for these files, and the directory files use the same types (0x101, 0x201 and 0x401) to identify them, it should come as no surprise that there are very few differences between the two versions. A summary of those differences can be found here.
The first item in each binary member file is a three-byte discriminator:
char discriminator[3] =
<'D','E','V' for a device,
'D','R','V' for a driver, or
'F','O','N' for a font>
gendev does check to see that a source file whose defined name already exists in the directory file has the same member name as found for that defined name in the directory file, but whether it checks that the value in the field DirEntry.type is consistent with whether the member source file being processed is a device, driver, or font file is not known at this time -- and, even if it did, checking the descriminator of the existing file would appear to be pointless, since that file will be overwritten by a new one based on the block being processed.
wgml always knows what type of binary member file it is searching for: the only defined name that can correspond to a :DEVICE block is the defined name entered with the DEVICE command line option; the only defined name that can correspond to a :DRIVER block is the one given as the value of the attribute driver_name (which is an attribute found only in a :DEVICE block); and the only defined names that can correspond to :FONT blocks are those given as the values of the various attributes font or fontname (which attributes are found only in a :DEVICE block).
The discriminator, then, can be treated as a final sanity check: if it is the value expected, the file is to be processed; if not, an error is to be reported.
The :DEVICE block was changed from the description in WGML 4 Reference by the README file produceable from the WGML 3.33 Update. The result of this is rather disjointed, so I will be exploring the source file format as well as the binary file format.
All of the statements made describing the requirements imposed on the :DEVICE block by gendev were confirmed by actual test. Many of them match statements made in the documentation or the README and should be taken as confirming the documentation, not as new discoveries.
Due to the size and complexity of the device formats, a separate page, Device File Blocks, will be used to explore the blocks included in the :DEVICE block.
Except as noted, the version 4.1 and version 3.33 source and binary formats for the device file are identical. And, as will be seen, the differences can be detected without having to know the version of the binary file being parsed.
This is the :DEVICE block:
:DEVICE
Attributes
:PAUSE Block
:DEVICEFONT Block
:DEFAULTFONT Block
:FONTPAUSE Block
:BOX Block
:UNDERSCORE Block
:PAGESTART Block
:PAGEOFFSET Block
:INTRANS Block
:OUTTRANS Block
:eDEVICE.
Device File Blocks uses the tags (or "Attributes") to identify the blocks.
The README documents the removal of the :RULE block, which used the tags :RULE and :eRULE and which is no longer allowed, and the changes to the :BOX block (using the tag :DBOX instead of :BOX, which is confusing since :DBOX is a valid tag used in :DRIVER blocks), but the presence of the :PAGEOFFSET block, :INTRANS block, and :OUTTRANS block is not documented in either the WGML 4 Reference or in the wgml 3.33 README as possible blocks inside a :DEVICE block; instead, they were discovered by examining existing source files containing :DEVICE blocks. The structure of the :INTRANS block and of the :OUTTRANS block are documented as part of the :FONT block. The :PAGEOFFSET block is not documented at all (except for an error message for a missing :ePAGEOFFSET tag).
These included blocks are required (the error triggered by each if absent is also shown):
- The Attributes:
AT--001: Required attribute not found.
- The :BOX block:
SN-054: Expecting :box tag.
- The :DEFAULTFONT block:
SN--021: Must have a :defaultfont with font=0.
- The :DEVICEFONT block is required because the font names which are used by the :DEFAULTFONT block (at least one of which must be present) and which may be used by the :BOX block must also be used in a :DEVICEFONT block:
SN-019: Fontname not specified in :devicefont.
- The :FONTPAUSE block is required for every :DEVICEFONT block which provides a name for the attribute fontpause (the same value must appear in the attribute type of the :FONTPAUSE block). Note that an empty string can be used for the attribute fontpause of the :DEVICEFONT block, in which case no :FONTPAUSE block is required.
SN--022: The fontpause in :devicefont has no match in :fontpause.
These included blocks are completely optional:
- The :INTRANS block
- The :OUTTRANS block
- The :PAGEOFFSET block
- The :PAGESTART block
- The :PAUSE block
- The :UNDERSCORE block
These included blocks can have multiple instances:
- The :DEFAULTFONT block
- The :DEVICEFONT block
- The :FONTPAUSE block
- The :INTRANS block
- The :OUTTRANS block
- The :PAUSE block
Extensive tests of block ordering revealed this fact:
All blocks present must be in the order shown.
The details (potentially useful in creating gendev) are:
- If the :PAUSE block follows the :DEVICEFONT block, this error message is produced:
SN-054: Expecting :box tag.
and, if it follows the :BOX block, this error message results:
SN--043: Expecting :edevice tag
- If the :DEVICEFONT block whose value for the attribute fontname matches the value for the attribute fontname used by a :DEFAULTFONT block follows that :DEFAULTFONT block, or if the :DEVICEFONT block whose value for the attribute fontname matches the value for the attribute font used by the :BOX block follows the :BOX block, then this error message results:
SN-019: Fontname not specified in :devicefont.
- If a :DEVICEFONT block whose fontname is not used by a :DEFAULTFONT block is placed after all of the :DEFAULTFONT blocks but before the :BOX block, this error message is produced:
SN-054: Expecting :box tag.
- A :DEVICEFONT block whose fontname is not used anywhere else which is placed after the :BOX block produces this error message:
SN--043: Expecting :edevice tag
- A :DEFAULTFONT block which is placed after the :BOX block produces this error message:
SN--043: Expecting :edevice tag
- A :FONTPAUSE block which is placed before all :DEVICEFONT blocks produces this error message:
SN-054: Expecting :box tag.
- A :FONTPAUSE block which is placed after the :BOX block produces this error message:
SN--043: Expecting :edevice tag
- A :RULE block placed before the :BOX block produces this error message:
SN-054: Expecting :box tag.
when placed after the :BOX block it produces this error message:
SN--043: Expecting :edevice tag
this shows that a :RULE block is no longer allowed in a :DEVICE block.
- If the :BOX block is placed in front of any :PAUSE block or the :DEVICEFONT block whose value for the attribute fontname matches the value for the attribute font value in the :BOX block, then this error message results:
SN-019: Fontname not specified in :devicefont.
- If the :BOX block is placed after all :PAUSE block and after the :DEVICEFONT Block whose value for the attribute fontname matches the value for the attribute font value in the :BOX block, but before the required :DEFAULTFONT block,
this error message results on the :DEFAULTFONT line of the first :DEFAULTFONT block:
SN--043: Expecting :edevice tag
- If the :BOX block is placed after all :PAUSE blocks and after all :DEVICEFONT blocks and after all :DEFAULTFONT blocks, then this error message results on the :FONTPAUSE line of the first :FONTPAUSE block:
SN--043: Expecting :edevice tag
- If the :BOX block is placed after the :UNDERSCORE block, the :PAGESTART block, the :PAGEOFFSET block, an :INTRANS block, or an :OUTTRANS block, then this error message appears:
SN-054: Expecting :box tag.
- If the :UNDERSCORE block, the :PAGESTART block, the :PAGEOFFSET block, an :INTRANS block, or an :OUTTRANS block is placed anywhere before the :BOX block, then this error message appears:
SN-054: Expecting :box tag.
- If the :UNDERSCORE block is placed after the :PAGESTART block, the :PAGEOFFSET block, an :INTRANS block, or an :OUTTRANS block then this error message appears:
SN--043: Expecting :edevice tag
- If the :PAGESTART block is placed after the :PAGEOFFSET block, an :INTRANS block, or an :OUTTRANS block then this error message appears:
SN--043: Expecting :edevice tag
- If the :PAGEOFFSET block is placed after an :INTRANS block or an :OUTTRANS Block, then error message appears:
SN--043: Expecting :edevice tag
- If an :INTRANS Block is placed after an :OUTTRANS Block, then this error message appears.
SN--043: Expecting :edevice tag
Testing produced these additional results:
- This error message:
SN--043: Expecting :edevice tag
appears if more than one instance of the Attributes, the :BOX block, the :UNDERSCORE block, the :PAGESTART block, or the :PAGEOFFSET block is placed in the source file.
Now we come to the binary format used to encode the above structure. Device File Blocks contains the format of the blocks in the resulting binary device file, usually as part of the description of the corresponding source block. The exceptions are:
- The FunctionsBlock, which is a Variant A FunctionsBlock as discussed in Device Functions, encodes the :VALUE blocks of both the :PAUSE blocks and the :FONTPAUSE blocks.
- The PageGeometryBlock, as discussed in Device File Blocks, encodes both the :PAGESTART block and the :PAGEOFFSET block.
- The TranslationBlock, as discussed in Device File Blocks, encodes both the :INTRANS blocks and the :OUTTRANS blocks.
- The attributes defined_name and member_name and the :INTRANS block and the :OUTRANS block are discussed in Common File Blocks.
Here is the overall format of the binary device file, starting with the first byte after the discriminator:
DeviceFile {
Attributes attributes;
uint16_t next_codeblock;
PagegeometryBlock pagegeometry;
BoxBlock box;
UnderscoreBlock underscore;
TranslationBlock translation;
DefaultfontBlock defaultfonts;
FunctionsBlock functions;
PauseBlock pauses;
DevicefontBlock devicefonts;
}
The field next_codeblock requires some explanation. This is the same sort of value found in the fields pauses.start_pause, pauses.document_pause, pauses.docpage_pause, pauses.devpage_pause, and devicefont.devicefonts[].font_pause: it is the sum of the values of all fields functions.codeblocks[].count.
Now that it is known that the compiled code in field CodeBlock.function is, on its highest level, a linked list with a termination indicator, so that the length of the field is not needed to interpret it, a possible use for the field next_codeblock appears: perhaps wgml is using it to allocate a block of memory, copying the CodeBlock.function fields into it in order, and then using the values in the fields pauses.start_pause, pauses.document_pause, pauses.docpage_pause, pauses.devpage_pause, and devicefont.devicefonts[].font_pause as offsets into this block.
This structure has these properties:
- It is correct for both version 3.33 and version 4.1.
- Every field is always present, whether the corresponding sub-block was present in the source file or not.
- Every field is always present in the order shown.
This table shows the number of bytes allocated for the cop_device object, the number of bytes actually used, and the size of each binary device file in the Open Watcom repository development branch:
Device File: Allocated Used File Size
HELP 2048 530 560
PS 4096 3324 2480
TASA 2048 530 560
TERM 2048 686 720
WHELP 2048 531 560
This table shows the number of bytes allocated for the cop_device object, the number of bytes actually used, and the size of each binary device file produced by gendev 4.1 from the source files provided in the WGML 3.33 Update:
Device File: Allocated Used File Size
ASA 2048 529 560
DIA630 2048 579 640
ELQ850DR 2048 829 880
ELQ805LQ 2048 808 800
HPFAXSYS 2048 1798 1600
HPLASER 11264 10333 8160
HPLASRII 13312 12424 9760
HPLASRPL 11264 10568 8320
HPLPLEGL 11264 10566 8320
MLT 2048 559 640
MLTEXP 2048 576 640
PCGRAPH 2048 609 640
PCMATRIX 2048 571 640
PROX24E 2048 732 800
PS 4096 3268 2480
QUME 2048 634 640
TASA 2048 530 560
TERM 2048 686 720
TTY 2048 529 560
X2700 2048 853 880
The code currently begins by allocating 2048 bytes and then increases the block, if necessary, by multiples of 1024. The above suggests that an initial value of 1024 and an increase of 3072 (for PS) would work as well (or better, since PS would then require only one reallocation) for the devices actually in use. However, it appears that realloc() could be used to shrink each the cop_device instance to the actual size needed, freeing the additional space, in which case starting at 4096 would be fastest for the devices used by Open Watcom since, for those devices, no expansion would be needed.
The :DRIVER block was changed from the description in WGML 4 Reference by the README file produceable from the WGML 3.33 Update. The result of this is rather disjointed, so I will be exploring the source file format as well as the binary file format.
All of the statements made describing the requirements imposed on the :DRIVER block by gendev were confirmed by actual test. Many of them match statements made in the documentation or the README and should be taken as confirming the documentation, not as new discoveries.
Due to the size and complexity of the driver formats, a separate page, Driver File Blocks, will be used to explore the blocks included in the :DRIVER block.
Except as noted, the version 4.1 and version 3.33 source and binary formats for the driver file are identical. And, as will be seen, the differences can be detected without having to know the version of the binary file being parsed.
This is the :DRIVER block:
:DRIVER
Attributes
:INIT Block
:FINISH Block
:NEWLINE Block
:NEWPAGE Block
:HTAB Block
:FONTSTYLE Block
:FONTSWITCH Block
:PAGEADDRESS Block
:ABSOLUTEADDRSS Block
:HLINE Block
:VLINE Block
:DBOX Block
:eDRIVER
Driver File Blocks uses the tags (or "Attributes") to identify the blocks.
The README documents the removal of the :BOLDSTART, :BOLDEND, :UNDERSTART, and :UNDEREND blocks, their replacement with the :FONTSTYLE block, and that a :NEWLINE block is no longer required "if :ABSOLUTE is specified". The :FONTSTYLE Block is not documented at all (except for two error messages: SN-084 and SN-088).
These included blocks are required (the error triggered by each if absent is also shown):
- The Attributes:
AT--001: Required attribute not found
- The :NEWPAGE block:
SN--033: Expecting :newpage tag
- Either an :ABSOLUTEADDRESS block or a :NEWLINE block with an attribute advance value of "1" is required. If there is no :ABSOLUTEADDRESS block and no :NEWLINE block, then this error message results:
DF--011: Need a newline with an advance of 1
These included blocks are completely optional:
- The :DBOX block
- The :FINISH block
- The :FONTSTYLE block
- The :FONTSWITCH block
- The :HLINE block
- The :HTAB block
- The :INIT block
- The :PAGEADDRESS block
- The :VLINE block
These included blocks can have multiple instances:
- The :FINISH block
- The :FONTSTYLE block
- The :FONTSWITCH block
- The :INIT block
- The :NEWLINE block
The :FINISH block and the :INIT block can have at most two instances; the others which can have multiple instances can have as many as needed.
Extensive tests of block ordering show these results:
- Although the WGML 4 Reference states that "[w]hen [the blocks] are specified, they must be in the order shown in [the figure showing the structure]", exhaustive (and exhausting) testing shows that the blocks can, in fact, occur in any order whatsoever, so long as they are all placed after the Attributes.
The phrase "any order whatsoever" means exactly what it says:
- If two :INIT blocks are present, it does not matter whether the block with the value START for the attribute place comes before or after the block with the value DOCUMENT for the attribute place.
- If two :FINISH blocks are present, it does not matter whether the block with the value END for the attribute place comes before or after the block with the value DOCUMENT for the attribute place.
- If more than one :NEWLINE block is present, they can be in any order by the value of the attribute advance.
- Whenever more than one instance of the same included block is present, the instances do not have to be grouped in any fashion: each instance can be placed anywhere in the file, before or after any instance of any included block, provided only that the Attributes come first.
Testing produced these additional results:
- Including any of the :BOLDSTART, :BOLDEND, :UNDERSTART, or :UNDEREND blocks produces this error message at the start of the first which is encountered:
SN--036: Expecting :edriver tag
this shows that these blocks are no longer allowed in a :DRIVER block.
- Using a value other than START or DOCUMENT for the attribute place in an :INIT block produces this error:
AT--003: Invalid attribute value
- A second :INIT block with the value START or DOCUMENT for the attribute place produces this statement:
Place value was already used.
and this error message:
AT--004: Attribute already found
- Using a value other than END or DOCUMENT for the attribute place in a :FINISH block produces this error:
AT--003: Invalid attribute value
- A second :FINISH block with the value END or DOCUMENT for the attribute place produces this statement:
Place value was already used.
and this error:
AT--004: Attribute already found
- The values for the attribute advance of the :NEWLINE block, when more than one block is present, need not be contiguous.
- Multiple :FONTSWITCH blocks may be placed in the source file; however, if more than one :FONTSWITCH block has the same value for the attribute type, this error message results:
SN--030: Duplicate :fontswitch type
- Multiple :FONTSTYLE blocks may be placed in the source file; however, if more than one :FONTSTYLE block has the same value for the attribute type, this error message results:
SN--084: Duplicate :fontstyle type
- There can be at most one :PAGEADDRESS block; if a second :PAGEADDRESS block is encountered, this error results:
SN--066: More than one :pageaddress specified
- There can be at most one :ABSOLUTEADDRESS block; if a second :ABSOLUTEADDRESS block is found, this error message appears:
SN--067: More than one :absoluteaddress specified
- There can be at most one :HLINE block; if a second :HLINE block is found, this error message appears:
SN--075: More than one :hline specified
- There can be at most one :VLINE block; if a second :HLINE block is found, this error message appears:
SN--076: More than one :vline specified
- There can be at most one :DBOX block; if a second :DBOX block is found, this error message appears:
SN--077: More than one :dbox specified
Now we come to the binary format used to encode the above structure. Driver File Blocks contains the format of the blocks in the resulting binary driver file, usually as part of the description of the corresponding source block. The exceptions are:
- The various FunctionsBlock variants, and the CodeBlock structure, are discussed in Device Functions.
- The attributes defined_name and member_name are discussed in the section Common Attributes.
Here is the overall format of the binary driver file, starting with the first byte after the discriminator:
DriverFile {
Attributes attributes;
PageAddressBlock pageaddress;
InitFuncs inits;
FinishFuncs finishes;
NewlineFuncs newlines;
FunctionsBlock unknown;
FunctionsBlock newpage;
FunctionsBlock htab;
FontswitchFuncs fontswitches;
FontstyleGroup fontstyles;
FunctionsBlock absoluteaddress;
HlineBlock hline;
VlineBlock vline;
DboxBlock dbox;
};
Fields of type FunctionsBlock are all Variant A FunctionsBlocks.
The field unknown is a blank P-buffer. While other possibilities doubtless exist, I suspect one of these is the correct explanation:
- There may be an unknown block that can occur in a :DRIVER but for which we have neither documentation nor example.
- This may have been where the :BOLDSTART, :BOLDEND, :UNDERSTART, and :UNDEREND blocks were encoded, when they were allowed in a :DRIVER block, if they were encoded in a single FunctionsBlock of some sort.
This structure has these properties:
- It is correct for both version 3.33 and version 4.1.
- Every field is always present, whether the corresponding sub-block was present in the source file or not.
- Every field is always present in the order shown.
This table shows the number of bytes allocated for the cop_driver object, the number of bytes actually used, and the size of each binary driver file in the Open Watcom repository development branch:
Device File: Allocated Used File Size
HELPDRV 2048 710 1520
PSDRV 8192 8074 9120
TASADRV 2048 874 1920
TERMDRV 2048 325 1600
WHELPDRV 3072 2586 3920
This table shows the number of bytes allocated for the cop_driver object, the number of bytes actually used, and the size of each binary driver file produced by gendev 4.1 from the source files provided in the WGML 3.33 Update:
Device File: Allocated Used File Size
ASADRV 2048 856 1840
D630DRV 2048 1352 2560
DR850DRV 2048 1556 2560
HPLDRV 2048 1377 2240
HPLPDRV 3072 2976 4000
HPLPLDRV 3072 2976 4000
LQ850DRV 2048 1881 3120
MLTDRV 2048 1535 2400
MLTEDRV 2048 1942 2800
PCMADRV 2048 1083 2000
PSDRV 8192 7368 8320
QUMEDRV 2048 1633 2800
TASADRV 2048 874 1920
TERMDRV 2048 313 1520
TTYDRV 2048 844 1920
X24EDRV 2048 1478 2560
X2700DRV 2048 1963 2640
The code currently begins by allocating 2048 bytes and then increases the block, if necessary, by multiples of 1024. The above suggests that an initial value of 3072 (for WHLPDRV) and an increase of 5120 (for PS) would work well for the drivers actually in use. However, it appears that realloc() could be used to shrink each the cop_driver instance to the actual size needed, freeing the additional space, in which case starting at 8192 would be fastest for all of the drivers listed above, whether used by Open Watcom or not, since no expansion would be needed.
The :FONT block was changed from the description in WGML 4 Reference by the README file produceable from the WGML 3.33 Update. Although the :FONT block is so simple that the result of this can not really be called "disjointed", I will still be exploring the source file format as well as the binary file format.
All of the statements made describing the requirements imposed on the :FONT block by gendev were confirmed by actual test. Many of them match statements made in the documentation or the README and should be taken as confirming the documentation, not as new discoveries.
Although the :FONT block is not nearly as complicated as either the :DEVICE or the :DRIVER block, a separate page, Font File Blocks, will nevertheless be used to explore the blocks included in the :FONT block.
Except as noted, the version 4.1 and version 3.33 source and binary formats for the font file are identical. And, as will be seen, the differences can be detected without having to know the version of the binary file being parsed.
This is the :FONT block:
:FONT
Attributes
:WIDTH Block
:INTRANS Block
:OUTTRANS Block
:eFONT.
Font File Blocks uses the tags (or "Attributes") to identify the blocks.
The README documents the removal of the attribute mono_space_width from the Attributes.
The manual gives this info (in reference to the :WIDTH, :INTRANS and :OUTTRANS Blocks):
Each of the character definition blocks are optional, and may be
specified more tha[n] once and in any order. If specified, they
must follow the font attributes.
Which aptly describes the situation, when emended as shown.
Now we come to the binary format used to encode the above structure. Font File Blocks contains the format of the blocks in the resulting binary device file, usually as part of the description of the corresponding source block. The exceptions are:
- The CharacterDescriptionBlock, as discussed in Font File Blocks, encodes the :INTRANS blocks, the :OUTTRANS blocks, and the :WIDTH blocks.
- The attributes defined_name and member_name and the :INTRANS block and the :OUTRANS block are discussed in Common File Blocks.
Here is the overall format of the binary font file, starting with the first byte after the discriminator:
FontBlock {
Attributes attributes;
CharacterDescriptionBlock characterBlock;
}
At this level of abstraction, this format is not very complicated at all. The CharacterDescriptionBlock, as discussed in Font File Blocks, compensates for this by being rather intricate.
This table shows the number of bytes allocated for the cop_font object, the number of bytes actually used, and the size of each binary font file in the Open Watcom repository development branch:
Font File: Allocated Used File Size
MONO01 2048 52 80
PSAB 2048 1092 1120
PSABO 2048 1099 1120
PSAD 2048 1092 1120
PSADO 2048 1099 1120
PSBD 2048 1089 1120
PSBDI 2048 1095 1120
PSBL 2048 1090 1120
PSBLI 2048 1096 1120
PSCB 2048 65 80
PSCO 2048 60 80
PSCOB 2048 68 80
PSCOBO 2048 72 80
PSHN 2048 1093 1120
PSHNB 2048 1098 1120
PSHNBO 2048 1105 1120
PSHNO 2048 1101 1120
PSHV 2048 1086 1120
PSHVB 2048 1091 1120
PSHVBO 2048 1098 1120
PSHVO 2048 1094 1120
PSNB 2048 1098 1120
PSNBI 2048 1104 1120
PSNI 2048 1100 1120
PSNR 2048 1099 1120
PSPB 2048 1090 1120
PSPBI 2048 1096 1120
PSPI 2048 1092 1120
PSPR 2048 1091 1120
PSSHADE 2048 52 80
PSSYM 3072 2519 2000
PSTR 2048 1088 1120
PSTRB 2048 1087 1120
PSTRBI 2048 1093 1120
PSTRI 2048 1089 1120
PSZAP 2048 1089 1120
This table shows the number of bytes allocated for the cop_font object, the number of bytes actually used, and the size of each binary font file produced by gendev 4.1 from the source files provided in the WGML 3.33 Update:
Font File: Allocated Used File Size
DIAPROP 2048 1076 320
HP1C10B8 2048 73 80
HP1C10BC 2048 74 80
HP1C10BE 2048 73 80
HP1C10BN 2048 74 80
HP1C10I8 2048 73 80
HP1C10IC 2048 74 80
HP1C10IE 2048 73 80
HP1C10IN 2048 74 80
HP1C10M8 2048 73 80
HP1C10MC 2048 74 80
HP1C10ME 2048 73 80
HP1C10MN 2048 74 80
HP1C12I8 2048 73 80
HP1C12IC 2048 74 80
HP1C12IE 2048 73 80
HP1C12IN 2048 74 80
HP2H14B8 2048 1097 400
HP2H14BC 2048 1098 400
HP2H14BE 2048 1097 400
HP2H14BN 2048 1098 400
HP2T08M8 2048 1095 400
HP2T08MC 2048 1096 400
HP2T08ME 2048 1095 400
HP2T08MN 2048 1096 400
HP2T12B8 2048 1097 400
HP2T12BC 2048 1098 400
HP2T12BE 2048 1097 400
HP2T12BN 2048 1098 400
HP2T12I8 2048 1097 400
HP2T12IC 2048 1098 400
HP2T12IE 2048 1097 400
HP2T12IN 2048 1098 400
HP2T12M8 2048 1097 400
HP2T12MC 2048 1098 400
HP2T12ME 2048 1097 400
HP2T12MN 2048 1098 400
HPAC12B8 2048 73 80
HPAC12I8 2048 73 80
HPBH14BA 2048 1101 400
HPBT08MA 2048 1095 400
HPBT10BA 2048 1097 400
HPBT10IA 2048 1097 400
HPBT10MA 2048 1097 400
HPCC12B8 2048 73 80
HPCC12BA 2048 73 80
HPCC12BF 2048 73 80
HPCC12BG 2048 73 80
HPCC12BH 2048 73 80
HPCC12BI 2048 73 80
HPCC12BK 2048 73 80
HPCC12BS 2048 73 80
HPCC12BW 2048 73 80
HPCC12I8 2048 73 80
HPCC12IA 2048 73 80
HPCC12IF 2048 73 80
HPCC12IG 2048 73 80
HPCC12IH 2048 73 80
HPCC12II 2048 73 80
HPCC12IK 2048 73 80
HPCC12IS 2048 73 80
HPCC12IW 2048 73 80
HPCC12M8 2048 73 80
HPCC12MA 2048 73 80
HPCC12MF 2048 73 80
HPCC12MG 2048 73 80
HPCC12MH 2048 73 80
HPCC12MI 2048 73 80
HPCC12MK 2048 73 80
HPCC12MS 2048 73 80
HPCC12MW 2048 73 80
HPCN09M8 2048 77 80
HPCN09MA 2048 77 80
HPCN09MF 2048 77 80
HPCN09MG 2048 77 80
HPCN09MH 2048 77 80
HPCN09MI 2048 77 80
HPCN09MK 2048 77 80
HPCN09MS 2048 77 80
HPCN09MW 2048 77 80
HPDP10B8 2048 73 80
HPDP10BA 2048 73 80
HPDP10I8 2048 73 80
HPDP10IA 2048 73 80
HPDP10M8 2048 73 80
HPDP10MA 2048 73 80
HPEG12B8 2048 73 80
HPEG12BA 2048 73 80
HPEG12I8 2048 73 80
HPEG12IA 2048 73 80
HPEG12M8 2048 73 80
HPEG12MA 2048 73 80
HPFH14B8 2048 1101 400
HPFH14BA 2048 1101 400
HPFN09M8 2048 77 80
HPFN09MA 2048 77 80
HPFT08M8 2048 1095 400
HPFT08MA 2048 1095 400
HPFT10B8 2048 1097 400
HPFT10BA 2048 1097 400
HPFT10I8 2048 1097 400
HPFT10IA 2048 1097 400
HPFT10M8 2048 1097 400
HPFT10MA 2048 1097 400
HPFXC12B 2048 88 160
HPFXC12M 2048 88 160
HPFXH08M 2048 1096 400
HPFXH10B 2048 1096 400
HPFXH10I 2048 1096 400
HPFXH10M 2048 1096 400
HPFXH12B 2048 1096 400
HPFXH12I 2048 1096 400
HPFXH12M 2048 1096 400
HPFXH14B 2048 1096 400
HPFXH14I 2048 1096 400
HPFXH14M 2048 1096 400
HPFXH18B 2048 1096 400
HPFXH24B 2048 1096 400
HPFXT08M 2048 1096 400
HPFXT10B 2048 1096 400
HPFXT10I 2048 1096 400
HPFXT10M 2048 1096 400
HPFXT12B 2048 1096 400
HPFXT12I 2048 1096 400
HPFXT12M 2048 1096 400
HPFXT14B 2048 1096 400
HPFXT14I 2048 1096 400
HPFXT14M 2048 1096 400
HPFXT18M 2048 1096 400
HPFXT24M 2048 1096 400
HPGL12MD 2048 73 80
HPGP07MA 2048 75 80
HPGP07ML 2048 75 80
HPGP10BA 2048 73 80
HPGP10BL 2048 73 80
HPGP10IA 2048 73 80
HPGP10IL 2048 73 80
HPGP10MA 2048 73 80
HPGP10ML 2048 73 80
HPHC12BA 2048 73 80
HPHC12BL 2048 73 80
HPHC12IA 2048 73 80
HPHC12IL 2048 73 80
HPHC12MA 2048 73 80
HPHC12ML 2048 73 80
HPHL12MD 2048 73 80
HPHP07MA 2048 75 80
HPHP07ML 2048 75 80
HPIC12B8 2048 73 80
HPIC12BC 2048 74 80
HPIC12BE 2048 73 80
HPIC12BN 2048 74 80
HPIC12M8 2048 73 80
HPIC12MA 2048 73 80
HPIC12MC 2048 74 80
HPIC12ME 2048 73 80
HPIC12MN 2048 74 80
HPIC12MX 2048 73 80
HPIN09M8 2048 77 80
HPIN09MA 2048 77 80
HPIN09MC 2048 78 80
HPIN09ME 2048 77 80
HPIN09MN 2048 78 80
HPIN09MX 2048 77 80
HPJP07M8 2048 75 80
HPJP07MA 2048 75 80
HPJP07MM 2048 75 80
HPJP10B8 2048 73 80
HPJP10BA 2048 73 80
HPJP10I8 2048 73 80
HPJP10IA 2048 73 80
HPJP10M7 2048 73 80
HPJP10M8 2048 73 80
HPJP10MA 2048 73 80
HPJP10MM 2048 73 80
HPJP10MO 2048 74 80
HPKT08M8 2048 1095 400
HPKT08MA 2048 1095 400
HPKT08MM 2048 1095 400
HPKT10B8 2048 1097 400
HPKT10BA 2048 1097 400
HPKT10I8 2048 1097 400
HPKT10IA 2048 1097 400
HPKT10M7 2048 1097 400
HPKT10M8 2048 1097 400
HPKT10MA 2048 1097 400
HPKT10MM 2048 1097 400
HPKT10MO 2048 1098 400
HPLC12B8 2048 73 80
HPLC12I8 2048 73 80
HPLN09M8 2048 77 80
HPMP10B8 2048 73 80
HPMP10I8 2048 73 80
HPMP10M8 2048 73 80
HPNG12B8 2048 73 80
HPNG12I8 2048 73 80
HPNG12M8 2048 73 80
HPPT10B8 2048 1097 400
HPPT10I8 2048 1097 400
HPPT10M8 2048 1097 400
HPQC12B8 2048 73 80
HPQC12I8 2048 73 80
HPQG12B8 2048 73 80
HPQG12M8 2048 73 80
HPRG14MA 2048 73 80
HPRG14ML 2048 73 80
HPRL14MD 2048 73 80
HPRR14BA 2048 74 80
HPRR14BL 2048 74 80
HPRR16BA 2048 75 80
HPRR16BL 2048 75 80
HPRR18BA 2048 75 80
HPRR18BL 2048 75 80
HPTH06MA 2048 1095 400
HPTH08BA 2048 1095 400
HPTH08MA 2048 1095 400
HPTH10BA 2048 1097 400
HPTH12BA 2048 1097 400
HPTH14BA 2048 1097 400
HPUG10M8 2048 77 80
HPUH06M8 2048 1095 400
HPUH08M8 2048 1095 400
HPUH10B8 2048 1097 400
HPUH12B8 2048 1097 400
HPUH14B8 2048 1097 400
HPUL12MD 2048 73 80
HPVG10M8 2048 77 80
HPVH06M8 2048 1095 400
HPVH08M8 2048 1095 400
HPVH10B8 2048 1097 400
HPVH12B8 2048 1097 400
HPVH14B8 2048 1097 400
HPVL12MD 2048 73 80
HPW346M8 2048 74 80
HPW381M8 2048 74 80
HPWG10M8 2048 77 80
HPWG10MA 2048 77 80
HPWG14M8 2048 73 80
HPWG14MA 2048 73 80
HPWL12MD 2048 73 80
HPWO12MR 2048 73 80
HPXB12MB 2048 73 80
HPXG10M8 2048 77 80
HPXG10MA 2048 77 80
HPXG14M8 2048 73 80
HPXG14MA 2048 73 80
HPXL12MD 2048 73 80
HPYC12B8 2048 73 80
HPYC12I8 2048 73 80
HPYC12M8 2048 73 80
HPYN09M8 2048 77 80
HPZH08M8 2048 1095 400
HPZH08MA 2048 1095 400
HPZH08ME 2048 1095 400
HPZH10B8 2048 1097 400
HPZH10BA 2048 1097 400
HPZH10BE 2048 1097 400
HPZH10I8 2048 1097 400
HPZH10IA 2048 1097 400
HPZH10IE 2048 1097 400
HPZH10M8 2048 1097 400
HPZH10MA 2048 1097 400
HPZH10ME 2048 1097 400
HPZH12B8 2048 1097 400
HPZH12BA 2048 1097 400
HPZH12BE 2048 1097 400
HPZH12I8 2048 1097 400
HPZH12IA 2048 1097 400
HPZH12IE 2048 1097 400
HPZH12M8 2048 1097 400
HPZH12MA 2048 1097 400
HPZH12ME 2048 1097 400
HPZH14B8 2048 1097 400
HPZH14BA 2048 1097 400
HPZH14BE 2048 1097 400
HPZN09M8 2048 77 80
HPZN09MA 2048 77 80
HPZN09ME 2048 77 80
HPZT08M8 2048 1095 400
HPZT08MA 2048 1095 400
HPZT08ME 2048 1095 400
HPZT10B8 2048 1097 400
HPZT10BA 2048 1097 400
HPZT10BE 2048 1097 400
HPZT10I8 2048 1097 400
HPZT10IA 2048 1097 400
HPZT10IE 2048 1097 400
HPZT10M8 2048 1097 400
HPZT10MA 2048 1097 400
HPZT10ME 2048 1097 400
HPZT12B8 2048 1097 400
HPZT12BA 2048 1097 400
HPZT12BE 2048 1097 400
HPZT12I8 2048 1097 400
HPZT12IA 2048 1097 400
HPZT12IE 2048 1097 400
HPZT12M8 2048 1097 400
HPZT12MA 2048 1097 400
HPZT12ME 2048 1097 400
HPZT14B8 2048 1097 400
HPZT14BA 2048 1097 400
HPZT14BE 2048 1097 400
LQ850C17 2048 52 80
LQ850D10 2048 54 80
LQ850D12 2048 54 80
LQ850D15 2048 54 80
LQ850D17 2048 52 80
LQ850D20 2048 52 80
LQ850E12 2048 54 80
LQ850E20 2048 52 80
LQ850M15 2048 54 80
LQ850P10 2048 54 80
LQ850PRO 2048 1076 320
MLTRES 2048 52 80
MONO01 2048 52 80
MONO07 2048 52 80
MONO12 2048 52 80
MONO12H8 2048 52 80
MONO24 2048 52 80
PSAB 2048 1092 1120
PSABO 2048 1099 1120
PSAD 2048 1092 1120
PSADO 2048 1099 1120
PSBD 2048 1089 1120
PSBDI 2048 1095 1120
PSBL 2048 1090 1120
PSBLI 2048 1096 1120
PSCB 2048 65 80
PSCO 2048 60 80
PSCOB 2048 68 80
PSCOBO 2048 72 80
PSHN 2048 1093 1120
PSHNB 2048 1098 1120
PSHNBO 2048 1105 1120
PSHNO 2048 1101 1120
PSHV 2048 1096 1120
PSHVB 2048 1091 1120
PSHVBO 2048 1098 1120
PSHVO 2048 1094 1120
PSNB 2048 1098 1120
PSNBI 2048 1104 1120
PSNI 2048 1100 1120
PSNR 2048 1099 1120
PSPB 2048 1090 1120
PSPBI 2048 1096 1120
PSPI 2048 1092 1120
PSPR 2048 1091 1120
PSSYM 3072 2519 2000
PSTR 2048 1088 1120
PSTRB 2048 1087 1120
PSTRBI 2048 1093 1120
PSTRI 2048 1089 1120
PSZAP 2048 1089 1120
QUME10 2048 52 80
QUME12 2048 52 80
QUMEPROP 2048 1076 320
X24EC10 2048 52 80
X24EC17 2048 52 80
X24EE12 2048 52 80
X24EPRO 2048 1076 320
XBOPS 2048 1094 400
XBOPSBIO 3072 2150 640
XBOPSBO 3072 2149 640
XBOPSIO 3072 2149 640
XBOPSO 3072 2148 640
XCP125O 2048 1125 400
XCP14 2048 1093 400
XEL12 2048 1095 400
XEL12BO 3072 2150 640
XEL12O 3072 2149 640
XKO10 2048 1096 400
XKO10B 2048 1097 400
XKO12 2048 1096 400
XKO12B 2048 1097 400
XKO14 2048 1096 400
XKO6 2048 1095 400
XKO8 2048 1095 400
XKO8B 2048 1096 400
XLG10BO 3072 2157 640
XLG10O 3072 2156 640
XLG12 2048 1102 400
XLG12BO 3072 2157 640
XLG12O 3072 2156 640
XLG15BO 3072 2157 640
XLG15O 3072 2156 640
XMA12BO 3072 2151 640
XMA12O 3072 2150 640
XOA10 2048 1094 400
XOB10 2048 1094 400
XSC10 2048 1097 400
XSP10 2048 1099 400
XSP10BO 3072 2154 640
XSP10O 3072 2153 640
XTI10 2048 1095 400
XTI10B 2048 1096 400
XTI10BIO 3072 2151 640
XTI10BO 3072 2150 640
XTI10I 2048 1096 400
XTI10IO 3072 2150 640
XTI10O 3072 2149 640
XTI12BO 3072 2150 640
XTI12IO 3072 2150 640
XTI12O 3072 2149 640
XTJ10BO 3072 2151 640
XTJ10O 3072 2150 640
XTRPS 2048 1095 400
XTRPSBO 3072 2150 640
XTRPSO 3072 2149 640
XVI10BO 3072 2152 640
XVI10O 3072 2151 640
XVI12 2048 1097 400
XVI12BO 3072 2152 640
XVI12O 3072 2151 640
The code currently begins by allocating 2048 bytes and then increases the block, if necessary, by multiples of 1024. The above suggests that this should work all right in almost all cases. It appears that realloc() could be used to shrink each the cop_font instance to the actual size needed, freeing the additional space, in which case starting at 3072 would be fastest for all of the fonts listed above, whether used by Open Watcom or not, since no expansion would be needed.
All available binary device files (in general, that is, including both directory files and binary member files) have been checked by the research program cfcheck.exe and have a length which is a multiple of 16. This is true for both version 3.33 and version 4.1 files. Whether this is necessary (that is, whether wgml requires it) is not yet known.
- Welcome
- Building
- Open Watcom Documentation
- Notes
- Relicensing effort
- Debugging
- OW tools usage Overview
- OW tools usage with CMake
- OW tools usage with Visual Studio Code
- Open Watcom 1.9 Wiki
OW Development
WGML Development
- WGML
- Augmented Devices
- Binary Device Files
- Common File Blocks
- COP Files
- Device File Blocks
- Device Function Language
- Device Function Notes
- Device Functions
- Directory File Format
- Drawing Boxes
- Driver File Blocks
- File and Directory Names
- Font File Blocks
- Fonts
- GML Tag Notes
- Keyword Statistics
- Macros and User Defined Tags
- Meta Data
- Page Layout Subsystem
- Search Paths
- Sequencing
- System Symbol Notes
- Tabs and Tabbing
- whpcvt Utility interaction