Features that are unavailable in exe
Features that are different in exe
Properties -> Run in separate process
By default, macros run in QM environment, but you also can create standalone programs (exe files) from them. Exe files run much like macros, but don't need QM. It is especially useful if you distribute them. Distributing exe also is better because it does not depend on QM version, whereas macros that run in QM environment may not run on older QM versions.
To make exe from current macro or function, click menu Run -> Make Exe, optionally change default options, and click OK. You can choose where to save everything that you'll change in the Make Exe dialog (QM 2.2.0). If you choose to save in the folder, later these settings will be used when you click menu Run -> Make Exe even if another macro/function belonging to the folder is opened. The name of the folder should be the name of the program (e.g. "X Editor"). The name is used in exe, for example, in error message boxes.
Main - the name of the macro or function that runs first when the program runs. By default it is current macro or function. All functions that it calls are automatically added to exe.
Make - the program file to make. By default it is MainMacroName.exe in My Documents\My QM.
Icon - program's icon. It also will be used in dialogs. Optional. Click Edit to edit it (if you have an icon editor).
Manifest - manifest file. It is optional but should always be used. You can use the default file default.exe.manifest. Manifest enables visual styles (dialogs will look nicer on Windows XP and later). For Windows Vista, manifest specifies whether the exe must run with higher privileges. Read more below.
.res - a res file to add to the exe as resources. Optional. Click Edit to edit it (if you have a resource editor). Read more below.
Auto add image files - automatically add image files to the exe as resources. Read more below.
End hot key - a hot key that can be used to end the program. Only a single program can use the hot key. The hot key will not work if another instance of the program or another program already uses that hot key. For example, Windows Explorer may use it for a shortcut. Don't use hot key with modifiers (Ctrl, Shift, Alt) if the macro uses keyboard/mouse commands, because then user-pressed modifier keys will be mixed with macro-pressed keys/buttons and the result may be dangerous.
Compress (QM 2.2.1) - compress the exe file to reduce its size. Uses upx - the Ultimate Packer for eXecutables. When the exe runs, it decompresses itself, which takes about 5 milliseconds for 200 KB exe on computers with 1,5-2 GHz processor.
Note: Make sure that items containing confidential data are encrypted. Read more about it below.
Automate additional tasks:
Run before - function to call before starting to create exe (when you click OK). QM waits while it is running. The function, for example, could end the program if it is running. To end the program, use this code:
clo win("GUID" "QM_ExeManager"); err ;;GUID is the value of the guid field of exe project settings, eg {831E78A4-8BD0-4217-94C2-37A1CFF290A8}
Run after - function to call after the exe is successfully created. QM waits while it is running. The function, for example, could add the exe file to a zip file. Example
Run on Run - function to run when the program is launched from QM (then QM does not run the program). The function, for example, can run the program with a command line, or activate certain window before.
All these 3 functions receive the full path of the program in the _command variable. For example, to run the program with a command line use this: run _command "command line".
Debug:
Show added items - display in the output all added functions, items that are added as text, ActiveX control classes (read below), and image files (read below).
Run immediately - run the program or the "Run on Run" function automatically when the program is created.
Output to QM - if QM is running, display all output of the program (RT errors, out, etc) in QM. If unchecked, RT errors are shown in a timed message box, and out does nothing.
Go to error - if QM is running, show RT errors of the program in QM (open the function and show the place). This works correctly only if the function is not modified and not renamed since the program was created last time.
Note: the last two options are active even if the exe runs on other computers where QM is installed and running.
These properties also are applied (when creating exe): "allow only single instance" (function) and "don't run/wait/terminate" (macro). Read more below.
To run exe you have created, you can use menu Run -> Run exe, or double click it e.g. in Windows Explorer, or run a macro that runs it, or use whatever way that you can use to run programs. If you click the Run button, the macro runs in QM, as usually. To run exe when you click the Run button, check "Run in separate process" in Properties (QM 2.2.0).
When creating exe, QM compiles the main function and all other used functions, including threads created using mac. Compiled code is added to exe. Source code is not added. In some cases you will have to use #exe to explicitly add some functions, text and ActiveX control info.
Exe cannot be decompiled to see the source code, but it is possible to see strings that were in source code, even if the exe is compressed. Therefore you should encrypt (in Options -> Security) items that contain passwords or other confidential information in strings. Note that compression will not make encrypted data smaller.
External files (e.g. custom dlls) are not added to exe automatically. You can add them together with exe file to a zip file. You can also add files to exe as resources. Read more below. Example.
When creating exe, QM also may create more files. These temporary files are not used by exe, and should not be distributed. Current QM version does not create more files.
Compile time errors ("unknown identifier", etc) will not occur in exe, because exe contains already compiled code. Declarations, type libraries and other references are not used in exe (all required information is added to exe when creating it). However, like any other program, the program will fail if a required dll function or COM component does not exist on the computer. To check whether a dll function exists, you can use version variables and delay-loading. To handle "No such interface supported" errors you can use err.
When a run time error ("window not found", etc) occurs, it is shown in QM or message box (see above), and the program exits.
If you use global variables that are initialized at QM startup, you should add the initialization code to the exe, or these variables in exe will be empty. For example, call the initialization function at the beginning of the main function (you can use #if EXE to skip it when running in QM). This is not needed for global variables that are initialized by constructor. This is not needed for predefined global variables.
If the main function has "Allow only single instance" option checked in Properties, only single instance of the program can run at a time. If it is a macro, macro properties "don't run/wait/terminate" are applied, which also means that only single instance of the program can run at a time. In both cases, limited is only the number of instances of the same program. Don't use "Allow only single instance" if you want to have more control, e.g. relay the command line to already running instance. You can use a mutex instead.
If the program is launched with command line parameters, they are stored into the _command variable and can be accessed in the main function and its thread. The command line also can be accessed using GetCommandLine.
On success, the exit code of the program is the return value of the main function. It should be 0 or positive. On failure, the exit code is: -1 if the main function ended due to a run-time error, -2 if the program didn't start because another instance is already running, -3 if terminated (e.g., hot key, new instance), -4 if could not start (e.g., a dll function not found).
The main function runs not in the primary thread of the exe process. Like in QM, the primary thread is used to manage threads and provide other services. The main function is executed in a separate thread. More threads can be created using mac. The exe process ends when the main function's thread ends. Like in QM, constructors and destructors of global variables run in the primary thread.
You can use shutdown -6 to end a thread in the process, but not in other processes. It also will not end threads running in QM. You can use shutdown -1 to end the exe process from any thread.
To launch exe using a hot key, can be used shortcut on desktop or in start menu (you can assign a hot key in shortcut properties dialog). To avoid possible problems when Ctrl/Shift/Alt are mixed with keys pressed by exe, exe created from macro waits until these keys are released before starting to execute commands. Exe created from function does not, but you can insert this code at the beginning:
rep() if(GetMod) 0.02; else break
If a dll is required for some QM intrinsic function, it is added to exe. For example, zip uses qmzip.dll. When the program runs, dlls are extracted to $temp$ folder if needed.
QM cannot create small exe files. The minimal size currently is about 420 KB. If compressed - about 210 KB.
Programs created using QM run at the same speed as macros and functions in QM. In some cases QM code runs significantly slower than native machine code (e.g. C++ programs). QM does not create native machine code.
QM cannot create dlls and console programs. It should be possible to create services, but currently it is not tested.
Programs created using QM will run on Windows 2000, XP, 2003 and Vista. To create programs for Vista, you should have at least QM 2.2.0, although most programs created with QM 2.1.9 also will work on Vista. Read about Vista-related issues below.
Resources are files and other data added to exe file. Can contain bitmaps (pictures), icons, cursors, dialogs, menus, accelerators, strings, version info, binary data (e.g. files), etc. If you use external files in macros/functions that are added to exe, you should either distribute them together with the exe or add them to exe as resources. For example, if you use scan, you can add bitmap files to resources so that you would not have to distribute them together with the exe file as separate files.
If "Auto add image files" is checked, QM automatically adds image files to exe. QM searches the source code of all macros/functions that are added to exe (except as text) for strings in form ":resourceid file.ico" or ":resourceid file.bmp", and adds these files as resources. Resource id (resourceid) must be a number between 1 and 0x7fff. Icon resource id should be > 133. This syntax (":resourceid file") is supported by scan, ShowDialog, GetFileIcon, LoadPictureFile. For example, to automatically add bitmap file used with scan, use code like scan ":10 file.bmp", and check "Auto add image files".
QM 2.2.0. Any files can be added to exe using #exe addfile. They are added as resources of type RT_RCDATA.
To add more resources, you need a resource editor. QM does not have its own resource editor, so you would have to find and download one. Using the resource editor, add all that you need and save to a file with res extension. Specify the file in the Make Exe dialog. When creating exe, QM will add resources from the file to the exe.
Whenever you edit image files or res file, you should make exe again, otherwise resources will not be updated in exe.
QM functions that support resources: ShowDialog (title bar icon, icons, bitmaps, menu, accelerators), DT_CreateMenu (menu, accelerators), scan (bitmap, icon), GetFileIcon (icon), LoadPictureFile (bitmap). With these functions, a resource can be specified as string in format ":resourceid" (e.g. ":300").
Resources also can be used with Windows API functions (LoadImage, FindResource, and other). These functions require the handle of the module that contains resources. In exe it is _hinst variable. However, it does not allow you to use these resources with API functions when the macro runs in QM, because then _hinst is qm.exe module handle. Use GetExeResHandle instead. In exe, it simply returns _hinst. In QM, it loads the exe file as data file and returns its module handle. Example: int hi=LoadImage(GetExeResHandle +133 IMAGE_ICON 0 0 0). Such code will run in QM as well as in exe.
You should not use dialog resources because you can create dialogs in QM. With dialog resources you could not use ShowDialog and all additional features that QM provides (control variables, etc). Menus also can be created in QM but you may find it easier to use a resource editor instead (currently QM does not have a WYSIWYG menu editor).
By default, to exe are added these resources: manifest 1 (if manifest file is specified) and icon 133 (if icon file is specified).
Some functions and other QM features are unavailable in exe. Most of them are related to QM items and interface, and therefore have no sense in exe. Others use QM hooks, services, etc, that would cost too much in exe.
Unavailable functions:
deb, dis, newitem, share, str.setmacro, SilentExport, SilentImport, CompileAllItems, RecGetWindowName, OnScreenRect, GetLastSelectedMenuItem, StartProcess, __TypeLibDialog, InsertStatement.
Unavailable only some features:
mac can start only functions. Cannot open items (+).
qmitem can be used only to get item id.
str.getmacro can only get text and name.
_error.line (will be empty).
flag 3 with end (will behave as without flag 3).
shutdown -2, -3, -4, -5 (will fail at run time).
str.encrypt algorithm 16 (will fail at run time).
wait x KF (wait for key-down and eat).
EnsureLoggedOn cannot unlock (will always return 0 if locked).
Functions from System folder that use unavailable functions also cannot be used in exe. For example, RunTextAsMacro and similar functions use newitem. These functions are in "\System\Functions\Qm\unavailable in exe" folder.
QM detects unavailable functions when creating exe. It also detects unavailable features used with mac, qmitem, str.getmacro.
A special constant EXE can be used with #if to include/exclude code that is not supported in exe. It is 0 when compiling macro that will run in QM, and 1 when compiling macro for exe.
Other unavailable features:
Menus, toolbars, TS menus. Only macros, functions and member functions can be added to exe. Other items can be added only as text (to use with str.getmacro, etc).
QM user interface (macro editor, list of macros, output, recording, tray icon, etc). To add tray icon, you can use AddTrayIcon.
Source code.
Triggers.
QM command line parameters.
Sounds (as well as any other settings in the Options dialog).
Automatic registration of COM components. If you distribute COM components with the program, you can use RegisterComComponent to install them (admin privileges required).
Does not load rich edit dll, except when a rich edit control is used in a dialog. To use rich edit controls not in dialogs, at first load dll: LoadLibrary("Riched20.dll").
QM_Grid window class.
Although net in exe can be used to run macros in QM, exe itself cannot be controlled.
Cannot unlock locked computer (Properties -> Common -> Unlock ...).
In QM, it is possible to execute functions while compiling. You cannot use this when compiling exe.
Some predefined variables have different values when the macro runs in exe.
Predefined constants (as well as all constants) have values specific to the computer where the exe was created, not where it runs.
Special folder $qm$ is the path of the exe file, not the path where QM is installed. $my qm$ is always My Documents\My QM (in QM it may be different if changed in Options). Also, the folder probably does not exist on computers when the program will run.
Exe always uses default values for settings in Options -> Run Time. For example, default macro autodelay is always 100.
Some functions are implemented differently in exe, and therefore may behave slightly differently in some cases. It includes:
run flags 0x10000 and 0x20000 (run as admin) work differently on Vista.
web may work differently on Vista.
Windows Vista includes a new security feature - User Account Control (UAC). With UAC, even if you are working on an administrator user account, most programs have only standard user's privileges. It creates various problems for many programs, including QM. They cannot write to many file system and registry locations, manipulate services, and much more. Also, most of them cannot interact (use keyboard, mouse and menu commands, send messages, use hooks, etc) with programs that have higher privileges. QM can interact with all programs, but UAC may be a problem for QM-created programs. Read more about it here.
Since most programs on Vista run with standard privileges, your QM-created programs will be able to automate them. If they have to automate programs with higher privileges (admin or uiAccess), or if they need higher privileges for other purposes, they must be started as administrator or marked as uiAccess.
To mark a program as administrator or uiAccess program, add a manifest resource with certain tags. uiAccess programs also must be signed. A code signing sertificate costs about $200/year. The default manifest specifies normal privileges (level="asInvoker" uiAccess="false"). Other level values that can be specified are "highestAvailable" and "requireAdministrator". uiAccess can be "false" or "true". You can find more information about UAC and MS Authenticode code signing on the Internet. Also you can ask about it in the Quick Macros forum.
See also: GetProcessUacInfo, Run in separate process
Normally, macros run in QM process. If you check "Run in separate process" in Properties, the macro will run in its own process. This option is available for macros and functions.
When you launch such a macro or function, QM creates and runs exe. It uses default exe settings, but you can change them. If exe already exists when you launch the macro, QM compares exe file time with macro last edit time. If macro was edited after creating exe, QM creates exe again. If exe project settings are associated with a folder, QM also checks all macros/functions in the folder. If the macro directly or indirectly uses functions from other folders, after editing these functions you can update exe using menu Run -> Make Exe.
This feature can be useful when creating/debugging exe that is not to be run from QM. Instead of invoking menu Run -> Make Exe and Run -> Run Exe, you can just click the Run button. The exe file is exactly the same as if you create it using menu Run -> Make Exe.
This feature can be useful on Windows Vista, when some functions require certain privileges while QM is running with different privileges. There are several predefined sets of privileges - integrity levels (IL). Process IL is assigned when starting the process and cannot be changed later. QM can run as administrator (High IL), normal (Medium IL) or uiAccess (Medium+uiAccess IL). Exe can run as:
| 0 | As QM | The same IL as of QM. |
| 1 | User | Medium IL, even if QM is running as administrator. |
| 2 | Administrator | High IL. On non-admin accounts also runs as admin but shows a password dialog. |
| 3 | Highest available | High IL on admin accounts. As QM on non-admin accounts. |
| 4 | Low | Low IL, like Internet Explorer running in protected mode. |
| 5 | As QM, -uiAccess | The same IL as of QM, but without uiAccess privileges. |
To run exe files with various IL, QM uses function StartProcess. You can also use it in macros, except in exe. The first argument can be one of values from the table.
Integrity levels are used only on Vista, and only if UAC (User Account Control) is on. Otherwise, exe will run with same privileges as QM, regardless what IL is selected. The only exception is "Administrator", which also is applied on non-administrator accounts on other OS.
On non-administrator accounts, if IL is different than QM, exe may run as other user than QM. Possible problems with user-specific special folders ("$personal$, "$my qm$, etc) and registry keys. If exe does not run, try to change its path (in Make Exe dialog) from "$my qm$" to some common folder, for example "$common appdata$\qmexe".
Vista IL that is specified in Properties is applied only if the exe is started by QM like a macro. It is not applied if the exe is started using run or when you double click exe icon in Windows Explorer. To apply it when you double click exe icon, check "Run in separate process", create shortcut to the macro, and use the shortcut.
When you run the macro using mac, a command line can be passed to the exe process. The main exe thread receives the string through the _command variable. String and numeric arguments also can be passed (use function). Don't pass pointers and references.
mac "macro name" "command line" 5 "string arg"
To manage the exe process (display running macro icon, end macro on Pause, etc), QM creates a thread. It is listed in the Running Items list and in the Threads dialog. If you end the thread (or end macro using Pause), it also ends the process. If you use mac as function (ie assign to a variable), it returns thread handle. The caller macro can wait until macro ends.
int h=mac("macro name") wait 0 H h
Note: This does not work if both the macro and the caller are macros. At least one of them must be function.
If you use "Run on Run" function, it receives the command line and arguments through its first argument. The _command variable contains exe file path. The function should run the exe file and wait until it exits (e.g., run with flag 0x400, or StartProcess and wait for handle). If it does not wait, QM cannot manage the exe process. Also, it should exit soon after the process ends.
function# $ca run _command ca "" "" 0x400
In some cases, the macro does not run in separate process, even if "Run in separate process" is checked: 1. If it is a function called from code. 2. If it is a function started from exe (using mac). 3. If it is a function started by a QM startup/exit trigger and is set to run synchronously. 4. If it is a function called by QM using some special way, e.g. like a filter function.
Note that many QM features are different when the macro runs in separate process. For example, global variables are not shared by processes.
Quick Macros Professional license allows you to create, use and distribute programs without restrictions.
If you have only standard Quick Macros license, you can create and use programs, and share them with other registered QM users. You can also share programs with others, but they will see a temporary transparent text in the bottom-right screen corner while the program is running. The text is not displayed if QM (2.1.9 or later) is running and registered.
If you are just evaluating Quick Macros, you can create programs only for evaluation purpose. Programs created with unregistered Quick Macros version don't start in 50% cases.
To buy QM Professional license, visit http://www.quickmacros.com. If you already have standard license, you will receive another registration code. Enter it using menu Help -> Registration -> Change Registration Code. You'll have to re-make exe files made without QM Pro license.
If you need QM Pro license, you probably are good in programming using QM. As a result, you probably have a collection of universal user-defined functions/classes/macros/components and know other stuff that also would be useful to other QM users. You can share all it with other QM users in the QM forum (Resources). You can request a free QM Pro license for good quality contributions to the forum.