Encrypted Files

Example:

procedure RunButton;
begin
  writeln('This is a proprietary routine');
end;

Suppose the above script is proprietary, and needs to be distributed as an encrypted file.   On the Script Editor, click the menu Script | Save As and enter the filename to use.   To save the file in an encrypted format, you must provide an extension of  .LIB   by typing the filename with the .LIB extension.   All encrypted files will have an .LIB extension and be saved in the C:\Ensign\Macro folder.

To use the encrypted file in a script, it must be referenced with the {$Include filename} compiler directive, as illustrated in this example, assuming we have an encrypted file named   TEST.LIB.

{$I Test.lib}
begin
  if who=0 then RunButton;
end;

This little script can use all the code in the TEST.LIB file, which in our simple example contains the RunButton procedure.   There is no harm nor any value in the user seeing this portion which calls the encrypted TEST library file.   But what the user cannot see nor can they edit is the TEST library file because it is encrypted.   To see and edit the contents of Test, one would need to have the original TEST.SPT file which was encrypted to create the TEST.LIB file.

So, how does this differ from the previous use of the {$I ....} directive.   The difference is in the presence or absence of the .LIB extension in the filename on the $I directive.

{$I Test}        This will include a filename  TEST.SPT  which is not encrypted.   SPT files are ASCII text files saved by the Script Editor.   They can be loaded, edited, and saved by the Script Editor.

{$I Test.lib}    The extension indicates the TEST.LIB file is encrypted and will be treated as such when it is processed by the ESPL engine.  If you try to view an encrypted file, you will see what look like random garbage.  Thus the developers proprietary work is protected.   It cannot be viewed nor edited by end-users.   Only the developer can make changes, by working with the SPT original and resaving to a LIB file.

Developers can put their sensitive code in encrypted files by saving them using filenames with the .LIB extension.   A filename with the .SPT extension will automatically be saved at the same time.   Developers will distribute the LIB file, and keep the SPT file for file maintenance purposes.

The libraries are easy to work with because the editor has a tab on the bottom for each script file found in your \Macro folder.  So, you can be editing in the main script, and click on a tab to quickly change to look at the code in the library, and click the main script tab to return to where you were editing.   Also, the error messages will indicate the library code where a syntax or run-time error occurred.   So, you have everything to gain by breaking your code into chunks and save them in separate script files.   And assemble them back into the main script using the Include directive.

Access to all distributed encrypted files will be through the use of the {$Include ...} compiler directive from a main script that is not encrypted.   This is the correct way to proceed because end-users will want to add purchased libraries to scripts they are developing.  End-users can include the encrypted libraries in the non-encrypted scripts they are editing and running.

Some typical uses of this encryption capability are:

• Hide proprietary formulas, studies, and technical analysis
• Prevent modification and tampering with original work
• Prevent removal of copyright notices, names and addresses
• Hide details of security authorization and prevent security mechanisms from being removed.