MexScript is a multi-paradigm computer scripting language used in a number of game resource archive file handlers. It was originally created for the 16-bit command-line tool multiex, and later 32-bit versions of MultiEx Commander. It is a script that enables the end user to have the interpreting program perform a number of tasks needed to access file contents, as well as to replace file contents. The MexScript has since become one of the standards to process game archives, as is indicated by the implementation of the script (also referred to as multiex, MexCom3, BMS) in similar programs, such as Dragon UNpack, Game Extractor, FusePAK, and the more recent dialect QuickBMS.
History.
MexScript was created in 1997 for multiex by Mike Zuurman and fed to the tool using .INI files. The script was improved upon in later releases of MultiEx Commander. The name stems from the abbreviation of multiex to 'mex', though it is also referred to as Binary MultiEx Script (BMS) which in essence is a compiled version of MexScript. MexScript is interpreted by a Dynamic-link library called "multiex.dll" for the Windows version of MultiEx Commander, and a public version was released on the 24th of July 2003.
Implementations.
Besides MultiEx Commander, the MexScript has been implemented in a number of other applications. The multiex Dynamic-link library was used after initial release in a similar game archive file handler called Dragon UNpack. The scripting language itself has been implemented in the linux tool Fusepak and the Java application Game Extractor. 
A script exists to convert MexScript into Python for OpenMEX.
There is also a dialect of MexScript/BMS called QuickBMS, that first appeared on the Xentax Foundation's Game Research Forum on April 16, 2009.
Design.
MexScript is a domain specific, structured functional scripting language designed for the end-user. The primary domain is the processes required to handle game resource archive formats (GRAF). GRAF is a term first coined in November 2003. The purpose of writing in the MexScript scripting language is to manipulate the contents of GRAs in order to MOD a computer game.
Script.
Extensive descriptions of MexScript are found on the web sites of various implementations, most notably MultiEx Commander and QuickBMS.
The last release of the 16-bit implementation in 1998 of MultiEx Commander featured statements and commands as follows:
ID, EVENTS, NOFILENAMES, GetLong, FlipLong, GetInt, GetString, WriteLong, GetDString, GetNullString, StrCReplace, StrEReplace, LOOP, ENDLOOP, SavePos, GoTo, SET, SETFILECNT, ADD, SUBST, SETBYTESREAD, MULTIPLY, UP, DOWN, PROMPTUSER, ExtractFILE, SETPATH, FindFileID, Case, SeparateHeader.
Later dialects as implemented by MultiEx Commander or QuickBMS offer more functionality.
Data.
Depending on the dialect or original implementation, the data types can differ substantially. MexScript for MultiEx Commander has the following:
Scoping.
Variables do not have to be declared before use; their scope is then global, except when a variable that has not been used before is involved in some kind of calculation. In such a case it is declared using a SET ;variable ; statement. All variables can be changed at run-time, allowing for self-modifying code.
Output.
The scripting language typically outputs a list of files contained in a game resource archive, along with the offsets and sizes, along with information on their name and putative compression. This is done in 32-bit MultiEx Commander and other implementations using the Log statement, or CLog statement.
Control structure commands.
MexScript provides several common control structures.
Recursion is MexScript's preferred processing paradigm.
I/O.
Output of the original multiex.exe was either extraction or importation of files contained in archives. The 32-bit implementation would output a list of files contained in the processed archive, along with information on their position, size, name and compression type. This list would then be fed to MultiEx Commander, or similar tools.
Syntax.
In the original 16-bit version, commands were to be written on one line, but later versions allowed more. Anything in a line following the hash symbol codice_1 is ignored, allowing the coder to insert comments. The QuickBMS dialect also supports C-style (codice_2) and C++-style (codice_3) comments. Each line ends with a semicolon codice_4, though it is not obligatory in many dialects. 
References.
 ;templatestyles src="Reflist/styles.css" / ;