Collection of Hack-Phreak Scene Programs

home *** CD-ROM | disk | FTP | other *** search

/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / SS0288.ZIP / SS0288_4.TXT < prev next >

Wrap

Text File | 1992-06-01 | 32KB | 784 lines

96H LNAMES--LIST OF NAMES RECORD ================================ Description ----------- The LNAMES record is a list of names that can be referenced by subsequent SEGDEF and GRPDEF records in the object module. The names are ordered by occurrence and referenced by index from subsequent records. More than one LNAMES record may appear. The names themselves are used as segment, class, group, overlay, and selector names. History ------- This record has not changed since the original Intel 8086 OMF specification. Record Format ------------- 1 2 1 <--String Length--> 1 96 Record String Name String Checksum Length Length <-----------repeated-----------> Each name appears in <count, char> format, and a null name is valid. The character set is ASCII. Names can be up to 254 characters long. NOTE: Any LNAMES records in an object module must appear before the records that refer to them. Because it does not refer to any other type of object record, an LNAMES record usually appears near the start of an object module. Examples -------- The following LNAMES record contains the segment and class names specified in all three of the following full-segment definitions: _TEXT SEGMENT byte public 'CODE' _DATA SEGMENT word public 'DATA' _STACK SEGMENT para public 'STACK' The LNAMES record is: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 96 25 00 00 04 43 4F 44 45 04 44 41 54 41 05 53 .%...CODE.DATA.S. 0010 54 41 43 4B 05 5F 44 41 54 41 06 5F 53 54 41 43 TACK._DATA._STAC 0020 4B 05 5F 54 45 58 54 8B K._TEXT. Byte 00H contains 96H, indicating that this is an LNAMES record. Bytes 01-02H contain 0025H, the length of the remainder of the record. Byte 03H contains 00H, a zero-length name. Byte 04H contains 04H, the length of the class name CODE, which is found in bytes 05-08H. Bytes 09-26H contain the class names DATA and STACK and the segment names _DATA, _STACK, and _TEXT, each preceded by 1 byte that gives its length. Byte 27H contains the Checksum field, 8BH. 98H OR 99H SEGDEF--SEGMENT DEFINITION RECORD ============================================ Description ----------- The SEGDEF record describes a logical segment in an object module. It defines the segment's name, length, and alignment, and the way the segment can be combined with other logical segments at bind, link, or load time. Object records that follow a SEGDEF record can refer to it to identify a particular segment. The SEGDEF records are ordered by occurrence, and are referenced by segment indexes (starting from 1) in subsequent records. History ------- Record type 99H is new for LINK386: the Segment Length field is 32 bits rather than 16 bits, there is one newly implemented alignment type (page alignment), the B bit flag of the ACBP byte indicates a segment of 4 GB, and the P bit flag of the ACBP byte is the Use16/Use32 flag. Starting with version 2.4, LINK ignores the Overlay Name Index field. In versions 2.4 and later, command-line parameters to LINK, rather than information contained in object modules, determine the creation of run-time overlays. The length does not include COMDAT records. If selected, their size is added. Record Format ------------- 1 2 <variable> 2 or 4 1 or 2 1 or 2 1 or 2 1 98 Record Segment Segment Segment Class Overlay Checksum or 99 Length Attributes Length Name Name Name Index Index Index Segment Attributes Field ------------------------ The Segment Attributes field is a variable-length field; its layout is: <-3 bits-> <-3 bits-> <-1 bit-> <-1 bit-> <-2 bytes--> <--1 byte--> A C B P Frame Number Offset <conditional> <conditional> The fields have the following meanings: A Alignment A 3-bit field that specifies the alignment required when this program segment is placed within a logical segment. Its values are: 0 Absolute segment. 1 Relocatable, byte aligned. 2 Relocatable, word (2-byte, 16-bit) aligned. 3 Relocatable, paragraph (16-byte) aligned. 4 Relocatable, aligned on 256-byte boundary (a "page" in the original Intel specification). 5 Relocatable, aligned on a double word (4-byte) boundary. This value is used by the PharLap OMF for the same alignment. 6 This value is used by the PharLap OMF for page (4K) alignment. It is not supported by LINK. 7 Not defined. The new values for LINK386 are A=4 and A=5. Double word alignment is expected to be useful as 32-bit memory paths become more prevalent. Page-align is useful for certain hardware-defined items (such as page tables) and error avoidance. If A=0, the conditional Frame Number and Offset fields are present and indicate the starting address of the absolute segment. LINK ignores the Offset field. Conflict: The original Intel specification included additional segment-alignment values not supported by Microsoft; alignment 5 now conflicts with the following LINK386 extensions: 5 "unnamed absolute portion of memory address space" 6 "load-time locatable (LTL), paragraph aligned if not part of any group" C Combination A 3-bit field that describes how the linker can combine the segment with other segments. Under MS-DOS, segments with the same name and class can be combined in two ways: they can be concatenated to form one logical segment, or they can be overlapped. In the latter case, they have either the same starting address or the same ending address, and they describe a common area in memory. Values for the C field are: 0 Private. Do not combine with any other program segment. 1 Reserved by IBM. Not supported by Microsoft. 2 Public. Combine by appending at an offset that meets the alignment requirement. 3 Reserved by IBM. Not supported by Microsoft. 4 As defined by Microsoft, same as C=2 (public). 5 Stack. Combine as for C=2. This combine type forces byte alignment. 6 Common. Combine by overlay using maximum size. 7 As defined by Microsoft, same as C=2 (public). Conflict: The Intel specification lists C=1 as Common, not C=6. B Big Used as the high-order bit of the Segment Length field. If this bit is set, the segment length value must be 0. If the record type is 98H and this bit is set, the segment is exactly 64K long. If the record type is 99H and this bit is set, the segment is exactly 2^32 bytes, or 4 GB, long. NOTE: A problem in the 286 chip makes code unreliable if it is executed between bytes 65,500 and 65,535. LINK warns of this problem if code segments reach that size. P This bit corresponds to the bit field for segment descriptors, known as the B bit for data segments and the D bit for code segments in the Intel documentation. If 0, then the segment is no larger than 64K (if data), and 16-bit addressing and operands are the default (if code). This is a Use16 segment. If nonzero, then the segment may be larger than 64K (if data), and 32-bit addressing and operands are the default (if code). This is a Use32 segment. NOTE: This is the only method for defining Use32 segments in the Microsoft OMF. The PharLap OMF uses an additional byte of bit flags at the end of the SEGDEF record to hold this and other flags (described later in this section). Even if the P bit is 0, the PharLap OMF assumes all segments are Use32. Segment Length Field -------------------- The Segment Length field is a 2- or 4-byte numeric quantity and specifies the number of bytes in this program segment. For record type 98H, the length can be from 0 to 64K; if a segment is exactly 64K, the segment length should be 0, and the B field in the ACBP byte should be 1. For record type 99H, the length can be from 0 to 4 GB; if a segment is exactly 4 GB in size, the segment length should be 0 and the B field in the ACBP byte should be 1. Segment Name Index, Class Name Index, Overlay Name Index Fields --------------------------------------------------------------- The three name indexes (Segment Name Index, Class Name Index, and Overlay Name Index) refer to names that appeared in previous LNAMES record(s). LINK ignores the Overlay Name Index field. The full name of a segment consists of the segment and class names, and segments in different object modules are normally combined according to the A and C values if their full names are identical. These indexes must be nonzero, although the name itself may be null. The Segment Name Index field identifies the segment with a name. The name need not be unique--other segments of the same name will be concatenated onto the first segment with that name. The name may have been assigned by the programmer, or it may have been generated by a compiler. The Class Name Index field identifies the segment with a class name (such as CODE, FAR_DATA, or STACK). The linker places segments with the same class name into a contiguous area of memory in the run-time memory map. The Overlay Name Index field identifies the segment with a run-time overlay. It is ignored by current versions of the linker. PharLap Extensions to This Record --------------------------------- In the PharLap 32-bit OMF, there is an additional optional field that follows the Overlay Name Index field. The reserved bits should always be 0. The format of this field is <------------5 bits----------------> <--1 bit--> <--2 bits--> Reserved U AT where AT is the access type for the segment and has the following possible values 0 Read only 1 Execute only 2 Execute/read 3 Read/write and U is the Use16/Use32 bit for the segment and has the following possible values: 0 Use16 1 Use32 Conflicts: The Microsoft-defined OMF has Use16/Use32 stored as the P bit of the ACBP field. Microsoft's OMF does not specify the access for the segment--it is specified in the .DEF file given to LINK. NOTES LINK imposes a limit of 255 SEGDEF records per object module. Certain name/class combinations are reserved for use by CodeView and have special significance to the linker: name $$TYPES with class name DEBTYP, and $$SYMBOLS with class name DEBSYM. See Appendix 1 for more information. Examples -------- The following examples of Microsoft assembler SEGMENT directives show the resulting values for the A field in the corresponding SEGDEF object record: aseg SEGMENT at 400h ; A = 0 bseg SEGMENT byte public 'CODE' ; A = 1 cseg SEGMENT para stack 'STACK' ; A = 3 The following examples of assembler SEGMENT directives show the resulting values for the C field in the corresponding SEGDEF object record: aseg SEGMENT at 400H ; C = 0 bseg SEGMENT public 'DATA' ; C = 2 cseg SEGMENT stack 'STACK' ; C = 5 dseg SEGMENT common 'COMMON' ; C = 6 In this first example, the segment is byte aligned: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 98 07 00 28 11 00 07 02 01 1E ....(..... Byte 00H contains 98H, indicating that this is a SEGDEF record. Bytes 01-02H contain 0007H, the length of the remainder of the record. Byte 03H contains 28H (00101000B), the ACBP byte. Bits 7-5 (the A field) contain 1 (001B), indicating that this segment is relocatable and byte aligned. Bits 4-2 (the C field) contain 2 (010B), which represents a public combine type. (When this object module is linked, this segment will be concatenated with all other segments with the same name.) Bit 1 (the B field) is 0, indicating that this segment is smaller than 64K. Bit 0 (the P field) is ignored and should be 0, as it is here. Bytes 04-05H contain 0011H, the size of the segment in bytes. Bytes 06-08H index the list of names defined in the module's LNAMES record. Byte 06H (the Segment Name Index field) contains 07H, so the name of this segment is the seventh name in the LNAMES record. Byte 07H (the Class Name Index field) contains 02H, so the segment's class name is the second name in the LNAMES record. Byte 08H (the Overlay Name Index field) contains 1, a reference to the first name in the LNAMES record. (This name is usually null, as MS-DOS ignores it anyway.) Byte 09H contains the Checksum field, 1EH. The second SEGDEF record declares a word-aligned segment. It differs only slightly from the first. 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 98 07 00 48 0F 00 05 03 01 01 .. H...... Bits 7-5 (the A field) of byte 03H (the ACBP byte) contain 2 (010B), indicating that this segment is relocatable and word aligned. Bytes 04-05H contain the size of the segment, 000FH. Byte 06H (the Segment Name Index field) contains 05H, which refers to the fifth name in the previous LNAMES record. Byte 07H (the Class Name Index field) contains 03H, a reference to the third name in the LNAMES record. 9AH GRPDEF--GROUP DEFINITION RECORD =================================== Description ----------- This record causes the program segments identified by SEGDEF records to be collected together (grouped). For OS/2, the segments are combined into a logical segment that is to be addressed through a single selector. For MS-DOS, the segments are combined within the same 64K frame in the run-time memory map. History ------- The special group name "FLAT" was added for LINK386. Record Format ------------- 1 2 1 or 2 1 1 or 2 1 9A Record Group Name FF Segment Checksum Length Index Index Definition <-----repeated-----> Group Name Field ---------------- The Group Name field is specified as an index into a previously defined LNAMES name and must be nonzero. Groups from different object modules are combined if their names are identical. Group Components ---------------- The group's components are segments, specified as indexes into previously defined SEGDEF records. The first byte of each group component is a type field for the remainder of the component. LINK requires a type value of FFH and always assumes that the component contains a segment index value. See the "Notes" section below for other types defined by Intel. The component fields are usually repeated so that all the segments constituting a group can be included in one GRPDEF record. NOTES LINK imposes a limit of 31 GRPDEF records in a single object module and limits the total number of group definitions across all object modules to 31. This record is frequently followed by a THREAD FIXUPP record. The most common group is DGROUP, which is used to group the default data segments (_DATA, CONST, and _BSS). LINK does special handling of the pseudo-group name FLAT for LINK386 only. All address references to this group are made as offsets from the Virtual Zero Address, which is the start of the memory image of the executable. The additional group component types defined by Intel and the fields that follow them are: FE External Index FD Segment Name Index, Class Name Index, Overlay Name Index FB LTL Data field, Maximum Group Length, Group Length FA Frame Number, Offset None of these types is supported by LINK. Examples -------- The example of a GRPDEF record below corresponds to the following assembler directive: tgroup GROUP seg1,seg2,seg3 The GRPDEF record is: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 9A 08 00 06 FF 01 FF 02 FF 03 55 .....U Byte 00H contains 9AH, indicating that this is a GRPDEF record. Bytes 01-02H contain 0008H, the length of the remainder of the record. Byte 03H contains 06H, the Group Name Index field. In this instance, the index number refers to the sixth name in the previous LNAMES record in the object module. That name is the name of the group of segments defined in the remainder of the record. Bytes 04-05H contain the first of three group component descriptor fields. Byte 04H contains the required 0FFH, indicating that the subsequent field is a segment index. Byte 05H contains 01H, a segment index that refers to the first SEGDEF record in the object module. This SEGDEF record declared the first of three segments in the group. Bytes 06-07H represent the second group component descriptor, this one referring to the second SEGDEF record in the object module. Similarly, bytes 08-09H are a group component descriptor field that references the third SEGDEF record. Byte 0AH contains the Checksum field, 55H. 9CH OR 9DH FIXUPP--FIXUP RECORD =============================== Description ----------- The FIXUPP record contains information that allows the linker to resolve (fix up) and eventually relocate references between object modules. FIXUPP records describe the LOCATION of each address value to be fixed up, the TARGET address to which the fixup refers, and the FRAME relative to which the address computation is performed. History ------- Record type 9DH is new for LINK386; it has a Target Displacement field of 32 bits rather than 16 bits, and the Location field of the Locat word has been extended to 4 bits (using the previously unused higher order S bit) to allow new LOCATION values of 9, 11, and 13. Record Format ------------- 1 2 <------from Record Length-----> 1 9C Record THREAD subrecord or Checksum or 9D Length FIXUP subrecord <--------repeated-------------> Each subrecord in a FIXUPP object record either defines a thread for subsequent use, or refers to a data location in the nearest previous LEDATA or LIDATA record. The high-order bit of the subrecord determines the subrecord type: if the high-order bit is 0, the subrecord is a THREAD subrecord; if the high-order bit is 1, the subrecord is a FIXUP subrecord. Subrecords of different types can be mixed within one object record. Information that determines how to resolve a reference can be specified explicitly in a FIXUP subrecord, or it can be specified within a FIXUP subrecord by a reference to a previous THREAD subrecord. A THREAD subrecord describes only the method to be used by the linker to refer to a particular target or frame. Because the same THREAD subrecord can be referenced in several subsequent FIXUP subrecords, a FIXUPP object record that uses THREAD subrecords may be smaller than one in which THREAD subrecords are not used. THREAD subrecords can be referenced in the same object record in which they appear and also in subsequent FIXUPP object records. THREAD Subrecord ---------------- There are four FRAME threads and four TARGET threads; not all need be defined, and they can be redefined by later THREAD subrecords in the same or later FIXUPP object records. The FRAME threads are used to specify the Frame Datum field in a later FIXUP subrecord; the TARGET threads are used to specify the Target Datum field in a later FIXUP subrecord. A THREAD subrecord does not require that a previous LEDATA or LIDATA record occur. The layout of the THREAD subrecord is as follows: <--------------1 byte--------------------> <---1 or 2 bytes---> 0 D 0 Method Thred Index 1 1 1 3 2 (bits) <---conditional----> where: 0 The high-order bit is 0 to indicate that this is a THREAD subrecord. D Is 0 for a TARGET thread, 1 for a FRAME thread. Method Is a 3-bit field. For TARGET threads, only the lower two bits of the field are used; the high-order bit of the method is derived from the P bit in the Fix Data field of FIXUP subrecords that refer to this thread. (The full list of methods is given here for completeness.) This field determines the kind of index required to specify the Target Datum field. T0 Specified by a SEGDEF index. T1 Specified by a GRPDEF index. T2 Specified by a EXTDEF index. T3 Specified by an explicit frame number (not supported by LINK). T4 Specified by a SEGDEF index only; the displacement in the FIXUP subrecord is assumed to be 0. T5 Specified by a GRPDEF index only; the displacement in the FIXUP subrecord is assumed to be 0. T6 Specified by a EXTDEF index only; the displacement in the FIXUP subrecord is assumed to be 0. The index type specified by the TARGET thread method is encoded in the Index field. For FRAME threads, the Method field determines the Frame Datum field of subsequent FIXUP subrecords that refer to this thread. Values for the Method field are: F0 The FRAME is specified by a SEGDEF index. F1 The FRAME is specified by a GRPDEF index. F2 The FRAME is specified by a EXTDEF index. LINK determines the FRAME from the external name's corresponding PUBDEF record in another object module, which specifies either a logical segment or a group. F3 Invalid. (The FRAME is identified by an explicit frame number; this is not supported by LINK.) F4 The FRAME is determined by the segment index of the previous LEDATA or LIDATA record (that is, the segment in which the location is defined). F5 The FRAME is determined by the TARGET's segment, group, or external index. F6 Invalid. NOTE: The Index field is present for FRAME methods F0, F1, and F2 only. Thred A 2-bit field that determines the thread number (0 through 3, for the four threads of each kind). Index A conditional field that contains an index value that refers to a previous SEGDEF, GRPDEF, or EXTDEF record. The field is present only if the thread method is 0, 1, or 2. (If method 3 were supported by LINK, the Index field would contain an explicit frame number.) FIXUP Subrecord --------------- A FIXUP subrecord gives the how/what/why/where/who information required to resolve or relocate a reference when program segments are combined or placed within logical segments. It applies to the nearest previous LEDATA or LIDATA record, which must be defined before the FIXUP subrecord. The FIXUP subrecord is as follows 2 1 1 or 2 1 or 2 2 or 4 Locat Fix Frame Target Target Data Datum Datum Displacement <conditional> <conditional> <conditional> where the Locat field has an unusual format. Contrary to the usual byte order in Intel data structures, the most significant bits of the Locat field are found in the low-order, rather than the high-order, byte <-----low-order byte----><----high-order byte---> 1 M Location Data Record Offset 1 1 4 10 (bits) where: 1 The high-order bit of the low-order byte is set to indicate a FIXUP subrecord. M Is the mode; M=1 for segment-relative fixups, and M=0 for self-relative fixups. Location Is a 4-bit field that determines what type of LOCATION is to be fixed up: 0 Low-order byte (8-bit displacement or low byte of 16-bit offset). 1 16-bit offset. 2 16-bit base--logical segment base (selector). 3 32-bit Long pointer (16-bit base:16-bit offset). 4 High-order byte (high byte of 16-bit offset). LINK does not support this type. 5 16-bit loader-resolved offset, treated as Location=1 by the linker. Conflict: The PharLap OMF uses Location=5 to indicate a 32-bit offset, whereas Microsoft uses Location=9. 6 Not defined, reserved. Conflict: The PharLap OMF uses Location=6 to indicate a 48-bit pointer (16-bit base:32-bit offset), whereas Microsoft uses Location=11. 7 Not defined, reserved. 9 32-bit offset. 11 48-bit pointer (16-bit base:32-bit offset). 13 32-bit loader-resolved offset, treated as Location=9 by the linker. Data Indicates the position of the LOCATION to be fixed up Record in the LEDATA or LIDATA record immediately preceding Offset the FIXUPP record. This offset indicates either a byte in the Data Bytes field of an LEDATA record or a data byte in the Content field of a Data Block field in an LIDATA record. The Fix Data bit layout is F Frame T P Targt 1 3 1 1 2 (bits) and is interpreted as follows: F If F=1, the FRAME is given by a FRAME thread whose number is in the Frame field (modulo 4). There is no Frame Datum field in the subrecord. If F=0, the FRAME method (in the range F0 to F5) is explicitly defined in this FIXUP subrecord. The method is stored in the Frame field. Frame A 3-bit numeric field, interpreted according to the F bit. The Frame Datum field is present and is an index field for FRAME methods F0, F1, and F2 only. T If T=1, the TARGET is defined by a TARGET thread whose thread number is given in the 2-bit Targt field. The Targt field contains a number between 0 and 3 that refers to a previous THREAD subrecord containing the TARGET method. The P bit, combined with the two low- order bits of the Method field in the THREAD subrecord, determines the TARGET method. If T=0, the TARGET is specified explicitly in this FIXUP subrecord. In this case, the P bit and the Targt field can be considered a 3-bit field analogous to the Frame field. P Determines whether the Target Displacement field is present. If P=1, there is no Target Displacement field. If P=0, the Target Displacement field is present. It is a 4-byte field if the record type is 9DH; it is a 2-byte field otherwise. Targt A 2-bit numeric field, which gives the lower two bits of the TARGET method (if T=0) or gives the TARGET thread number (if T=1). Frame Datum, Target Datum, and Target Displacement Fields --------------------------------------------------------- The Frame Datum field is an index field that refers to a previous SEGDEF, GRPDEF, or EXTDEF record, depending on the FRAME method. Similarly, the Target Datum field contains a segment index, a group index, or an external name index, depending on the TARGET method. The Target Displacement field, a 16-bit or 32-bit field, is present only if the P bit in the Fix Data field is set to 0, in which case the Target Displacement field contains the offset used in methods 0, 1, and 2 of specifying a TARGET. NOTES FIXUPP records are used to fix references in the immediately preceding LEDATA, LIDATA, or COMDAT record. The Frame field is the translator's way of telling the linker the contents of the segment register used for the reference; the TARGET is the item being referenced whose address was not completely resolved by the translator. In protected mode, the only legal segment register values are selectors; every segment and group of segments is mapped through some selector and addressed by an offset within the underlying memory defined by that selector. Examples -------- Due to the incredible length of the FIXUPP examples in "The MS-DOS Encyclopedia," they are not repeated here. However, the examples are highly recommended if you want to understand what is happening.