Armored Autohotkey executable builder ~ 0.9.5b

USAGE	SCRIPT / CONFIG

HotkeyCamo is a graphical interface application by default, however by modifying its default subsystem to console with a pe editor it will act as a basic cmd shell application by printing its log to stdout.

Regardless of its subsystem the ways to control and configure HkC remain subsystem independant.

Command line	HkC.exe [? or Input_Path] [~ss] [~nb] [~ns] [~np]
?	If a question mark character exists anywhere in argument 1 HkC will load/display a help file/screen depending on its subsystem.
Input_Path	Can be one of the following:: An AutoHotkey script which does not contain HotkeyCamo configuration and build info. An AutoHotkey script which does contain HkC configuration and build info embedded in multi-line comment tags. A file that contains configuration / build info with a valid HKC_IN option entry.
~ss	Runtime subsystem switch, (which is not the same as changing the programs default system with a PE/Hex editor) Causes HkC to use the code written for the opposite of its actual subsystem. If HkC's default subsystem is - Windows A classic 'press any key' console window is created for the log. Its output will not go to an existing cmd shell when executed from one because of the way windoze handles the subsystem. If HkC's default subsystem is - Console HkC will display the gui, allowing command shell users access to the ui if they ever feel the need. The only drawback of this is that two windows will appear or when executed through an existing shell it will be frozen until the interface/HkC closes.
~nb	Perform all chosen operations except the final build phase, useful if you have a separate program/script that you want to use in conjunction with the modified build files inside or outside of HkC. This switch is intended to be used with the hkc_tmp option to prevent deletion of the temp files. Warning the modified build files are deleted by default for a reason, don't blame me if you use them outside of HkC and they do not operate 100% as the originals do in some areas, the temps are crafted to work using the build conditions specified when they were generated only.
~ns	Disable the crc checksums for detecting the version of the build files. (Autodetect cannot be used with this enabled) The only reason why you might wish to disable the crc checks is if you have already made modifications to either Ahk2Exe or AutoHotkeySC before using HkC with these files. such modifications would cause the checks to fail and HkC would abort the build. If this is the case then you must specify the actual version of your build files with the hkc_ver option (or in the gui) and add the ~ns commandline switch at runtime. (you can now also disable crc checks from the gui) This would force HkC to use the specified version offset map and skip the two checks it makes to try and prevent the large margin for error that would result when patching the build files with incorrect offsets.
~np	Disable the 'protective' elements of the fuzzing procedure so an exe after being built can be restored with a decompiler. Use of this switch modifies the gui and the behaviour of the hkc_rnd option slightly.
Exit Codes	0 : HkC completed its task. -1 : Could not find input file or one was not specified. -2 : Unsupported Ahk version value was used or autodetect failed. -3 : Could not find upx.exe or upx serious error when unpacking Ahk2Exe. -4 : HkC could not create the temporary interpreter AutoHotFuzzy.bin. -5 : Both temp build files could not be opened for write access. -6 : HkC failed to set the interpreters subsystem to console. -7 : An error occurred when attempting to build final executable. -8 : Error locating the specified alternate build files. -9 : An error occurred when updating resources. -10: Pre build execution error. -11: One or both build files failed the crc sumprint checks.

SCRIPT / CONFIG

Like most builders of its type HotkeyCamo can store its configuration and build related settings within the script itself by wrapping the entire cfg section in multi-line comment tags /* ... */ or settings can be stored in a separate config file.

Example:: MyScript.ahk

/*
; Within a script using multi-line comment tags.
HKC_OUT = MyProgram.exe
    HKC_ICO = Main.ico
    HKC_VER = AUTO
[]
  */
    MsgBox, 64, Your, Script starts here
    ; ...etc

Example:: MyConfig.cfg

  ; As a separate config file.
    HKC_IN = MyScript.ahk
    HKC_OUT = MyProgram.exe
    HKC_ICO = Main.ico
    HKC_VER = 0
  ; ...etc

Apart from the obvious the only real difference between HkC options in a script and in a config file is that you must specify a path to the script through the hkc_in option from a config.

The default working directory and the directory path used by HkC when relative paths are given or no path is given where one might be expected will always be the directory that contains the script and not the config file.

So if in the above example the path to your config is x:\myapp\MyConfig.cfg
And the value of the input path within the config is: hkc_IN = source\MyScript.ahk
Then the working and default relative directory path used will be x:\myapp\source\

Here is an example of a potential config file to explain the general structure, which is easily recognisable as the ini format.

<-- At the top Primary 'HKC_' options are defined without a section header name. They do not have to exist if not required and can be in any order.

; Mockup
HKC_IN = %userprofile%\My Documents\MyScript.ahk
HKC_OUT = %userprofile%\Desktop\MyProgram.exe
HKC_ICO = @SD>Main.ico
HKC_A2E = @CDP>Compiler2\Ahk2Exe.exe
HKC_BIN = @CDP>Compiler2\AutoHotkeySC.bin
HKC_VER = A.U.T.O
HKC_RND = 1Two3Four5Six
HKC_ALT = 0
HKC_TMP = 0
HKC_PAK = 1
HKC_DBG = 0
HKC_SUB = 1
HKC_EAR = 0

<-- Next we have the optional extra sections for resource - execution and versioninfo control, these also can be in any order and do not have to exist if not required

[HKC_RES]
MyRCD = 10 ` 1 ` 2057 ` @SD>Mydata.dat
[HKC_PBE]
MyBuild script = @AHK> ` @CDP>Compiler2\Extra.ahk @BIN> ` @CD> ` 0
[HKC_VER]
FileVersion = 1,0,0,0

The colors although not really important are there to indicate the types of values that are expected for each field.

Yellow - A string, can contain anything but most expect a path / file / mix, in which you can use macro's and environment variables to assist.

Yellow & Red - Can be a string or a number or both. See hkc_ver and hkc_rnd for more information.

Red - A number is always expected.

Green - Options and extra sections.

Grey - Element delimiter characters.

In the optional res pbe and ver sections each element / entry that follows the section header that is not a comment line (;) defines an action or item related to the header name.

when embedding HkC configuration data in other types of files such as an ahk script or a quicklaunch style config, I highly recommend that if there is any text after the last element of the config block, you place empty square brackets "[]" on the line after the config to prevent the parser mistaking additional text (script) as a possible config entry.

Example:: MyScript.ahk

/*
HKC_OUT = %userprofile%\Desktop\MyProgram.exe
HKC_ICO = @SD>Main.ico
HKC_A2E = @CDP>Compiler2\Ahk2Exe.exe
HKC_BIN = @CDP>Compiler2\AutoHotkeySC.bin
HKC_VER = A.U.T.O
HKC_RND = 1Two3Four5Six
HKC_ALT = 0
HKC_TMP = 0
HKC_PAK = 1
HKC_DBG = 0
HKC_SUB = 1
HKC_EAR = 0
[HKC_RES]
MyRCD = 10 ` 1 ` 2057 ` @SD>Mydata.dat
[HKC_PBE]
MyBuild script = @AHK> ` @CDP>Compiler2\Extra.ahk @BIN> ` @CD> ` 0
[HKC_VER]
FileVersion = 1,0,0,0
[]<- Otherwise further instances of 'content = content' would be parsed.
*/
MsgBox, 64, Your, Script starts here
MyVar = ; ...etc

HkC will add this empty section terminator to configs that are saved to the clipboard through its gui, its only an issue if you are writing a config from scratch or forget why its there and delete it.