ve文件格式.txt

EXE文件结构说明.老而经典的资料.希望对大家有帮助.

------------------------------------
Header
------------------------------------

+00h	"VE"	Identification tag
+02h	0000h	Version
+04h	long	Offset to image
+08h	long	Offset to relocs
+0ch	long	Offset to library list (unused)
+10h	long	Offset to export list (unused)
+14h	long	Length of image
+18h	long	Length of relocs
+1ch	long	Length of library list (unused)
+20h	long	Length of export list (unused)
+24h	long	Uncompressed image length
+28h	long	Uncompressed relocs length
+2ch	long	BSS length
+30h	long	Flags
+34h	long	Entry point
+38h	long	Stack point
+3ch	long	Offset to resources (reserved)
+40h	byte	Image compression
+41h	byte	Relocs compression
+42h	byte	Library list compression (unused)
+43h	byte	Export list compression (unused)

* All offsets are from the start of the VE header.
* All variables are in LSB to MSB order.
* Compression values:
	0	None
	1	LZSS
	2	LZH

--------------------------------------
Relocs
--------------------------------------
00h	End of relocs
01h	32-bit reloc
02h	48-bit (far) reloc
03h	16-bit (segment) reloc
04h/05h	32-bit reloc to external library by name/number (unused)
06h/07h	48-bit reloc to external library by name/number (unused)
08h/09h	16-bit reloc to external library by name/number (unused)

[for 48-bit and 16-bit relocs, a segment of 0 is code and 1 is data]


+00h	byte	Reloc type
	[word]	Library number for reloc types 04h-09h
	[word]	Function name reference ID for reloc types 04h, 06h, 08h
	[word]	Library function for reloc types 05h, 07h, 09h
+01h	word	Number of relocs (zero means 64k relocs)
+03h	long	First reloc
+07h	byte	Reloc differentials (number of relocs - 1)
	00-7fh	Next reloc is <size> to <size>+127 bytes away
	80-ffh	(a) add 128-16384 bytes to the next value [last value]
		(b) << 7
		(c) << 7
		(d) << 7

--------------------------------------
Export list (unused)
--------------------------------------
00h	long	Address of first export
04h	long	Number of exports

	+00h	long	Delta 
	+04h	byte	Length of name; may be zero
	+05h	byte	Name

--------------------------------------
Library list (unused)
--------------------------------------
00h	long	Number of referenced libraries

	+00h	byte	Length of name; may be zero
	+01h	byte	Name

??	long	Number of name references

	+00h	byte	Length of name; may be zero
	+01h	byte	Name

--------------------------------------
Secondary compression: LZSS
--------------------------------------

+00h	long	Number of codes
+01h		Code groups:

	+00h	byte	Bit flags; bit 0 is first code in group
			0: code is a literal byte
			1: code is a reference to earlier data

	For each code in the group:
		If the code is a literal, copy the next byte
		If the code is a reference, the next short indicates the ref:
			bits 0-3 is length-3
			bits 4-15 is start of reference: current-4096+offset

Note: If the reference ends past the current point data should be repeated.
      This is automatic if a forward move is used in a buffer.

--------------------------------------
Secondary compression: LZ-Huffman
--------------------------------------

Distance encoding
-----------------
Offset	   Extra bits
   1	         0
   2		 0
   3		 0
   4		 0
   5-6		 1
   7-8		 1
   9-12		 2
  13-16		 2
  17-24		 3
  25-32		 3
  33-48		 4
  49-64		 4
  65-96		 5
  97-128	 5
 129-192	 6
 193-256	 6
 257-384	 7
 385-512	 7
 513-768	 8
 769-1024	 8
1025-1536	 9
1537-2048	 9
2049-3072	10
3073-4096	10

Length encoding
---------------
Len	Xbits
 3	  0
 4	  0
 5	  0
 6	  0
 7	  0
 8	  0
 9	  0
10	  0
11-12	  1
13-14	  1
15-16	  1
17-18	  1
19-22	  2
23-26	  2
27-30	  2
31-34	  2
35-42	  3
43-50	  3
51-58	  3
59-66	  3
67-82	  4
83	  0

