vbdpss.hlp (Table of Contents; Topic list)
Important Notice
The pages on this site contain documentation for very old MS-DOS software, purely for historical purposes. If you're looking for up-to-date documentation, particularly for programming, you should not rely on the information found here, as it will be woefully out of date.
Article Q84062
                                                 Contents  Index  Back
─────────────────────────────────────────────────────────────────────────────
                           Knowledge Base Contents  Knowledge Base Index
 
 VB for MS-DOS: How to Append Data to the End of an .EXE File - Q84062
 
 Appending data to the end of an executable file may be useful when you
 need to include data with your program but do not want to have extra
 data files. The method shown below in this article involves reading the
 executable file header to determine the program image (the actual size
 of the executable part of the file) at run time to determine the
 position of the data at the end of the executable file. Once the
 position of the data has been determined, the executable file can OPEN
 itself for BINARY access and read the data.
 
 Although this method has been tested in limited use with Microsoft
 Basic products, it is not officially supported or guaranteed by
 Microsoft, and has not been extensively tested.
 
 More Information:
 
 The first step in this process is to get the executable header
 information. This is documented in the "Microsoft MS-DOS Programmers
 Reference" (published by Microsoft Press). The following is the format
 of an executable header as defined by a Visual Basic program:
 
 TYPE EXEHEADER
     exSignature AS INTEGER
     exExtraBytes AS INTEGER ' Number of bytes in last page.
     exPages AS INTEGER      ' Number of whole and part pages.
     exRelocItems AS INTEGER
     exHeaderSize AS INTEGER
     exMinAlloc AS INTEGER
     exMaxAlloc AS INTEGER
     exInitSS AS INTEGER
     exInitSP AS INTEGER
     exCheckSum AS INTEGER
     exInitIP AS INTEGER
     exInitCS AS INTEGER
     exRelocTable AS INTEGER
     exOverlay AS INTEGER
 END TYPE
 
 The two fields exExtraBytes and exPages can be used to compute the
 size of the image area of the executable, and thus the beginning of
 the data area.
 
 The following is a small program that will create a data file
 containing a graphics image created with the PRINT and LINE statements
 in Basic:
 
    See Example
 
 The next example should be compiled and have the data file from the
 previous program appended on the end of the executable. Type in the
 following program and save it as "TEST.BAS":
 
    See Example
 
 After compiling this program, use the MS-DOS TYPE command to append
 the data file to the end of the executable as follows:
 
    type datafile >> test.exe
 
 Run the program and you will see the image that was created in the
 first program displayed in the second program.
 
 How Basic's Graphics GET Statement Stores Graphics in an Array:
 --------------------------------------------------------------
 
 (This internal product information is provided as is, and may be
 subject to change or nondisclosure in future versions of BASIC.)
 
 The graphics GET statement transfers a screen image into a specified
 array. The first 4 bytes in the array are two integers which specify
 how wide and long the stored image is in pixels, while the rest of the
 data stored in the array is a binary representation of the stored
 screen image, as shown in the following diagram:
 
    +------------+------------+
    | image width, in pixels  |  <-- 2-byte integer number
    +------------+------------+
    | image length, in pixels |  <-- 2-byte integer number
    +--------+--------+--------+--------+--------+--------+
    |        |        |   < binary image data >  |        |
    +--------+--------+--------+--------+--------+--------+
     byte #5   byte #6  byte #7
 
 The binary image data depends on the screen mode of the graphic image
 and is stored linearly in memory by pixel rows and columns. The GET
 statement scans the screen image by row from left to right and stores
 the bit representation of each pixel. Each row of the stored data will
 be padded out to an even byte boundary by NULL bytes (ASCII 0). For
 example:
 
    Take a square box drawn on the screen and stored with the following
    program:
 
       ' To try this example in VBDOS.EXE:
       ' 1. From the File menu, choose New Project.
       ' 2. Copy the code example to the Code window.
       ' 3. Press F5 to run the program.
       SCREEN 2
       DIM box%(1 to 5)
       LINE (1, 1)-(10, 3), ,B
       GET (1, 1)-(10, 3), box%
 
    The first 4 bytes of box% will be as follows:
 
       box%(1) = 10  ' The box is 10 pixels wide.
       box%(2) = 3   ' The box is 3 pixels long.
 
    The binary representation of the remaining bytes in the box% array
    is as follows:
 
       box%(3) = 11111111 11000000  <- Note padding of each row of bits.
       box%(4) = 10000000 01000000  <- Also note how the 1's form a box.
       box%(5) = 11111111 11000000
 
 How GET Stores Color on an IBM PC or Compatible
 -----------------------------------------------
 
 On an IBM PC or compatible, the way the graphics GET statement stores
 color information depends upon the characteristics of the display
 mode. For screen modes with a single color plane (SCREENs 1, 2, 3,
 11, and 13), each pixel is represented by the number of bits per pixel
 per plane for the particular display mode. For example:
 
    If the square box given above were drawn in SCREEN mode 1 (2 bits
    per pixel per plane) with the following program:
 
       ' To try this example in VBDOS.EXE:
       ' 1. From the File menu, choose New Project.
       ' 2. Copy the code example to the Code window.
       ' 3. Press F5 to run the program.
       SCREEN 1
       DIM box%(1 to 7)
       LINE (1, 1)-(10, 3), ,B
       GET (1, 1)-(10, 3), box%
 
    Then the binary representation of the image data bytes (after the
    4-byte width and length header) would be as follows:
 
       11111111 11111111 11110000
       11000000 00000000 00110000   <- Notice 2 bits per pixel.
       11111111 11111111 11110000
 
    Since no color was specified, the default color (white) was used
    (thus all of the color bits were turned on).
 
 For SCREEN modes with multiple color pages (SCREENs 7, 8, 9, 10, and
 12), the GET statement stores each display page separately by screen
 row. The GET statement stores the binary information for one row of
 the graphics on the first color page, and then the same row of
 graphics on the next color page, padding each row of color page
 information to an even byte boundary. For example:
 
    If the same square box were drawn in SCREEN mode 12 (four color
    planes) in red with the following program:
 
       ' To try this example in VBDOS.EXE:
       ' 1. From the File menu, choose New Project.
       ' 2. Copy the code example to the Code window.
       ' 3. Press F5 to run the program.
       SCREEN 12
       COLOR 4   ' Select red color.
       DIM box%(1 to 14)
       LINE (1, 1)-(10, 3), ,B
       GET (1, 1)-(10, 3), box%
 
    Then the binary representation of the image data bytes (again after
    the 4-byte header) would be as follows:
 
       00000000 00000000 <- blue plane
       00000000 00000000 <- green plane
       11111111 11000000 <- red plane (note padding to byte boundary)
       00000000 00000000 <- intensity plane - first row finished
 
       00000000 00000000 <- blue
       00000000 00000000 <- green
       10000000 01000000 <- red
       00000000 00000000 < - intensity - second row
 
       00000000 00000000
       00000000 00000000
       11111111 11000000
       00000000 00000000 <- last row