An .ICL file -- ICon Library, as used by icon editors like Microangelo -- is a renamed 16-bit Windows .DLL (an NE format executable) which typically contains nothing but a resource section.
The ICL extension seems to be used by convention.
Icon Library .ICL File Format
.WMF Metafile Format
.WMF Metafile Format
A metafile for the Microsoft Windows operating system consists of a collection of graphics device interface (GDI) functions that describe an image. Because metafiles take up less space and are more device-independent than bitmaps, they provide convenient storage for images that appear repeatedly in an application or need to be moved from one application to another. To generate a metafile, a Windows application creates a special device context that sends GDI commands to a file or memory for storage. The application can later play back the metafile and display the image. During playback, Windows breaks the metafile down into records and identifies each object with an index to a handle table. When a META_DELETEOBJECT record is encountered during playback, the associated object is deleted from the handle table. The entry is then reused by the next object that the metafile creates. To ensure compatibility, an application that explicitly manipulates records or builds its own metafile should manage the handle table in the same way. For more information on the format of the handle table, see the HANDLETABLE structure.
In some cases, there are two variants of a metafile record, one representing the record created by Windows versions before 3.0 and the second representing the record created by Windows versions 3.0 and later. Windows versions 3.0 and later play all metafile versions but store only 3.0 and later versions. Windows versions earlier than 3.0 do not play metafiles recorded by Windows versions 3.0 and later. A metafile consists of two parts: a header and a list of records. The header and records are described in the remainder of this topic. For a list of function-specific records, see Metafile Records.
Metafile Header
The metafile header contains a description of the size of the metafile and the number of drawing objects it uses. The drawing objects can be pens, brushes, bitmaps, or fonts.
The metafile header has the following form:
typedef struct tagMETAHEADER {
WORD mtType;
WORD mtHeaderSize;
WORD mtVersion;
DWORD mtSize;
WORD mtNoObjects;
DWORD mtMaxRecord;
WORD mtNoParameters;
} METAHEADER;
Following are the members in the metafile header:
| mtType | Specifies whether the metafile is stored in memory or recorded in a file. This member has one of the following values: 0 : Metafile is in memory. 1 : Metafile is in a file. |
| mtHeaderSize | Specifies the size, in words, of the metafile header. |
| mtVersion | Specifies the Windows version number. The version number for Windows version 3.0 and later is 0x300. |
| mtSize | Specifies the size, in words, of the file. |
| mtNoObjects | Specifies the maximum number of objects that can exist in the metafile at the same time. |
| mtMaxRecord | Specifies the size, in words, of the largest record in the metafile. |
| mtNoParameters | Not used. |
Typical Metafile Record
The graphics device interface stores most of the GDI functions that an application can use to create metafiles in typical records.
A typical metafile record has the following form:
struct {
DWORD rdSize;
WORD rdFunction;
WORD rdParm[];
}
Following are the members in a typical metafile record:
| rdSize | Specifies the size, in words, of the record. |
| rdFunction | Specifies the function number. This value may be the number of any function in the table at the end of this section. |
| rdParm | Identifies an array of words containing the function parameters (listed in the reverse order in which they are passed to the function). |
Following are the GDI functions found in typical records, along with their hexadecimal values:
| GDI function | Value |
| Arc | 0x0817 |
| Chord | 0x0830 |
| Ellipse | 0x0418 |
| ExcludeClipRect | 0x0415 |
| FloodFill | 0x0419 |
| IntersectClipRect | 0x0416 |
| LineTo | 0x0213 |
| MoveTo | 0x0214 |
| OffsetClipRgn | 0x0220 |
| OffsetViewportOrg | 0x0211 |
| OffsetWindowOrg | 0x020F |
| PatBlt | 0x061D |
| Pie | 0x081A |
| RealizePalette (3.0 and later) | 0x0035 |
| Rectangle | 0x041B |
| ResizePalette (3.0 and later) | 0x0139 |
| RestoreDC | 0x0127 |
| RoundRect | 0x061C |
| SaveDC | 0x001E |
| ScaleViewportExt | 0x0412 |
| ScaleWindowExt | 0x0400 |
| SetBkColor | 0x0201 |
| SetBkMode | 0x0102 |
| SetMapMode | 0x0103 |
| SetMapperFlags | 0x0231 |
| SetPixel | 0x041F |
| SetPolyFillMode | 0x0106 |
| SetROP2 | 0x0104 |
| SetStretchBltMode | 0x0107 |
| SetTextAlign | 0x012E |
| SetTextCharacterExtra | 0x0108 |
| SetTextColor | 0x0209 |
| SetTextJustification | 0x020A |
| SetViewportExt | 0x020E |
| SetViewportOrg | 0x020D |
| SetWindowExt | 0x020C |
| SetWindowOrg | 0x020B |
Placeable Windows Metafiles
A placeable Windows metafile is a standard Windows metafile that has an additional 22-byte header. The header contains information about the aspect ratio and original size of the metafile, permitting applications to display the metafile in its intended form.
The header for a placeable Windows metafile has the following form:
typedef struct {
DWORD key;
HANDLE hmf;
RECT bbox;
WORD inch;
DWORD reserved;
WORD checksum;
} METAFILEHEADER;
Following are the members of a placeable metafile header:
| key | Specifies the binary key that uniquely identifies this file type. This member must be set to 0x9AC6CDD7L. |
| hmf | Unused; must be zero. |
| bbox | Specifies the coordinates of the smallest rectangle that encloses the picture. The coordinates are in metafile units as defined by the inch member. |
| inch | Specifies the number of metafile units to the inch. To avoid numeric overflow, this value should be less than 1440. Most applications use 576 or 1000. |
| reserved | Unused; must be zero. |
| checksum | Specifies the checksum. It is the sum (using the XOR operator) of the first 10 words of the header. |
The actual content of the Windows metafile immediately follows the header. The format for this content is identical to that for
standard Windows metafiles. For some applications, a placeable indows metafile must not exceed 64K.
Note: Placeable Windows metafiles are not compatible with the GetMetaFile function. Applications that intend to use the metafile functions to read and play placeable Windows metafiles must read the file by using an input function (such as _lread), strip the 22-byte header, and create a standard Windows metafile by using the remaining bytes and the SetMetaFileBits function.
Guidelines for Windows Metafiles
To ensure that metafiles can be transported between different computers and applications, any application that creates a metafile should make sure the metafile is device-independent and sizable.
The following guidelines ensure that every metafile can be accepted and manipulated by other applications:
- Set a mapping mode as one of the first records. Many applications, including OLE applications, only accept metafiles that are in MM_ANISOTROPIC mode.
- Call the SetWindowOrg and SetWindowExt functions. Do not call the SetViewportExt or SetViewportOrg functions if the user will be able to resize or change the dimensions of the object.
- Use the MFCOMMENT printer escape to add comments to the metafile.
- Rely primarily on the functions listed in Typical Metafile Record. Observe the following limitations on the functions you use:
- Do not use functions that retrieve data (for example, GetActiveWindow or EnumFontFamilies).
- Do not use any of the region functions (because they are device dependent).
- Use StretchBlt or StretchDIB instead of BitBlt.
Sample of Metafile Program Output
This section describes a sample program and the metafile that it creates. The sample program creates a small metafile that draws a purple rectangle with a green border and writes the words "Hello People" in the rectangle.
MakeAMetaFile(hDC)
HDC hDC;
{
HPEN hMetaGreenPen;
HBRUSH hMetaVioletBrush;
HDC hDCMeta;
HANDLE hMeta;
/* Create the metafile with output going to the disk. */
hDCMeta = CreateMetaFile( (LPSTR) "sample.met");
hMetaGreenPen = CreatePen(0, 0, (DWORD) 0x0000FF00);
SelectObject(hDCMeta, hMetaGreenPen);
hMetaVioletBrush = CreateSolidBrush((DWORD) 0x00FF00FF);
SelectObject(hDCMeta, hMetaVioletBrush);
Rectangle(hDCMeta, 0, 0, 150, 70);
TextOut(hDCMeta, 10, 10, (LPSTR) "Hello People", 12);
/* We are done with the metafile. */
hMeta = CloseMetaFile(hDCMeta);
/* Play the metafile that we just created. */
PlayMetaFile(hDC, hMeta);
}
The resulting metafile, SAMPLE.MET, consists of a metafile header and six records. It has the following binary form:
0001 mtType... disk metafile
0009 mtSize...
0300 mtVersion
0000 0036 mtSize
0002 mtNoObjects
0000 000C mtMaxRecord
0000 mtNoParameters
0000 0008 rdSize
02FA rdFunction (CreatePenIndirect function)
0000 0000 0000 0000 FF00 rdParm (LOGPEN structure defining pen)
0000 0004 rdSize
012D rdFunction (SelectObject)
0000 rdParm (index to object #0... the above pen)
0000 0007 rdSize
02FC rdFunction (CreateBrushIndirect)
0000 00FF 00FF 0000 rdParm (LOGBRUSH structure defining the brush)
0000 0004 rdSize
012D rdFunction (SelectObject)
0001 rdParm (index to object #1... the brush)
0000 0007 rdSize
041B rdFunction (Rectangle)
0046 0096 0000 0000 rdParm (parameters sent to Rectangle...
in reverse order)
0000 000C rdSize
0521 rdFunction (TextOut)
rdParm
000C count
string
48 65 6C 6C 6F 20 50 65 6F 70 6C 65 "Hello People"
000A y-value
000A x-value
ZSoft PCX File Format
Image files used by PC Paintbrush product family and FRIEZE (those with a
.PCX extension) begin with a 128 byte header. Usually you can ignore this
header, since your images will probably all have the same resolution. If
you want to process different resolutions or colors, you will need to
interpret the header correctly. The remainder of the image file consists
of encoded graphic data. The encoding method is a simple byte oriented
run-length technique. We reserve the right to change this method to
improve space efficiency. When more than one color plane is stored in
the file, each line of the image is stored by color plane (generally ordered
red, green, blue, intensity), As shown below.
Scan line 0: RRR... (Plane 0)
GGG... (Plane 1)
BBB... (Plane 2)
III... (Plane 3)
Scan line 1: RRR...
GGG...
BBB...
III... (etc.)
The encoding method is:
FOR each byte, X, read from the file
IF the top two bits of X are 1's then
count = 6 lowest bits of X
data = next byte following X
ELSE
count = 1
data = X
Since the overhead this technique requires is, on average, 25% of
the non-repeating data and is at least offset whenever bytes are repeated,
the file storage savings are usually considerable.
ZSoft .PCX FILE HEADER FORMAT
| Byte | Item | Size | Description/Comments |
| 0 | Manufacturer | 1 | Constant Flag, 10 = ZSoft .pcx |
| 1 | Version | 1 | Version information 0 = Version 2.5 of PC Paintbrush 2 = Version 2.8 w/palette information 3 = Version 2.8 w/o palette information 4 = PC Paintbrush for Windows(Plus for Windows uses Ver 5) 5 = Version 3.0 and > of PC Paintbrush and PC Paintbrush +, includes Publisher's Paintbrush . Includes 24-bit .PCX files |
| 2 | Encoding | 1 | 1 = .PCX run length encoding |
| 3 | BitsPerPixel | 1 | Number of bits to represent a pixel (per Plane) : 1, 2, 4, or 8 |
| 4 | Window | 8 | Image Dimensions: Xmin,Ymin,Xmax,Ymax |
| 12 | HDpi | 2 | Horizontal Resolution of image in DPI* |
| 14 | VDpi | 2 | Vertical Resolution of image in DPI* |
| 16 | Colormap | 48 | Color palette setting, see text |
| 64 | Reserved | 1 | Should be set to 0. |
| 65 | NPlanes | 1 | Number of color planes |
| 66 | BytesPerLine | 2 | Number of bytes to allocate for a scanline plane. MUST be an EVEN number. Do NOT calculate from Xmax-Xmin. |
| 68 | PaletteInfo | 2 | How to interpret palette- 1 = Color/BW, 2 = Grayscale (ignored in PB IV/ IV +) |
| 70 | HscreenSize | 2 | Horizontal screen size in pixels. New field found only in PB IV/IV Plus |
| 72 | VscreenSize | 2 | Vertical screen size in pixels. New field found only in PB IV/IV Plus |
| 74 | Filler | 54 | Blank to fill out 128 byte header. Set all bytes to 0 |
NOTES:
- All sizes are measured in BYTES.
- All variables of SIZE 2 are integers.
- *) HDpi and VDpi represent the Horizontal and Vertical resolutions which the image was created (either printer or scanner); i.e. an image which was scanned might have 300 and 300 in each of these fields.
Decoding .PCX Files
First, find the pixel dimensions of the image by calculating
[XSIZE = Xmax - Xmin + 1] and [YSIZE = Ymax - Ymin + 1]. Then calculate how many bytes are required to hold one complete uncompressed scan line: TotalBytes = NPlanes * BytesPerLineNote that since there are always an even number of bytes per scan line, there will probably be unused data at the end of each scan line. TotalBytes shows how much storage must be available to decode each scan line, including any blank area on the right side of the image. You can now begin decoding the first scan line - read the first byte of data from the file. If the top two bits are set, the remaining six bits in the byte show how many times to duplicate the next byte in the file. If the top two bits are not set, the first byte is the data itself, with a count of one.
Continue decoding the rest of the line. Keep a running subtotal of how many bytes are moved and duplicated into the output buffer. When the subtotal equals TotalBytes, the scan line is complete. There should always be a decoding break at the end of each scan line. But there will not be a decoding break at the end of each plane within each scan line. When the scan line is completed, there may be extra blank data at the end of each plane within the scan line. Use the XSIZE and YSIZE values to find where the valid image data is. If the data is multi-plane, BytesPerLine shows where each plane ends within the scan line.
Continue decoding the remainder of the scan lines (do not just read to end-of-file). There may be additional data after the end of the image (palette, etc.)
Palette Information Description
EGA/VGA 16 Color Palette Information
In standard RGB format (IBM EGA, IBM VGA) the data is stored as 16 triples.
Each triple is a 3 byte quantity of Red, Green, Blue values. The values can
range from 0-255, so some interpretation may be necessary. On an IBM EGA,
for example, there are 4 possible levels of RGB for each color. Since
256/4 = 64, the following is a list of the settings and levels:
Setting Level
0-63 0
64-127 1
128-192 2
193-254 3
VGA 256 Color Palette Information
ZSoft has recently added the capability to store palettes containing more than 16 colors in the .PCX image file. The 256 color palette is formatted and treated the same as the 16 color palette, except that it is substantially longer. The palette (number of colors x 3 bytes in length) is appended to the end of the .PCX file, and is preceded by a 12 decimal. Since the VGA device expects a palette value to be 0-63 instead of 0-255, you need to divide the values read in the palette by 4.
To access a 256 color palette:
- First, check the version number in the header; if it contains a 5 there is
a palette. - Second, read to the end of the file and count back 769 bytes. The value you find should be a 12 decimal, showing the presence of a 256 color palette.
24-Bit .PCX Files
24 bit images are stored as version 5 or above as 8 bit, 3 plane images.
24 bit images do not contain a palette. Bit planes are ordered as lines of red, green, blue in that order.
CGA Color Palette Information
NOTE: This is no longer supported for PC Paintbrush IV/IV Plus.
For a standard IBM CGA board, the palette settings are a bit more complex.
Only the first byte of the triple is used. The first triple has a valid
first byte which represents the background color. To find the background,
take the (unsigned) byte value and divide by 16. This will give a result
between 0-15, hence the background color. The second triple has a valid
first byte, which represents the foreground palette. PC Paintbrush supports
8 possible CGA palettes, so when the foreground setting is encoded between
0 and 255, there are 8 ranges of numbers and the divisor is 32.
CGA Color Map
Header Byte #16: Background color is determined in the upper four bits.
Header Byte #19: Only upper 3 bits are used, lower 5 bits are ignored. The first three bits that are used are ordered C, P, I. These bits are interpreted as follows:
c: color burst enable - 0 = color; 1 = monochrome
p: palette - 0 = yellow; 1 = white
i: intensity - 0 = dim; 1 = bright
QuickBasic BSAVE Format
We'll assume the picture dimensions are width * height x bpp (where bpp means bits per pixel).
File Header
The total length of the header is 7 bytes
| Byte 00 | Must be &HFD (253) to be a valid BSAVE file |
| Bytes 01 to 02 | Segment where the datas were stored in memory before using BSAVE |
| Bytes 03 to 04 | Offset where the datas were stored in memory before using BSAVE |
| Bytes 05 to 06 | width*height*(bpp/8)+5 : Size of the array stored in the file + 5 |
Memory Dump of the buffer got using GET command
| Bytes 07 to 08 | width*bpp | Bytes 09 to 10 | height | Bytes 11 to 11+width*height*(bpp/8) | Color indexes map got using GET command |
Checksum
Last byte : This is a kind of checksum. I have no more information about this byte but it appears to depend on the picture dimensions.
Note: All number in this document are written in decimal
.FNT Font-File Format
Formats for Microsoft Windows font files are defined for both raster and vector fonts. These formats can be used by smart text generators in some GDI support modules. The vector formats, in particular, are more frequently used by GDI itself than by support modules.
Both raster and vector font files begin with information that is common to both, and then continue with information that differs for each type of file.
For Windows 3.00, the font-file header includes six new fields: dFlags, dfAspace, dfBspace, dfCspace, dfColorPointer, and dfReserved1. These fields are not used in Windows 3.00. To ensure compatibility with future versions of Windows, these fields should be set to zero.
All device drivers support the Windows 2.x fonts. However, not all device drivers support the Windows 3.00 version.
Windows 3.00 font files include the glyph table in dfCharTable, which consists of structures that describe the bits for characters in the font file. This version enables fonts to exceed 64K in size, the size limit of Windows 2.x fonts. This is made possible by the use of 32-bit offsets to the character glyphs in dfCharTable.
Because of the 32-bit offsets and their potentially large size, these fonts are designed for use on systems that are running Windows version 3.00 in protected (standard or 386 enhanced) mode with an 80386 (or higher) processor where the processor's 32-bit registers can access the character glyphs. Typically, device drivers use the Windows 3.00 version of a font only when both of these conditions are true.
Font files are stored with an .FNT extension of the form NAME.FNT. The information at the beginning of both raster and vector versions of Windows 3.00 font files is shown in the following list:
| Field | Description |
| dfVersion | 2 bytes specifying the version (0200H or 0300H) of the file. |
| dfSize | 4 bytes specifying the total size of the file in bytes. |
| dfCopyright | 60 bytes specifying copyright information. |
| dfType | 2 bytes specifying the type of font file. The low-order byte is exclusively for GDI use. If the low-order bit of the WORD is zero, it is a bitmap (raster) font file. If the low-order bit is 1, it is a vector font file. The second bit is reserved and must be zero. If no bits follow in the file and the bits are located in memory at a fixed address specified in dfBitsOffset, the third bit is set to 1; otherwise, the bit is set to 0 (zero). The high-order bit of the low byte is set if the font was realized by a device. The remaining bits in the low byte are reserved and set to zero. The high byte is reserved for device use and will always be set to zero for GDI-realized standard fonts. Physical fonts with the high-order bit of the low byte set may use this byte to describe themselves. GDI will never inspect the high byte. |
| dfPoints | 2 bytes specifying the nominal point size at which this character set looks best. |
| dfVertRes | 2 bytes specifying the nominal vertical resolution (dots-per-inch) at which this character set was digitized. |
| dfHorizRes | 2 bytes specifying the nominal horizontal resolution (dots-per-inch) at which this character set was digitized. |
| dfAscent | 2 bytes specifying the distance from the top of a character definition cell to the baseline of the typographical font. It is useful for aligning the baselines of fonts of different heights. |
| dfInternalLeading | Specifies the amount of leading inside the bounds set by dfPixHeight. Accent marks may occur in this area. This may be zero at the designer's option. |
| dfExternalLeading | Specifies the amount of extra leading that the designer requests the application add between rows. Since this area is outside of the font proper, it contains no marks and will not be altered by text output calls in either the OPAQUE or TRANSPARENT mode. This may be zero at the designer's option. |
| dfItalic | 1 (one) byte specifying whether or not the character definition data represent an italic font. The low-order bit is 1 if the flag is set. All the other bits are zero. |
| dfUnderline | 1 byte specifying whether or not the character definition data represent an underlined font. The low-order bit is 1 if the flag is set. All the other bits are 0 (zero). |
| dfStrikeOut | 1 byte specifying whether or not the character definition data represent a struckout font. The low-order bit is 1 if the flag is set. All the other bits are zero. |
| dfWeight | 2 bytes specifying the weight of the characters in the character definition data, on a scale of 1 to 1000. A dfWeight of 400 specifies a regular weight. |
| dfCharSet | 1 byte specifying the character set defined by this font. |
| dfPixWidth | 2 bytes. For vector fonts, specifies the width of the grid on which the font was digitized. For raster fonts, if dfPixWidth is nonzero, it represents the width for all the characters in the bitmap; if it is zero, the font has variable width characters whose widths are specified in the dfCharTable array. |
| dfPixHeight | 2 bytes specifying the height of the character bitmap (raster fonts), or the height of the grid on which a vector font was digitized. |
| dfPitchAndFamily | Specifies the pitch and font family. The low bit is set if the font is variable pitch. The high four bits give the family name of the font. Font families describe in a general way the look of a font. They are intended for specifying fonts when the exact face name desired is not available. The families are as follows:
|
| dfAvgWidth | 2 bytes specifying the width of characters in the font. For fixed-pitch fonts, this is the same as dfPixWidth. For variable-pitch fonts, this is the width of the character "X." |
| dfMaxWidth | 2 bytes specifying the maximum pixel width of any character in the font. For fixed-pitch fonts, this is simply dfPixWidth. |
| dfFirstChar | 1 byte specifying the first character code defined by this font. Character definitions are stored only for the characters actually present in a font. Therefore, use this field when calculating indexes into either dfBits or dfCharOffset. |
| dfLastChar | 1 byte specifying the last character code defined by this font. Note that all the characters with codes between dfFirstChar and dfLastChar must be present in the font character definitions. |
| dfDefaultChar | 1 byte specifying the character to substitute whenever a string contains a character out of the range. The character is given relative to dfFirstChar so that dfDefaultChar is the actual value of the character, less dfFirstChar. The dfDefaultChar should indicate a special character that is not a space. |
| dfBreakChar | 1 byte specifying the character that will define word breaks. This character defines word breaks for word wrapping and word spacing justification. The character is given relative to dfFirstChar so that dfBreakChar is the actual value of the character, less that of dfFirstChar. The dfBreakChar is normally (32 - dfFirstChar), which is an ASCII space. |
| dfWidthBytes | 2 bytes specifying the number of bytes in each row of the bitmap. This is always even, so that the rows start on WORD boundaries. For vector fonts, this field has no meaning. |
| dfDevice | 4 bytes specifying the offset in the file to the string giving the device name. For a generic font, this value is zero. |
| dfFace | 4 bytes specifying the offset in the file to the null-terminated string that names the face. |
| dfBitsPointer | 4 bytes specifying the absolute machine address of the bitmap. This is set by GDI at load time. The dfBitsPointer is guaranteed to be even. |
| dfBitsOffset | 4 bytes specifying the offset in the file to the beginning of the bitmap information. If the 04H bit in the dfType is set, then dfBitsOffset is an absolute address of the bitmap (probably in ROM). For raster fonts, dfBitsOffset points to a sequence of bytes that make up the bitmap of the font, whose height is the height of the font, and whose width is the sum of the widths of the characters in the font rounded up to the next WORD boundary. For vector fonts, it points to a string of bytes or words (depending on the size of the grid on which the font was digitized) that specify the strokes for each character of the font. The dfBitsOffset field must be even. |
| dfReserved | 1 byte, not used. |
| dfFlags | 4 bytes specifying the bits flags, which are additional flags that define the format of the Glyph bitmap, as follows:
|
| dfAspace | 2 bytes specifying the global A space, if any. The dfAspace is the distance from the current position to the left edge of the bitmap. |
| dfBspace | 2 bytes specifying the global B space, if any. The dfBspace is the width of the character. |
| dfCspace | 2 bytes specifying the global C space, if any. The dfCspace is the distance from the right edge of the bitmap to the new current position. The increment of a character is the sum of the three spaces. These apply to all glyphs and is the case for DFF_ABCFIXED. |
| dfColorPointer | 4 bytes specifying the offset to the color table for color fonts, if any. The format of the bits is similar to a DIB, but without the header. That is, the characters are not split up into disjoint bytes. Instead, they are left intact. If no color table is needed, this entry is NULL. [NOTE: This information is different from that in the hard-copy Developer's Notes and reflects a correction.] |
| dfReserved1 | 16 bytes, not used. [NOTE: This information is different from that in the hard-copy Developer's Notes and reflects a correction.] |
| dfCharTable | For raster fonts, the CharTable is an array of entries each consisting of two 2-byte WORDs for Windows 2.x and three 2-byte WORDs for Windows 3.00. The first WORD of each entry is the character width. The second WORD of each entry is the byte offset from the beginning of the FONTINFO structure to the character bitmap. For Windows 3.00, the second and third WORDs are used for the offset. There is one extra entry at the end of this table that describes an absolute-space character. This entry corresponds to a character that is guaranteed to be blank; this character is not part of the normal character set. The number of entries in the table is calculated as ((dfLastChar - dfFirstChar) + 2). This includes a spare, the sentinel offset mentioned in the following paragraph.For fixed-pitch vector fonts, each 2-byte entry in this array specifies the offset from the start of the bitmap to the beginning of the string of stroke specification units for the character. The number of bytes or WORDs to be used for a particular character is calculated by subtracting its entry from the next one, so that there is a sentinel at the end of the array of values. For proportionally spaced vector fonts, each 4-byte entry is divided into two 2-byte fields. The first field gives the starting offset from the start of the bitmap of the character strokes. The second field gives the pixel width of the character. |
| <facename> | An ASCII character string specifying the name of the font face. The size of this field is the length of the string plus a NULL terminator. |
| <devicename> | An ASCII character string specifying the name of the device if this font file is for a specific device. The size of this field is the length of the string plus a NULL terminator. |
| <bitmaps> | This field contains the character bitmap definitions. Each character is stored as a contiguous set of bytes. (In the old font format, this was not the case.) The first byte contains the first 8 bits of the first scanline (that is, the top line of the character). The second byte contains the first 8 bits of the second scanline. This continues until a first "column" is completely defined. The following byte contains the next 8 bits of the first scanline, padded with zeros on the right if necessary (and so on, down through the second "column"). If the glyph is quite narrow, each scanline is covered by 1 byte, with bits set to zero as necessary for padding. If the glyph is very wide, a third or even fourth set of bytes can be present. Note: The character bitmaps must be stored contiguously and arranged in ascending order. The following is a single-character example, in which are given the bytes for a 12 x 14 pixel character, as shown here schematically.
The bytes are given here in two sets, because the character is less than 17 pixels wide. Note that in the second set of bytes, the second digit of each is always zero. It would correspond to the 13th through 16th pixels on the right side of the character, if they were present. |
The Windows 2.x version of dfCharTable has a GlyphEntry structure with the following format:
GlyphEntry struc
geWidth dw ? ;width of character bitmap in pixels
geOffset dw ? ;pointer to the bits
GlyphEntry ends
The Windows 3.00 version of the dfCharTable is dependent on the format of the Glyph bitmap.
Note: The only formats supported in Windows 3.00 will be DFF_FIXED and DFF_PROPORTIONAL.
DFF_FIXED
DFF_PROPORTIONAL
GlyphEntry struc
geWidth dw ? ;width of character bitmap in pixels
geOffset dd ? ;pointer to the bits
GlyphEntry ends
DFF_ABCFIXED
DFF_ABCPROPORTIONAL
GlyphEntry struc
geWidth dw ? ;width of character bitmap in pixels
geOffset dd ? ;pointer to the bits
geAspace dd ? ;A space in fractional pixels (16.16)
geBspace dd ? ;B space in fractional pixels (16.16)
geCspace dw ? ;C space in fractional pixels (16.16)
GlyphEntry ends
The fractional pixels are expressed as a 32-bit signed number with an implicit binary point between bits 15 and 16. This is referred to as a 16.16 ("sixteen dot sixteen") fixed-point number.
The ABC spacing here is the same as that defined above. However, here there are specific sets for each character.
DFF_1COLOR
DFF_16COLOR
DFF_256COLOR
DFF_RGBCOLOR
GlyphEntry struc
geWidth dw ? ;width of character bitmap in pixels
geOffset dd ? ;pointer to the bits
geHeight dw ? ;height of character bitmap in pixels
geAspace dd ? ;A space in fractional pixels (16.16)
geBspace dd ? ;B space in fractional pixels (16.16)
geCspace dd ? ;C space in fractional pixels (16.16)
GlyphEntry ends
DFF_1COLOR means 8 pixels per byte
DFF_16COLOR means 2 pixels per byte
DFF_256COLOR means 1 pixel per byte
DFF_RGBCOLOR means RGBquads
.FON File Format
.FON files are used by the Windows operating system and are an extension to the Windows 3.1 .FNT files. Each FON file is a NE format DLL file with only a resource section, containing .FNT files as resources.
EXE File Format
All multi-byte values are stored LSB first. One block is 512 bytes, one paragraph is 16 bytes.
| Offset (hex) | Meaning |
|---|---|
| 00-01 | 0x4d, 0x5a. This is the "magic number" of an EXE file. The first byte of the file is 0x4d and the second is 0x5a. |
| 02-03 | The number of bytes in the last block of the program that are actually used. If this value is zero, that means the entire last block is used (i.e. the effective value is 512). |
| 04-05 | Number of blocks in the file that are part of the EXE file. If [02-03] is non-zero, only that much of the last block is used. |
| 06-07 | Number of relocation entries stored after the header. May be zero. |
| 08-09 | Number of paragraphs in the header. The program's data begins just after the header, and this field can be used to calculate the appropriate file offset. The header includes the relocation entries. Note that some OSs and/or programs may fail if the header is not a multiple of 512 bytes. |
| 0A-0B | Number of paragraphs of additional memory that the program will need. This is the equivalent of the BSS size in a Unix program. The program can't be loaded if there isn't at least this much memory available to it. |
| 0C-0D | Maximum number of paragraphs of additional memory. Normally, the OS reserves all the remaining conventional memory for your program, but you can limit it with this field. |
| 0E-0F | Relative value of the stack segment. This value is added to the segment the program was loaded at, and the result is used to initialize the SS register. |
| 10-11 | Initial value of the SP register. |
| 12-13 | Word checksum. If set properly, the 16-bit sum of all words in the file should be zero. Usually, this isn't filled in. |
| 14-15 | Initial value of the IP register. |
| 16-17 | Initial value of the CS register, relative to the segment the program was loaded at. |
| 18-19 | Offset of the first relocation item in the file. |
| 1A-1B | Overlay number. Normally zero, meaning that it's the main program. |
Here is a structure that can be used to represend the EXE header and relocation entries, assuming a 16-bit LSB machine:
struct EXE {
unsigned short signature; /* == 0x5a4D */
unsigned short bytes_in_last_block;
unsigned short blocks_in_file;
unsigned short num_relocs;
unsigned short header_paragraphs;
unsigned short min_extra_paragraphs;
unsigned short max_extra_paragraphs;
unsigned short ss;
unsigned short sp;
unsigned short checksum;
unsigned short ip;
unsigned short cs;
unsigned short reloc_table_offset;
unsigned short overlay_number;
};
struct EXE_RELOC {
unsigned short offset;
unsigned short segment;
};
The offset of the beginning of the EXE data is computed like this:
exe_data_start = exe.header_paragraphs * 16L;
The offset of the byte just after the EXE data (in DJGPP, the size of the stub and the start of the COFF image) is computed like this:
extra_data_start = exe.blocks_in_file * 512L;
if (exe.bytes_in_last_block)
extra_data_start -= (512 - exe.bytes_in_last_block);
Subscribe to:
Posts (Atom)