Path: utzoo!news-server.csri.toronto.edu!rutgers!njin!njitgw!mars.njit.edu!cd5340
From: cd5340@mars.njit.edu (David Charlap)
Newsgroups: comp.lang.pascal
Subject: Re: Bitmaps in exe files
Message-ID: <2605@njitgw.njit.edu>
Date: 11 Mar 91 21:44:38 GMT
References: <26239@adm.brl.mil>
Sender: news@njitgw.njit.edu
Organization: New Jersey Institute of Technology
Lines: 30

In article <26239@adm.brl.mil> DAVID@ches.cs.vims.edu writes:
>Hope this helps - I've managed to use this technique without
>problems. If you need to update your data you have to go through
>the whole routine with BINOBJ and then re-compile the program.
>Something I've been looking at is incorporating a (hopefully)
>unique tag in the file so I can scan the executable EXE file for
>it, locate where the stuff is stored in the EXE file and replace
>it *in situ* without having to recompile.

To do this, (assuming Borland is making full use of DOS's EXE header
facilities), you should be able to locate the data segment(s) of a
program by reading the .EXE header.  From there, if you know the
contents of the old data, you should be able to find it quickly.  Of
course, I wouldn't want to change it to anything of a different
length from the original, or bad things could happen.  Also, you must
beware of compressed EXE files.  Many programs today will LZW compress
an executable file, placing the decompress code in the EXE header.
This will completely ruin any chance of finding (let alone changing)
your data without recompiling.

Personally, if you're going to be changing the data, why do you want
to compile it into the code?  Leave it in a data file somewhere.  The
time to load it won't be very much longer, and your life will be much
easier.  I've only linked BINOBJ data when the data is static.  As in
color title screens, or separately compiled object modules (like BGI
drivers).
--
David Charlap                   "Invention is the mother of necessity"
cd5340@mars.njit.edu            "Necessity is a mother"
Operators are standing by	"mother!" - Daffy Duck