Dec 232017
TP 4.0+ source code that illustrates a method of "stamping" your original application EXE file with the user's name, address, serial #, etc.
File EXECHK.ZIP from The Programmer’s Corner in
Category Pascal Source Code
TP 4.0+ source code that illustrates a method of “stamping” your original application EXE file with the user’s name, address, serial #, etc.
File Name File Size Zip Size Zip Type
ABORT.INC 1510 424 deflated
EXECHK.DEF 1371 450 deflated
EXECHK.DOC 3832 1673 deflated
EXECHK.INC 5110 1047 deflated
EXECHK.PAS 2206 824 deflated
MYDATA.INC 3674 923 deflated
MYINSTAL.PAS 2565 934 deflated
MYPROG.PAS 2230 823 deflated

Download File EXECHK.ZIP Here

Contents of the EXECHK.DOC file

EXECHK.ZIP/binary 6-Dec-90 xxxx Accesses: xx

Title : Copy discouragement

Source code illustrates a method of "stamping" your original
application EXE file with the user's name, address, serial #,
etc., in order to discourage illegal copying of your software.
This method works with files compressed using LZEXE and will
compile under any version of TP. Includes sample application
and installation programs.

To discourage illegal copying of software, by "stamping" the user's
Name, Serial#, etc. onto the EXE file itself. (Actually it is appended
to the end of the EXE file.)

After compiling both files (MYPROG.PAS and MYINSTAL.PAS), try to
run them. MYPROG.EXE will not run until it has been modified by
MYINSTAL.EXE, and the MYINSTAL.EXE will only run from the A: drive.

Copy both EXE files to a diskette in A: drive, then run "a:myinstal".
You will be prompted for your name, company, city/state and software
serial number, which will be written to the MYPROG.EXE file on the
A: drive. Now the MYPROG.EXE will run (from any drive), displaying
the user/licensee data on startup.

You must reset the "FileMode" variable to ReadWrite, as the EXECHK
routine sets the "FileMode" variable to ReadOnly under DOS 2.x and
to Read_DenyNone under DOS 3.x. If you encounter a failure in your
programs when writing to a file, then this is most likely the cause.

This is done for you in the demo programs.

Checks the EXE file header (see the "exechk.def" file) and compares
it to the actual "FileSize", during program initialization.
Will work correctly even if the EXE file has been LZEXE'd.

The "ExeInstallData" and "ExeReadData" routines are not specific
to the data types used in ""; they use a VAR parameter so
you can create your own. You do have to specify the size of the
variables which you're using, however.

If you had just a one line "stamp" string, you would call either
routine like this:

MyDataStruc : string ;
Exe....Data ( MyFileName , MyDataStruc , SizeOf ( MyDataStruc ) ) ;
end .

Since the user-specific information is only appended the the EXE file,
it could, of course, be altered by a savvy user through Norton Utils,
PC-Tools, etc. If this is a concern, you could add an encryption routine
and cross-check the data structure, without having to rework the
main routines.

If "IsExePersonalized" returns FALSE, get the user information
("MyDataInput") and call the "ExeInstallData" routine to append
the information to the original EXE file, presumably on drive A:

Since the user may have to re-install the program (due to disk problems,
purchase of a new machine, inadvertant format/erasure, etc.), if
the "IsExePersonalized" returns TRUE, then skip the "MyDataInput"
and go directly to your main installation.

PROGRAM LOGIC - The actual application software
If function "IsExePersonalized" returns FALSE, then the program should
HALT, because it has not yet been "stamped". Of course, it would be
polite to inform the user that he must have the original disk and
should install it properly.

 December 23, 2017  Add comments

Leave a Reply