Literal/Distance tree: 256+24 = 280 codes
Length tree:			 22 codes

Format:
1. Bit lengths for L/D bit length tree, packed into nibbles, bits 0-3 before
   bits 4-7 (16 nibbles).
2. Bit lengths for length tree, packed into nibbles the same way (22 nibbles).
3. Literal/distance bit-length tree (280 codes).
4. Encoded data.

Bit packing order:
All values are packed MSB to LSB; this is the reverse of the way the Deflate
method packs Huffman codes.

--------------------------------------
Applying relocs
--------------------------------------
1) Load and depack relocs if necessary.
2) Process blocks sequentially:
  a) 32-bit relocs: add base address to <target> (long).
     48-bit relocs: add base address to <target> (long).
		    place CS in <target+4> if <target+4> is 0 or DS if
		    <target+4> is 1 (target+4 is short).
     16-bit relocs: place CS in <target> if <target> is 0 or DS if <target>
		    is 1.
  b) Set <target> to the base address plus <first reloc>.
  c) All relocs in the same block are ascending in memory by delta offsets.
     The smallest delta offset is 0, which indicates the next immediate
     relocation item for that type of reloc (2 bytes for 16-bit, 4 bytes
     for 32-bit, and 6 bytes for 48-bit).  Thus, for 32-bit relocs, the
     range of deltas possible with one delta byte is 4-131.
  d) If the delta is too large to fit into one byte, the delta is split into
     multiple bytes with 7-bits of the delta in each byte.  The bytes are
     ordered from most significant to least, with all bytes but the last
     having the MSB set.  Thus the string 81828374 is equivalent to the
     delta (0x01<<28) + (0x02<<14) + (0x03<<7) + (0x74), or 0x2081F4.
  e) There is no delta for the first reloc.  A block with two relocs would
     only have one delta.

-------------------------------------
Generating relocs
-------------------------------------
1) Multiple blocks with the same reloc type are permitted but it is
   recommended that this only occur if all relocs of that type cannot fit
   into a single block.  The multiple blocks should not share relocation
   areas (i.e. relocations in one block should not lie within 10000h-20000h
   while another block has relocations from 18000h-28000h), in the interest
   of greater compression.
2) All relocs of a particular type should be sorted in ascending address
   order to minimize the number of extension delta bytes (>80h) required
   as well as maximize compression derived from any secondary compression
   such as LZSS.

-------------------------------------
Loading VE executables
-------------------------------------
0) Save ES; it contains the PSP segment.  The program name can be obtained
   from here if necessary.
1) Load in VE header.  If the VE executable is attached to a preloader
   such as VELoader it is necessary to read the MZ header and then find
   the end of the LE executable to find the VE header.
2) Allocate memory according to the VE header for the image and relocs.
   BSS memory should immediately follow the image and thus both should
   be allocated as a single block.
3) Read in image and decompress.
4) Read in relocs and decompress.
5) Apply relocs to the image.  CS and DS applied to image for 16-bit and
   48-bit relocs should be the same as those supplied to the program at
   execution start.
6) Free relocs memory.
7) Zero BSS memory.
8) Switch stack to offset noted in VE header.  This is necessary since
   the Watcom library requires the stack pointer to be at the end of
   the BSS segment for stack checking.
9) Load ES with the PSP segment as obtained at the start of the loader.
10) Near call the program.
11) INT 21h AX=4C00h if the program happens to return.

-------------------------
ENGLISH MAJOR EXAMINATION
-------------------------

The VE 32-bit Executable Format and the tools LE2VE, VERUN, VELOADER, and
VELOD4GW are Copyright (C) 1995-1997 by Avery Lee.  All Rights Reserved.
The VE 32-bit Executable Format and the toole LE2VE, VERUN, VELOADER, and
VELOD4GW are free software; you may distribute and/or modify them under
the terms of the GNU General Public License.  It should have been included
in the archive(s); if not, write to the Free Software Foundation, Inc.,
675 Mass Ave., Cambridge, MA 02139, USA.

Any trademarks, registered trademarks, etc. not specifically mentioned as
being so are recognized here.  No offense or infringement is intentional.

Any patent and/or copyright violations in this package are certainly
unintentional.