(*******************************************************************
[76576,470]
EXECHK.ZIP/binary 6-Dec-90 xxxx Accesses: xx

Title : Copy discouragement
Keywords: APPLICATION COPY EXE FILE ILLEGAL PROTECT SOFTWARE SOURCE STAMP

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.
*******************************************************************)

(*******************************************************************
PURPOSE
-------
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.)

DIRECTIONS FOR USE
------------------
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.

WARNING!
--------
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.

NOTES
-----
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 "mydata.inc"; 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:

VAR
MyDataStruc : string ;
begin
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.

PROGRAM LOGIC - The First "INSTALL"
-----------------------------------
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:

PROGRAM LOGIC - Subsequent "INSTALLS"
-------------------------------------
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.
*******************************************************************)