Assox v.1.0.0.0 README FILE

2009-05-19

Contents

CREDITS

tpr conceived of the original Assoc concept and released versions 0.1 through 0.6. Then I (rauls) wanted to add just one new feature, so tpr sent me the source code and... I got so involved that I ended up re-writing the program from the grounds up and adding lots of features. Assoc was renamed Assox to avoid being confused with several other Assocs on the net.

Thanks tpr! for this great concept, for testing the new versions, for making the PDF documentation and the beautiful Assox logo, for providing numerous usage examples and add-ons, and above all for suggestions and support.

Dottore created the icon. Thanks Dottore!

Warning

Starting a README file with a big warning might not be the smartest thing to do, but you really need to pay attention. If you are upgrading from a previous version, you must read the upgrade notes before you start playing with the new version. You have been warned! Read topic UPGRADING FROM PREVIOUS VERSIONS.

QUICK START

Here are four examples to get you started with Assox.

Example 1 - Associating file types using the SendTo menu

Unzip the distribution file in its own folder then double-click file "Assox Collections" to start a simple add-on which associates file types interactively. For more information see topic ASSOX COLLECTIONS.

Example 2 - Associating Firefox, Opera, Skype

If you use a portable version of these browsers, you probably would like it to work seamlessly in your system. Double-click one of the Internet browser files (vbs) located in the Assox folder: Firefox2, Firefox3, Opera9. If you also want to associate skype double-click file Skype. Should you want to go back to your standard Internet settings double-click file ResetProtocols which undoes the browser and Skype settings.

Example 3 - Associating file types using the Assox file browser dialog

Run Assox.exe and say yes when it asks if you want to create a default configuration file. Now press the Settings button to load Assox.ini into your editor program. Go to the end of the file and type: 

mp3=:::

if you want to associate mp3 files to your portable media player program. If instead you want to associate another type of file, say txt files to a portable notepad, replace txt for mp3 in the line above. Add a similar line for every program that you wish to associate with a file extension. Save the file and exit your editor.

Now press "Start>". Assox begins asking you where to find the program(s) that you want to associate. The file type (mp3 in the example above) is shown in the find file dialog title bar. Browse to your portable media player program, say \PortablesApps\XMPlay\XMPlay.exe, select it and press "OK". Repeat for all associations. You can skip some associations if you want, you will be prompted again the next time Assox runs.

When it's done, Assox shows a summary of its actions. Now open Explorer, browse to an mp3 file, double click it and verify that it opens in XMPlay.

Example 4 - Associating file types using the Wizard add-on

With examples 1 and 3 in mind, double-click file "Wizard" (vbs) to start a simple add-on which associates groups of related file types, i.e., bmp, gif, jpg (image types), to an application category, i.e., an image viewer.

See also topic PORTABLE STRUCTURE.

FEATURES

INTRODUCTION

Assox primary aim is to create file type associations as easily as possible in batch mode from a configuration file. It also lets you create shortcuts, startup items, send-to items and folders. You can associate programs to handle your e-mail and Internet calls. You can run programs and create add-ons to extend functionality.

Assox supports relative paths, so you can use it with your portable programs on a USB key. It also includes many features that help to manage a multi-user Windows installation on a fixed hard disk.

You make changes to your system by running a so-called "ADD run" from the GUI or the command line. You undo changes by running a "REMOVE run". Changes are non-destructive and safe.

HOW TO RUN

GUI

While Assox does not depend on a Graphical User Interface (GUI), it can be used with a GUI to enhance its functionality. Double click Assox.exe in Explorer to start the single-window GUI with the default settings and configuration file (Assox.ini).

In the main window you may select to apply either the "ADD" or the "REMOVE" action. ADD groups together adding file types, shortcuts, and more as specified in the configuration file. REMOVE undoes the settings of ADD. Press the Apply> button to run the selected action. Assox shows detailed results in the bottom (detail) status area.

The details area shows user rights and capabilities, depend on which options are enabled in the settings file. The detail area can be configured to show lots of details (setting DetailLevel).

Note

Some details may appear "out of sequence" because Assox postpones some operations at the end of the run, and it logs details only at that point.

Check boxes modify how Assox performs a run:

Buttons provide access to more functionality:

You may drag-and-drop files onto the window to easily create file type associations, see ASSOX COLLECTIONS.

Tip

You can change the name of the default settings and configuration file.

The default settings file is named after the name of the program executable file, where ".exe" is replaced by ".ini". So if you rename Assox.exe, say to "MyAssox.exe", Assox will look for "MyAssox.ini" as its default settings file. See advanced topic PACKAGES.

It is also possible to specify the settings file using option [General]Arguments, see topic SETTINGS.

Renaming Assox.exe to change the name of the settings file works also when Assox is run from the command line.

COMMAND-LINE OPTIONS

Assox.exe [OPTIONS] | [file.ini]

OPTIONS:  /?
          /ini=file.ini
          /exit=status.txt
          /S
          /unreg
          /add-on=1
          /col PATHS    (forces /S) (no other options allowed)
file.ini: same as /ini=file.ini     (no other options allowed)

Relative (to the start folder) paths for /ini, /exit and file.ini are supported: 

..\..\Assox.exe /ini=".\MyIni.ini" /exit="..\joe\exit.txt"
Assox.exe config\MyAssox.ini

With no /ini= option, Assox reads a default file Assox.ini from its start folder.

Specifying just file.ini - and no other options - on the command-line is equivalent to /ini=file.ini.

Invalid/unrecognized options are silently ignored. Valid options: 

/?             show version information and quit
/ini=          use an alternate file for settings
/exit=         write exit status information to file (1)
/S             (uppercase) run in silent mode, no GUI (2)
/unreg         clear previous items from the registry (3)
/add-on=1      see below (4)
/col PATHS     see below (5)

The maximum length of a command-line is 1023 characters.

  1. The status file must not exist. Upon exiting, Assox will fill it with the following information reflecting the results of the silent run, or of the last GUI run:

    By checking for the existence of the statusfile, a batch file can determine when Assox has finished.

  2. The GUI is shown by default. This is recommended on first use. /S turns the GUI off, except possibly for some prompts that depend on your settings file. To completely turn off all prompts, you may need to adjust your settings.

  3. The items to be removed/disassociated are read from the configuration file.

  4. For /add-on=1 is for special use. See topic ADD-ONS.

  5. This option sends PATHS to ASSOX COLLECTIONS. PATHS are one or more full paths to be added as items when Assox is restarted in GUI mode. /col PATHS implies /S and must be the last option on the command line.

CONFIGURATION

By default Assox reads its program settings and what items to do, such as which file type associations to make, shortcuts to create, or programs to start, etc. - from its configuration file Assox.ini. You can specify an alternate configuration file with option /ini. See topic SETTINGS.

Note

all items in the default Assox.ini are commented out. Remove the ';' from the beginning of each line and modify application paths, or take advantage of automatic path finding, see topic APPLICATION CHECK.

The contents of Assox.ini are not case sensitive. However, it is highly recommended to use the same case shown in this document and in the default files.

It is possible to keep program settings and items in two separate files (setting RedirectItems).

ITEM SYNTAX

Note

By convention UPPERCASE syntax elements represent sets of literal words, and convey the meaning of those words in the specific context where they are used.

When writing actual items, you need to replace uppercase elements with literal words. Punctuation and symbols are always literal.

Here is the full syntax of an Assox item line: 

TYPE\NAME;MODIFIERS=|PATH; ARGS
The only required elements are TYPE and the equal sign character.

TYPE tells Assox what to do, it is the most important element. When TYPE starts with _ it denotes a built-in action, otherwise it is assumed to denote a file type (a filename extension).

PATH is mostly a file or folder path, although in some cases it can be a set of arbitrary words. When it is a path, it can be absolute or relative. Absolute means that PATH starts with a disk letter followed by :\, such as C:. If it is not absolute, PATH is considered to be relative with respect to the folder where Assox is located.

Here are some examples of valid items: 

; a minimal valid item, just TYPE=PATH
doc=C:\Office\WinWord.exe

; relative path
txt=Office\MyEditor.exe

These two items tell Assox to add file type associations for .doc and .txt files with WinWord and MyEditor respectively.

Adding file type associations entails modifying the system registry, since that is where Windows records file associations. Once those associations exist, Assox may exit, since it is Windows that takes care of starting WinWord and MyEditor.

At some point you may need to remove the file type associations. To do so with Assox you give it the same two items, and tell it to remove them. See topic UNDOING CHANGES.

ARGS is a list of application-dependent parameters. Notice that you need to separate PATH from ARGS with a semicolon character, which is not part of ARGS. 

; example of ARGS /P "%1"
txt=Notepad.exe; /P "%1"

This item tells Windows to provide command-line parameters /P "%1" when it starts Notepad.

All characters that follow the semicolon are passed as arguments. In most cases you should add a space after the semicolon, so Windows will know where to split the application path from its list of parameters. See topic COMMAND-LINE PARAMETERS.

NAME can be an arbitrary set of words of your own choosing, but it must not start with _. 

_set_\Greetings=|Hello there!

Here we see a built-in type (_set_), a NAME (Greetings), a new symbol (|, the vertical bar or pipe character after the equal sign) and a PATH comprised of arbitrary words (Hello there!)

You name an item to be able to refer to it in subsequent items. Not all item TYPEs support NAMEs. If they do not, the name you give is simply ignored. Notice that you need to separate the TYPE from the NAME with a backslash character \.

Names can also be used to actually name a file, such as when you create a shortcut with the built-in action _shortcut_: 

_shortcut_\Open Windows Folder=C:\WINDOWS\

Names can also be used to label an action in a file association: 

txt\print=C:\Windows\system32\Notepad.exe; /P "%1"

Here when you right click a text (.txt) file in Explorer, you will see a new menu entry "print" which will start Notepad with command-line parameters /P and the selected file. See topic VERBS.

Let's go back to our greetings example: 

_set_\Greetings=|Hello there!

The vertical bar after the equal sign tells Assox to accept the literal value of PATH without further processing it, otherwise normally Assox would verify that PATH is a valid file or folder, and stop if it is not. See topic APPLICATION CHECK.

So what does _set_ do? It assigns the value "Hello there!" to the name "Greetings". So in subsequent items you could use $(Greetings) to mean "Hello there!": 

_shortcut_\My Essay=notepad.exe; "$(Greetings)"

You could have multiple variables in the same item line. Assox always expands all variables into their values before applying the line. Several pre-defined, read-only variables are also available. See topic VARIABLES.

Built-in actions, such as _set_ and _shortcut_, provide access to the various features of Assox. See topic BUILT-IN ACTIONS.

MODIFIERS may be added to a built-in action to refine how Assox performs it. Not all built-in actions support MODIFIERS. Notice that you need to separate the NAME from the MODIFIERS with a semicolon character: 

; correct syntax
_shortcut_\Minimized Notepad;_mode_;7=C:\Windows\system32\Notepad.exe

; wrong syntax, missing backslash
_shortcut_;_mode_;7=C:\Windows\system32\Notepad.exe

MODIFIERS are always written as a list of KEYWORD;VALUE pairs, where elements of the list are separated with a semicolon character - just like a semicolon character separates the KEYWORD from the VALUE.

KEYWORDs must start with _ and are specific to the built-in action. Values are literal and depend on the KEYWORD. See topic BUILT-IN ACTIONS.

Assox syntax has evolved over time, so some old elements remain and may give you unexpected results. See advanced topic DEPRECATED AND OBSOLETE.

More examples: 

; associate e-mail to nPOPuk
_mailto_=nPOPuk\nPOPuk.exe

; associate "call to" web links to skype
_callto_=C:\Skype\Skype.exe; "/callto:%1"

; PATH can use Windows environment variables, such as USERPROFILE 
mp3\enqueue=|%USERPROFILE%\apps\TheKMPlayer\KMPlayer.exe; /ADD "%1"

; or predefined, read-only variables, such as $EXEDIR, and more
_shortcut_\Click Me!;_icon_;$EXEDIR\icons\hypnotic.ico,2=spirals.exe

BUILT-IN ACTIONS

When the TYPE syntax element does not denote a file type (filename extension) it denotes a built-in action. All built-in actions start and end with the _ (underscore) character.

Warning

Mispelled built-in actions are interpreted as file types and result in creating a new file association in the system registry, which is most likely not your intention.

ACTION

ADDS/REMOVES

TOPICS

_set_

user variable

USER-DEFINED VARIABLES, SHORTCUTBASE AND FOLDERS, STARTING PROGRAMS

_shortcut_

desktop shortcut

SHORTCUTS, SHELL LINKS

_startup_

startup shortcut

SHORTCUTS, SHELL LINKS

_sendto_

sendto menu item

SHORTCUTS, SHELL LINKS

_browser_

internet browser

INTERNET, PROTOCOLS

_mailto_

internet mailto

INTERNET, PROTOCOLS

_callto_

internet calling

INTERNET, PROTOCOLS

_dir_

folder

SHORTCUTBASE AND FOLDERS

_write_

message (GUI)

MESSAGE BOX

_start_

starts a program

STARTING PROGRAMS

_refp_

program reference

PROGRAM REFERENCES

_assist_

assist add-ons

ADD-ONS

FILETYPE

file association

SETTINGS, VERBS, ASSOX COLLECTIONS

_set_ is used to create user-defined variables which can be referenced in subsequent items. _set_ has other interesting properties, such as the ability to create variables in the Windows environment, and to run programs. See topic VARIABLES.

_shortcut_, _startup_ and _sendto_ all create so-called "shortcuts", or more appropriately "link files", that point to a program, folder, network share, and even to exotic entities, such as control panel applets, etc.

The main difference among these three pre-defined actions is the location of the link file: _shortcut_ places it on the desktop; _startup_ places it in the Windows Startup folder, so the link file is auto-started each time you log on; _sendto_ places the link in the Windows SendTo folder, so the link name appears when you right-click a file and select the "Send To" menu. There are other important differences. See topic SHORTCUTS.

_browser_, _mailto_ and _callto_ provide a way to define which programs should start when you click on internet links, such as webpage addresses, mailto links in web pages or callto links for Skype and similar calling programs. See topic INTERNET

_dir_ creates and removes folders (directories). See advanced topic SHORTCUTBASE AND FOLDERS.

_write_ is used to display user messages and message boxes. See advanced topic MESSAGE BOX.

_start_ is used to start programs after all other item types have been processed. See advanced topic STARTING PROGRAMS.

_refp_ creates a reference to a program. This reference is then used to start the program, one or more times.

_assist_ provides assistance to add-on packages which extend Assox functionality. See advanced topic ADD-ONS.

FILETYPE is a file name extension, i.e., mp3 for MP3 files: song.mp3. You are not restricted to existing file extensions, you can make up your own for special applications. FILETYPE creates an association between the file extension and the program PATH. See topic SETTINGS.

If you specify an existing file extension, PATH overrides the program currently associated with that extension. When you remove the association, the previous program association is restored. See topic UNDOING CHANGES.

You may also use FILETYPE to extend the right-click menu for a file type, and perform several other customizations. See topic VERBS.

You may also combine multiple filename extensions in a single FILETYPE by separating them with semicolons. See topic VARIABLES AS LISTS OF FILETYPES.

UNDOING CHANGES

When Assox is invoked with the /unreg switch it reads Assox.ini and "undoes it", that is it takes actions to restore the system as it was before the last ADD run.

Selecting REMOVE in the main window is equivalent to running Assox /unreg.

In detail, Assox takes the following actions:

Warning

Assox undoes only and exactly what is listed in the configuration file. You can make mistakes, so be careful.

For instance (BAD PRACTICE follows): run Assox to do a first set of changes, then modify the configuration file and run Assox again to make a second set of changes; now run Assox /unreg, it undoes the second set of changes only, since the configuration file does not list the first set of changes anymore. See advanced topic SAFETY FILE.

Tip

If you use a portable menu utility, you can create an item for Assox /unreg, and set it to run on exit so your host system will be restored when you close the menu.

Normally rebooting the system isn't required to undo the type of changes that Assox applies. However, sometimes unassigned icons may linger in the system icon cache for a while. This is harmless, although temporarily your desktop may not look exactly the way you want it.

Assox also sports a safety file feature, which alerts you when you have edited a configuration file without first undoing (unregistering) it, and offers to undo the older configuration before processing the new one, see advanced topic SAFETY FILE.

INTERNET

Web pages, documents, files, and application components include direct links to the Internet. These links connect to your e-mail program, web browser, file transfer program, internet calling application, and more.

With Assox you can easily change which default programs get used for internet functions.

Use _browser_ to change your Internet browser; _mailto_ to change which program starts when you click on an e-mail address in a webpage; _callto_ to set your Internet calling application, for instance Skype. See advanced topic PROTOCOLS.

SETTINGS

The settings file tells Assox what to do and how. It is a standard .ini file, with somewhat relaxed rules for comments.

Default settings are established in the default Assox.ini file, which is automatically created when no Assox.ini exists in the program folder.

Several mechanisms are available to rename the default settings file, see topic HOW TO RUN.

Since Assox.ini is a standard .ini file, nothing prevents you from adding your own sections to it, as long as their names do not conflict with the reserved section names.

RESERVED SECTION NAMES

SPECIAL TOPICS

[Associations]

COMMAND-LINE PARAMETERS

[Shortcuts]

SHORTCUTS SHORTCUTBASE AND FOLDERS

[Startup]

SHORTCUTS

[SendTo]

SHORTCUTS

[General]

PORTABLE STRUCTURE

[Items]

ITEM SYNTAX 

[Associations]
EnableAssociations=1
RemoveAssociations=1
EnableMailto=1
RemoveMailto=1
EnableCallto=1
RemoveCallto=1
CurrentUserOnly=1
DisableExplorerAssociations=1
CloneOnCreate=1
ExeTypes=.com.exe.cmd.bat.vbs

The family of Enable settings enable various features, which result in the creation of "items" in your computer when Assox is executed.

The family of Remove settings enable the removal of the named items, and the restoration of previous associations when Assox /unreg is executed. For example, if you use EnableAssociations=1 and RemoveAssociations=0, file types get associated based on the configuration file, but are never removed.

CurrentUserOnly if set to 1 (default), associations are modified for the current user only. If you need system-wide associations, set it to 0. Remember that in Windows user associations override system associations. See also advanced topic RESTRICTED USER SUPPORT.

DisableExplorerAssociations (enabled by default) tells Assox not to bother setting up association data specific to Explorer, since Explorer can function just as well without such data. See advanced topic EXPLORER ASSOCIATIONS.

CloneOnCreate (enabled by default) sets the way in which Assox first creates a file type entry. See advanced topic CLONING FILE TYPES.

ExeTypes (default .com.exe.cmd.bat.vbs) is a list of file type extensions that Assox displays as executable files in the find file dialog file type pull-down list, and when it receives a file type collection. See topics APPLICATION CHECK and ASSOX COLLECTIONS. You can edit this list to suit your needs (each extension must start with a dot and no spaces are allowed). If the list is empty or missing in Assox.ini the default value is used. 

[Shortcuts]
EnableShortcuts=1
RemoveShortcuts=1
OverwriteShortcuts=1
ShortcutsForCurrentUser=1
KeepOtherShortcuts=1

[Startup]
EnableStartupItems=1
RemoveStartupItems=1
OverwriteStartupItems=0
StartupItemsForCurrentUser=1
KeepOtherStartupItems=1

[SendTo]
EnableSendTo=1
RemoveSendTo=1
OverwriteSendTo=0
SendToForCurrentUser=1

Settings for shortcuts, startup items and sendtos are similar.

Enable* and Disable* settings enable/disable items of the give type.

With Overwrite* settings you can choose whether to overwrite existing shortcuts without confirmation. If you set Overwrite*=0, Assox will prompt you every time a shortcut is going to be replaced.

With Create*ForCurrentUser you specify that desktop shortcuts, startup items and sendtos are to be created in the user's desktop, startup folder, and sendto folder respectively, or in the all users' corresponding locations.

Tip

sendto items are created in Explorer's right-click SendTo menu. In Explorer you can select multiple files, right-click and select SendTo>YourItem which will start program YourItem passing all selected files as arguments (all in one line).

KeepOther* applies only when Assox is adding items in ADD runs. If KeepOther*=0 Assox unconditionally removes all items from the desktop and startup folder - either the user's or all users'. When KeepOther*=-1, Assox does the same for both the user's and all users' desktop and startup folder.

Note

Setting these options to 0 will wipe out all shortcut and startup items, not just the ones listed in the configuration file! 

[General]
Arguments=
EnableApplicationCheck=1
ShowReadOnlyNotification=1
UseAdminCheck=2
AskToRunStartupItems=1
Prefix=
Suffix=
EnableRegistryBackup=0
EnableInputExpansion=2
DisableWasComment=0
AlwaysUnregFirst=0
DetailLevel=1
RedirectItems=

Arguments (default null string) provides a way to override command-line arguments for the current Assox instance only. Set this option exactly as you would type arguments on the command line, as shown in topic HOW TO RUN. Changing this option requires restarting Assox.

When the value of Arguments is non-null, it overrides all the original command-line arguments, except for /S and /ini=. The latter is used, if present, to open a settings file, which may itself specify a replacement settings file by means of another option Arguments.

You may also use environment variables and predefined variable $CMDLINEOPTIONS to set Arguments, see the examples in advanced topic PACKAGES.

Note

Setting Arguments does not affect $CMDLINEOPTIONS, and viceversa.

EnableApplicationCheck (default 1) - "Application Check" is a key feature that applies to the file or folder PATH that is specified to the right of the '=' character. When ApplicationCheck is enabled, Assox verifies that the path refers to an existing file or folder, and in case it does not Assox takes appropriate actions. See topic APPLICATION CHECK.

You can use Prefix and Suffix to specify words to be added before or after the names of desktop shortcuts or startup items. For example, you can use "Prefix=Portable" to see "Portable Winword.lnk" or "Portable CCleaner.lnk" on your desktop.

AskToRunStartupItems (default 1) - At the end of an ADD run Assox runs startup items, if any. If AskToRunStartupItems=1 Assox prompts for a confirmation. After running startup items, Assox runs _start_ items, see topic STARTING PROGRAMS. Use AskToRunStartupItems=-1, to skip the confirmation prompt and not run startup items.

ShowReadOnlyNotification (default 1) - If the configuration file is read-only, Assox notifies you that repairing paths is not possible. You can disable the notification by setting ShowReadOnlyNotification=0.

UseAdminCheck (default 2) - If non-zero, Assox will stop if it is running without administrative rights. Without such rights Assox may not change system-wide registry keys. However, it may still modify registry keys that belong to the current user. Set UseAdminCheck=0 to skip the admin right check, at your own risk. Use AdminCheck=2 to enable by default the GUI checkbox "Stop non-admin" (requires restart). See also advanced topic RESTRICTED USER SUPPORT.

EnableRegistryBackup (default 0) - If 1, Assox creates two backup files of affected registry keys. Assox_regbak_begin.reg before it starts changing the registry, and Assox_regbak_end.reg when it is done changing the registry.

Note

Be wary that clicking these files loads them into the system Registry and overwrites existing values.

EnableInputExpansion (default 2) - If non-zero input lines are expanded for variables. See topic VARIABLES.

DisableWasComment (default 0) - If 1 when Assox replaces a line in Assox.ini by effect of the Application Check feature, it leaves the original line as a comment prefixed by ";^was^", otherwise it deletes the original line.

AlwaysUnregFirst (default 0) - If 1 Assox unregisters the safety file without asking for the user to confirm this action. AlwaysUnregFirst=2 skips processing the /unreg command-line option. See advanced topic SAFETY FILE.

Be wary that by setting this option you are asking Assox to potentially REMOVE items without giving you a chance to opt out.

DetailLevel (default 1) - Level 1 prints detailed information about items that require your attention. Level 2 prints the same plus details about starting programs, _if_/_ifelse_ modifiers, and repaired lines. Level 3 prints all details. Level 0 turns off details (not recommended) but it still prints a summary of each run.

RedirectItems (default null string) redirects reading items from another file, otherwise items are read directly from section [Items] of Assox.ini (default), starting from the first line following [Items] and ending at the end of the file. Set RedirectItems to a relative or absolute path pointing to a configuration file. Variables in the path value are expanded exactly as for all item lines. 

[Items]

If used, [Items] must be the last reserved section name in Assox.ini, and it includes all items according to the syntax rules explained in topic ITEM SYNTAX.

COMMAND-LINE PARAMETERS

Items may include command-line parameters (ARGS): 

_shortcut_=|%ProgramFiles%\Internet Explorer\IEXPLORE.EXE; -k http://Example.org

This will create a desktop shortcut to Internet Explorer, and the resulting shortcut will open Example.org in kiosk mode (-k).

By default Assox automatically appends parameter "%1" to FILETYPE, and no parameter to all other built-in actions.

Separate PATH from ARGS with a ';' character. Use ';' followed by nothing to specify null ARGS.

If there are multiple semicolons in the line, the leftmost one is taken as the separator.

Quote file paths if they include spaces. Examples: 

_startup_=\TC7\TOTALCMD.EXE; L="C:\WINDOWS\Offline Web Pages\desktop.ini"

; right-click menu: pause a console window until a key is pressed
bat\just-pause=C:\windows\system32\cmd.exe; /c pause

; right-click menu: run a batch file which pauses
bat\run-pause=C:\windows\system32\cmd.exe; /c "%1" & pause

Notice that you need to add "%1" to reference the batch file.

VARIABLES

Variables names are prefixed with a '$' character, for example $APPLPATH. If you need to enter a literal '$' use the three-character sequence _$_.

An item can reference the path of its associated application with $APPLPATH, $APPLPATH can be used for both absolute and relative paths. If PATH is a file, $APPLPATH expands to the parent folder of PATH. If PATH is a folder, $APPLPATH expands to the PATH itself. For example: 

_startup_=Total Commander 7\TOTALCMD.EXE; L="$APPLPATH\Plugins\wcx"

This creates the following shortcut - assuming that Total Commander is in directory "F:\Total Commander 7" and Assox is F:\Assox.exe: 

"F:\Total Commander 7\TOTALCMD.EXE" L="F:\Total Commander 7\Plugins\wcx"

$APPLPATH is just an example. There are many other pre-defined variables, and also user-defined variables. Variables begin with the '$' character. When Assox finds '$' characters it attempts to expand variables on both sides of the '=' character: 

ext=$WINDIR\system32\cmd.exe

becomes C:\WINDOWS\system32\cmd.exe.

Option EnableInputExpansion in Assox.ini determines what happens when Assox expands variables (the following discussion assumes that '=' and not '=|' is used):

See topic PRE-DEFINED VARIABLES for a complete list of pre-defined variables.

USER-DEFINED VARIABLES

Assox provides read+write user-defined variables. Use _set_ to change their value, and to perform special operations: 

; set value of NAME to a folder path
_set_\NAME=J:\portables\

; modifiers perform special operations (run DIR C:\ hidden)
_set_\NAME;_f_;x=C:\$SYSDIR\cmd.exe; /c DIR C:\

Reference a variable value with $(NAME): 

_set_\ROOT=..\..\
jpg=|$(ROOT)IrfanView\i_view32.exe
tif=|$(ROOT)IrfanView\i_view32.exe

The above example creates a ROOT variable that points two folders above Assox, and sets the default association of JPEG and TIFF files to IrfanView.

Note the use of "=|" in items jpg and tif. In this example we do not want a file dialog to appear if jpg or tif point to an invalid PATH. We want to restrict the eventual dialog to item _set_ only, so we protect jpg and tif with "=|". See also topics APPLICATION CHECK and PRESERVING PATH.

Appending a \ to the path ensures that the find folder dialog - as opposed to the find file dialog - is invoked when needed.

Tip

By setting a ROOT variable you only need to change its assignment when you move the IrfanView folder elsewhere, or leave ROOT unchanged and let Assox prompt you only once with the folder find dialog.

User-defined variables must be set before they can be referenced, otherwise the line that references the undefined variable is skipped as an error. User-defined variables can reference other variables. They can also be set to the null value by not writing anything after the '=|' symbol.

User-defined variables can also reference environment variables as $(%NAME%). The environment variable NAME must be defined, otherwise Assox will return an error: 

_set_\TempFolder=$(%TEMP%)

If an error occurs while setting a variable, or if a file/folder find dialog is cancelled, the variable is set to an undefined value, which is itself considered an error. Any subsequent lines that use that variable generate an error as well and get skipped.

Notice that the interpretation of _set_ syntax slightly differs from all other items:

MODIFIERS: 

       _f_;FLAGS   see below
      _if_;EXPR    set variable conditionally - see below
_ifsanity_;EXPR    set variable conditionally - see below
      _dh_;TEXT    find dialog header text - see below
    _mode_;NUM     0(invisible) *1(normal window) 3(maximized) 7(minimized)
    _wdir_;WPATH   working directory

FLAGS is a string of characters, where each characters has a special meaning: 

e   export to Assox environment
%   expand environment variables
v   export to system volatile environment
!   request compliant programs to update their environment
x   capture program status and set $(ERRORLEVEL)
y   capture program output and set $(ERRORLEVEL)

e exports NAME=Value to Assox environment: 

; override COMMANDER_PATH before running Total Commander
_set_\COMMANDER_PATH;_f_;e=$EXEDRIVE\TC\
_start_=TotalCommander\TOTALCMD.EXE

Using _set_ without FLAGS would create a user-defined variable COMMANDER_PATH that only subsequent Assox items could see. By adding e the variable is exported to the process environment of Assox, so effectively it is inherited by all processes that Assox starts.

% expands all environment variables in PATH. For instance, assuming that the environment contains two variables A and B holding values "this is A" and "this is B" respectively, then: 

_set_\C;_f_;%=|%A% and %B%
_write_=|$(C)

writes "this is A and this is B" to the detail window. If an environment variable ENVVAR does not exist, %ENVVAR% remains unchanged (no error).

v exports NAME=Value to the system volatile environment, where it

survives for the duration of the current logon session.

! tells compliant programs to update their environment to incorporate the changes made to the system volatile environment. Only a few programs are compliant, most notably the Windows Explorer shell is, which means that after a ! update, every program that Explorer starts inherits NAME=Value also. This is often used to add search folder paths to system %PATH% variable: 

_set_\Var;_f_;v!=|VALUE
;
_shortcut_\test=$SYSDIR\cmd.exe; /k  echo Var=%Var% & if "VALUE"=="%Var%" echo IMPORTED
;
_write_\_box_;1=|CLICK DESKTOP SHORTCUT "test Var"

Var=VALUE is set inside Assox and in the volatile environment (v modifier). Due to the ! modifier, Explorer updates its own environment to include the value of Var. A Desktop shortcut is created to test the value of Var. A message tells the user to click on the shortcut. When the user clicks, a console window evaluates the value of environment variable %Var% and it outputs "IMPORTED" because it finds Var in its environment. The reason it can find it is because the Desktop shares its environment with Explorer.

Tip

A '!' modifier must follow one or more 'v' modifiers. For performance reasons it is best to add just one '!' after all 'v' modifiers in Assox.ini. Note however that Explorer can't detect environment changes until '!' is used.

x and y execute PATH[; ARGS], wait for its completion, then set user variable NAME to the program exit code (x does) or to the program captured output (y does). They both also set user variable ERRORLEVEL to the program exit code.

Note that y should be used to start console programs only -- and it hides the console window -- while x should be used for windowed programs. If you want to make x hide the program window use modifier _mode_ as described below. For x can also set the program working directory with modifier _wdir_.

Limitation: captured output length is limited to 1024 characters.

Unless you do need to capture console output, it is recommended to use modifier x rather than y, which is subject to some system limitations. 

_set_\NAME;_f_;y=$SYSDIR\cmd.exe; /c DIR c:\

sets two user variables: NAME to the output of the DIR command, ERRORLEVEL to the exit code of cmd.exe, or -100 if cmd.exe could not start. Notice that Assox blocks waiting until cmd.exe has terminated. If you had used x instead of y, NAME would be set to the exit code of cmd.exe, just like ERRORLEVEL.

_if_ and _ifsafety_ set the variable only if a set of conditions is met, otherwise the value of variable NAME is unchanged (possibly being undefined, if NAME has not been set before). Notice that if PATH is invalid and the set of conditions is false, the file/folder browser is skipped and no PATH repairing takes place. These modifiers are further explained in topic STARTING PROGRAMS.

_dh_;TEXT modifies the find dialog header. If Assox shows the find dialog for this variable, the default dialog header "Assox: Find(line #): _assist_\NAME=c:\path\" is replaced by "Assox: TEXT".

_mode_;NUM affects modifier _f_;x only which starts a hidden windowed program. Different values for NUM change window visibility as follows: 0(hidden) 1(normal window, default) 3(maximized) 7(minimized).

_wdir_;WPATH affects modifier _f_;x only by setting the program working directory.

PRE-DEFINED VARIABLES

Assox also provides several pre-defined read-only variables that can't be set but can be referenced as $VARNAME (note the absence of brackets): 

$PROGRAMFILES, $PROGRAMFILES32, $PROGRAMFILES64
$COMMONFILES, $COMMONFILES32, $COMMONFILES64
$DESKTOP (*)
$EXEDIR, $EXEDRIVE
$WINDIR, $SYSDIR, $SYSDRIVE
$TEMP
$STARTMENU (*), $SMPROGRAMS (*), $SMSTARTUP (*) startup folder
$DOCUMENTS (*) "My Documents"
$FAVORITES (*), $MUSIC (*), $PICTURES (*), $VIDEOS (*)
$APPDATA (*) requires IE5 and above, $LOCALAPPDATA
$PROFILE always current user, $ALLUSERSPROFILE
$SENDTO
$UNREG 1(processing REMOVE group) | 0(processing ADD group)
$SAFETY 1(processing safety file) | 0(otherwise); $SAFETY 1 implies $UNREG 1
$INIALWAYSUNREGFIRST value of AlwaysUnregFirst setting
$INIFILE, $INIPATH, $ININAME settings file: full file-path, full folder-path, filename (no extension)
$CFGFILE, $CFGPATH, $CFGNAME configuration file: full file-path, full folder-path, filename (no extension)
$LINENUM  current line number in $CFGFILE
$PRGNAME executable filename, $CMDLINEOPTIONS command-line options
$SHORTCUTBASE folder where _shortcut_ creates files, use _set_ or _dir_ to change
$PREFIX $SUFFIX shortcut name prefix and suffix
$QUICKLAUNCH (t) Quick Launch bar folder
$RECENT (u) Recent documents folder
$FAVORITES (*)
$FONTS Windows font folder
$TEMPLATES (*) Explorer right-click menu action "New"

(*) Current user when option CurrentUserOnly=1
(t) same as $TEMP when there isn't a QuickLaunch bar
(u) always current user

VARIABLES AS SHORTHAND

Assox supports using user-defined variables as shorthands of other items. This provides a simple, single-line, macro-like facility. For instance, you could define a shorthand for an item type and its modifiers that you find yourself using frequently, such as starting a windowed program in ADD runs: 

_set_\ExecWait=|_set_\t;_f_;x;_if_;$UNREG .eq. 0

; ExecWait notepad then explorer
$(ExecWait)=|$SYSDIR\notepad.exe
$(ExecWait)=|$WINDIR\explorer.exe

VARIABLES AS LISTS OF FILETYPES

You can assign a list of file types, separated by semicolons, to a user-defined variable, and use the variable to associate all file types in the list to the same program: 

_set_\ImageTypes=|gif;bmp;jpg;jpeg;png
$(ImageTypes)=IrfanView\iview_32.exe

APPLICATION CHECK

Application Check (the word "Application" is used for historical reasons) applies to the file or folder PATH that is specified to the right of the '=' character. When Application Check is enabled, Assox verifies that the path refers to an existing file or folder, and if it does not Assox takes appropriate actions.

If the path is invalid (file or folder not found), Assox displays a browser dialog asking you to find a valid substitute for the invalid target. If you do select a susbtitute target, it is replaced in the configuration file. This action is referred to as "repairing the path". The browser dialog window and its title bar show which configuration item is pointing to the invalid path, and Assox starts browsing in a folder as close as possible to the target. Cancelling the dialog leaves the configuration file unchanged.

After browsing for an invalid file or folder, if possible Assox converts the substitute path into a relative path to help maintain a portable folder structure. See topic PORTABLE STRUCTURE.

Tip

Append "\" to the path to get the find folder browser dialog instead of the find file dialog.

Option EnableApplicationCheck in Assox.ini determines what happens when a PATH is invalid:

See also the discussion about option EnableInputExpansion in topic VARIABLES.

IN-DEPTH DESCRIPTION

PRESERVING PATH

When you write a '|' character after '=', PATH is left "as is", that is, Assox does not check if PATH is valid. Notice that variables in the line are expanded as usual.

This feature is most useful with file types, to specify dynamic paths using environment variables. For instance: 

mp3=|%bin%\Audio\_xmplay\xmplay.exe

This tells Windows to expand variable %bin% when you click on an mp3 file. So %bin% may change to point to different folders without having to change the file type association.

Note that %bin% should point to a valid path and be defined in Explorer's context, or you'll get either an "invalid access" error message or Explorer's "Open With" dialog. To set a variable in Explorer's context you can use the MyComputer / Properties / Advanced / Environment Variables dialog, or set variables in the "volatile environment" (Google) with _set_\_f_;v! or other methods.

This feature is enabled for all TYPEs. However, be wary that if a shortcut target path includes environment %variables% and Windows can't find the target when it creates the shortcut, Windows may change the shortcut target to something else.

Another example: 

mp3=|c:\users\%USERNAME%\progs\xmplay\XMPlay.exe

This associates mp3 files to each user's own copy of XMPlay, provided that you create under c:\users a structure of folders named after each user's logon name (%USERNAME%).

VERBS

VERB is the more appropriate name for the NAME of a FILETYPE: 

ext\VERB[;][MODIFIERS]=[|]PATH[; ARGS]

When Assox creates a file type association, by default it changes the file type icon and the 'open' action, which is triggered when you left-click twice the icon. You can use a VERB to create or modify a supplemental action for the file type, i.e., 'edit': 

; without VERB: default 'open', open mp3 files with xmplay
mp3=C:\apps\xmplay\xmplay.exe

; with VERB = 'edit', edit html files with notepad (ouch!)
html\edit=$SYSDIR\notepad.exe; "%1"

MODIFIERS: 

 _icon_;IPATH[,NUM]  icon filepath - see below
  _des_;DESC         description text
_label_;LABEL        do not create if... - see below

IPATH is the full or relative path of a file that contains icon resources, such as .ico, .dll, .exe, .icl files. NUM (optional) is the icon index in that file (default 0).

_icon_ works for file types, mailto and callto associations: 

mp3\_icon_;$EXEDIR\MyIcons\audio.dll,2=XMPlay\xmplay.exe

To change the default left click action of a file without changing its icon: 

ext\open=folder\someprogram.exe

Warning

You must keep FILETYPE ico separated from all other file extensions, or their default icon will not display correctly: 

 BAD: bmp;ico;pgn=irfanview\iview_32.exe
GOOD: bmp;pgn=irfanview\iview_32.exe
      ico=irfanview\iview_32.exe

DESC - Explorer and most file managers show the description of a file type in tooltips and other similar items. For instance, Explorer shows "New RTF Document" for an .rtf file, when you right-click the desktop and choose menu entry "New". Normally Assox does not write a description of the file type. If the file type is cloned, its description is inherited (default case). If instead the file type is new its description is null. In any case you can specify your own description with _des_: 

; describe wav files
wav\_des_;lossless audio=WinAmp\winamp.exe

LABEL - Normally Explorer's right-click menu displays the VERB as a menu entry, so txt\edit= results in an "edit" entry in the context menu. _label_ specifies different text for the label: 

; verb=custom verb open, modifier=menu entry label
txt\open;_label_;Edit with &PSPad=PSPad\PSPad.exe

SHORTCUTS

Action _shortcut_ places link files in the desktop folder, either the user's desktop or all users' desktop according to setting CurrentUserOnly.

Action _startup_ places link files in the Startup folder (affected by setting CurrentUserOnly). When Assox adds these shortcuts it optionally asks if you want to run the target programs. Regardless, when you next log on, Windows starts the target programs (if the startup shortcuts still exist).

Action _sendto_ places link files in the SendTo folder (affected by setting CurrentUserOnly) where they become part of Explorer's right click SendTo menu.

PATH can be an absolute or relative path to a document or program file, a folder, or a reference to a special folder, (such as Control Panel, Printers, etc., see examples in Assox.ini).

If =| is used, PATH does not need to be fully qualified or even to exist, as Windows itself attempts to resolve shortcut targets to create portable links. For instance, when a shortcut target file is not specified with a full path, Windows looks for the file in a number of locations, and if it finds the target it inserts its full path in the link file. The rules Windows uses can get fairly complicated and possibly quite hard to predict. See topic SHELL LINKS for more information. It is recommended to keep PATH resolution simple and predictable by specifying the full path of the target file.

ARGS should not include a "%1" parameter.

NAME (optional) is used as the link file name. If NAME is not specified, the link file name is the same as the target program name.

MODIFIERS: 

  _mode_;NUM          *1(normal window) 3(maximized) 7(minimized)
   _key_;HOTKEY       keyboard Modifiers+Keyname - see below
   _des_;TEXT         description text
  _wdir_;WPATH        working directory - see below
  _icon_;IPATH[,NUM]  icon filepath - see below
_unless_;NUM          do not create if... - see below

  * = default value. Note: _start_ only supports 0(invisible) too.

HOTKEY is a case-insensitive string that combines keyboard Modifiers and a Keyname, for example: 

_shortcut_\With hotkey;_key_;CTRL+ALT+F5=SomeProgram.exe

Modifier      "ALT+" | "CTRL+" | "SHIFT+" | "EXT+"
Keyname       "A" .. "Z" |
              "0" .. "9" |
              "Back" | "Tab" | "Clear" | "Return" |
              "Escape" | "Space" | "Prior" | ...

Note

HOTKEY can activate only shortcuts that are located on the Windows desktop or in the Windows Startup folder.

WPATH is the full or relative path of the application working directory If you do not specify _wdir_ the folder where the target application is located is used, which is equivalent to using _wdir_;$APPLPATH. If the working directory can't be resolved, $EXEDIR is used.

IPATH is the full or relative path of a file that contains icon resources, such as .ico, .dll, .exe, .icl files. NUM (optional) is the icon index in that file (default 0).

Note

While a MODIFIER is expanded for the occurrence of VARIABLES, Assox does not verify whether the path in the modifier is valid. If you want for Assox to verify such a path, first assign it to a user-defined variable, then reference that variable in the modifier.

_unless_ requests not to create the shortcut if the link file is not available. This is most useful when _startup_ is the action: 

_startup_\Everything;unless;1=|C:\path\to\Everything.exe

_startup_\Everything;unless;2=|C:\path\to\Everything.exe

Unless 1: do not create shortcut if target does not exist before Windows has performed Shell Links resolution. Most people should use this option.

Unless 2: do not create the shortcut if Windows Shell Links resolution returns a non-existent file. This option is intented for special cases.

Examples: 

; create startup item APPLICATION only if app.exe is a valid file
_startup_\APPLICATION;_unless_;1=|x:\path\to\app.exe

Creating a startup item in this way ensures that Assox and Windows will not attempt to run a non-existent application and show an error message. For instance, the application might not exist because you did not copy it to a USB key.

Roughly equivalent ways to achieve the same result are: 

_start_\_unless_;1=|J:\path\to\app.exe

_refp_\APPpl;_unless_;1=|J:\path\to\app.exe
_start_=|$(APPpl)

SHORTCUTBASE AND FOLDERS

A special, pre-defined variable SHORTCUTBASE is used to set the base folder in which _shortcut_ creates shortcuts. As usual you can read this variable with $(SHORTCUTBASE).

When $(SHORTCUTBASE) is null (default), the Desktop is the base, otherwise folder $(SHORTCUTBASE) is the base: 

_set_\SHORTCUTBASE=$SMPROGRAMS\
; next shortcuts will be created in folder SMPROGRAMS\

_set_\SHORTCUTBASE=
; next shortcuts will be created on the Desktop

Notice that KeepOtherShortcuts in Assox.ini applies only to the Desktop, and even when SHORTCUTBASE is not null.

The ability to create and remove folders can be especially useful in conjunction with SHORTCUTBASE.

Action _dir_ creates/removes folders and changes SHORTCUTBASE. You can easily create shortcuts in any folder where you have permissions.

Notice that in most cases you should use '=|' with _dir_ to avoid triggering the find file/folder dialog.

_dir_ syntax: 

_dir_\DIR3=|c:\d1\d2\d3\

On ADD runs _dir_ performs three steps:

  1. create folder d3 and possibly d1 and d2 if they don't already exist

  2. _set_\DIR3=c:\d1\d2\d3\

  3. _set_\SHORTCUTBASE=c:\d1\d2\d3\

Note

After _dir_ if you want to create shortcuts on the Desktop you need to explicitly _set_\SHORTCUTBASE=|

On REMOVE runs _dir_ performs four steps:

  1. _set_\DIR3=c:\d1\d2\d3\

  2. _set_\SHORTCUTBASE=c:\d1\d2\d3\

  3. prompt user to confirm removal of folder d3

  4. remove folder d3 and all its contents recursively (zap)

Notice that depending on which sub-folders you want removed, you may need to create nested folders in multiple steps: 

; Remove d1 and d2 and d3
_dir_\DIR1=c:\d1
_dir_\DIR3=c:\d1\d2\d3

; Keep d1 but not d2 and d3
_dir_\DIR2=c:\d1\d2\
_dir_\DIR3=c:\d1\d2\d3\

Notice also that _dir_ paths are removed in the order they are found in Assox.ini, so if a first _dir_ removes a path on which a subsequent _dir_ depends, you will get a find dialog unless =| is used (recommended).

MODIFIERS: 

_prompt_;no          skip delete confirmation (not recommended)
_keep_;WHEN        preserve folder contents - see below

WHEN - To prevent folder removal depending on its contents use: 

; Do not remove $(DIR3) and its contents
_dir_\DIR3;_keep_;always=c:\d1\d2\d3\

; Remove $(DIR3) only if it is empty
_dir_\DIR3;_keep_;notempty=c:\d1\d2\d3\

Example: create a hierarchical menu of shortcuts in the Start All Programs menu: 

_dir_\My Menu=|$SMPROGRAMS\My Menu\
_shortcut_\Assox=Assox.exe
_shortcut_\Assox UNREG=Assox.exe; /unreg
_dir_\Internet=|$(My Menu)Internet
_shortcut_\Email=$(TheBAT)
_shortcut_\Opera=$(Opera)
_dir_\Graphics=|$(My Menu)Image
_shortcut_\IrfanView=$(IrfanView)
_set_\SHORTCUTBASE=
; next shortcuts will be created on the Desktop

Results in this menu structure on ADD runs: 

My Menu
   Assox
   Assox UNREG
   Internet
       Email
       Opera
   Image
       IrfanView

which is automatically removed on REMOVE runs.

Note

Explorer shows each menu level in strict alphabetical order. You can alter the order in two ways. 1) Prefix each folder name with numbers or letters so your intended order is preserved. 2) Manually rearrange menu entries in the Start menu. Be wary that the menu order is saved in registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2 and that Assox does not clear that key.

PORTABLE STRUCTURE

If you structure your application folders in a specific way, it is easier to copy them to a USB key to use your programs in other computers. Possibly the most common portable structure around is the PortableApps structure, which is described on the portableapps website. Here is how to fit and use Assox in such a structure.

You have a portable USB drive or USB key and want to make Explorer automatically start your portable programs when you click on a file icon. Let's assume the following folder structure on your portable drive (the drive letter doesn't matter): 

\
\PortableApps
\PortableApps\AppA\AppAPortable.exe
\PortableApps\AppB\AppBPortable.exe

Unzip the Assox distribution file to folder \PortableApps\Assox: 

\
\PortableApps
\PortableApps\Assox\Assox.exe
\PortableApps\Assox\doc
\PortableApps\Assox\plugins

With this structure in place Assox.ini should refer to AppAPortable.exe as ..\AppA\AppAPortable.exe.

Now you can fill Assox.ini with this portable structure in a number of ways:

  1. Use the "Application Check" feature: ext=:::

    This is the interactive way, where you basically point and click. Assox.ini items that use a clearly non-existent file name, such as ":::", trigger the interactive file/folder browser, which allows you to replace the file name with a valid, relative path. You need to set EnableApplicationCheck=1 (or 2) before running Assox. The browser always returns relative paths when they are in the same disk where Assox lives.

    Variations of this technique include using the "Assox Collections" and "Wizard" add-ons, or the drag-and drop feature. See topic ASSOX COLLECTIONS.

  2. Use $EXEDIR: ext=$EXEDIR\MyApps\ or a relative path: ext=MyApps\

    This is the manual way, where you edit Assox.ini. $EXEDIR refers to the Assox folder. This option is essentially the same as option 1, except that it does not necessarily trigger the browser, like ::: did above. In absence of the browser, $EXEDIR is not removed from Assox.ini - unless EnableApplicationCheck=2.

  3. Use an environment variable: ext=|%MyApps%

    This is also a manual way. Because of the '=|' symbol, this item will never be changed. With an environment variable you can go across file systems and disk letters. Since you could change the environment variable value independently of changing the file association, in many cases you would not need to re-run Assox to relocate an application to a different folder; you would just change the variable value to point to the new application folder. In multi-user systems you could also use a single item to point to different installations of the same application - each user's logon script would set an environment variable pointing to the user's folder.

    For this technique to work, you need to pre-set variables in the environment of you logon shell (Explorer), and this may not be possible if you are temporarily using someone else's PC. Use MyComputer>Properties>Advanced>Environment Variables to set permanent user or system variables that Explorer can see. Or use _set_\VAR;_f_;v!=VALUE to set volatile variables for the current logon session.

Tip

Double-click this shortcut to see which environment variables Explorer can see: 

_shortcut_\show_env=$SYSDIR\cmd.exe; /k set

Using environment variables to point to shortcut targets is not recommended.

ASSOX COLLECTIONS

Scenario: you want to be able to add file type associations in an interactive way.

Assox Collections is how you do it. You can use collections in two interchangeable ways: drag-and-drop files to the main window, or send file paths to Assox as command-line arguments following /col, which must be the last option on the command line (line length limits apply), see topic HOW TO RUN.

A Collection is comprised of a list of paths. All document paths - file types - must come at the beginning of the list. All program paths - applications - must come at the end of the list: 

c:\mydocs\image.jpg
c:\mydocs\image.bmp
c:\mydocs\image.psd

c:\myapps\Photoshop\Photoshop.exe
c:\myapps\irfanview\i_view32.exe

When Assox receives the paths it silently saves them into a Collection file, Assox.clc, located in its start folder.

Note

This feature requires the Assox folder to be writable.

Then when Assox starts in GUI mode it asks the user if the collections should be acquired, that is, if they should be added as FILETYPE items to the configuration file (default Assox.ini).

The plugins folder in the Assox distribution includes "Assox Collections" a simple Assox plugin that demonstrates how to send file paths as command-line options using send-to shortcuts. Start the plugin by double clicking file "Assox Collections" (vbs).

Be wary that when sending multiple paths at once from deeply nested folders, it is not unlikely that the 1023-character limit of a command-line may be exceeded. In this case Assox Collections will silently drop excess paths. The work-around is to send fewer paths at once.

ADVANCED TOPICS

PROTOCOLS

To quickly set up your portable Internet browser or Skype refer to example 2 in topic QUICK START. It exploits the protocol association actions that are described in this section.

Action _mailto_ sets the program that handles mailto: e-mail links in webpages: 

_mailto_[\][MODIFIERS]=PATH[; ARGS]

MODIFIERS: 

_icon_;PATHICO[,N]     icon

Action _callto_ sets the program that handles your Internet calling links in webpages: 

_callto_=PATH[; ARGS]

Specify ARGS that are appropriate for your program, for instance, for Skype ARGS is "/callto:%1".

Action _browser_ sets the system internet browser for a combination of web protocols: 

_browser_[\][MODIFIERS]=PATH[; ARGS]

MODIFIERS: 

_exempt_;N              skip protocol(s), see below
  _icon_;PATHICO[,N]    icon in Windows Start menu and other places
   _des_;TEXT           Windows Start menu browser label

_browser_ operates for the current user or for all users depending on the value of Assox.ini setting CurrentUserOnly.

Warning

Regardless of the value of CurrentUserOnly, some restrictions may apply if Assox runs without administrative rights.

Windows may impose restrictions, limitations and possibly even show harmless error messages. For this reason it is recommended to use _browser_ and the other actions that are described in this section, with administrative rights.

FINE TUNING

Associations

Note

After _browser_ remember to associate file extensions, i.e., 

_browser_=$(Opera)
htm;html;shtml;xht;xhtm;xhtml;mht=$(Opera)

The default local installations of Firefox 2 and 3 associate the following extensions: htm;html;shtml;xht;xhtml. The default local installation of Opera associates the following extensions: htm;html;mht;mhtml;xht;xhtm;xhtml;xml (as well as torrent (torrent protocol), wgt (widgets), and bmp;gif;jpg;jpeg;xbm (various kinds of image types).

It is generally better to be frugal in associating extensions, and add new ones as needs arise. A good starting set for all browsers is htm;html;shtml;xht;xhtm;xhtml.

Limitations

If multiple users of the same PC associate different browsers, for instance one wants Internet Explorer, another one wants Firefox, a third one wants Opera, etc., some browsers may fail to open some links.

This is due to an Assox implementation issue. For this reason the _browser_ action is considered somewhat EXPERIMENTAL.

Restrictions

Windows Explorer may impose some restrictions. When Assox detects such restrictions it prints a warning message, "insufficient rights for Windows Start menu", to remind you that - due to lack of administrative rights - in an ADD run:

and - due to lack of administrative rights - in a REMOVE run:

Windows errors

In some cases lack of administrative rights may lead to partial instead of full replacement of an existing protocol. When the new protocol is only partially associated Windows may display an error message stating that "Windows cannot find a file/program/components..." This message is annoying but harmless, and the associated program should still start when you click on the protocol link.

When Assox detects a partial instead of full protocol association it prints a warning message, "insufficient rights for full PROTOCOL NAME" to remind you that you might be getting error messages from Windows.

_exempt_ - By default _browser_ associates PATH with all these protocols: ftp(1), chrome(2), gopher(4), http(8), https(16)

To skip associating some protocols, use _exempt_;N where N is the sum of the numbers of the procotols to skip. You can associate different programs to different protocols by using several _browser_ items, for instance, to associate the ftp protocol separately from the browser use: 

; set all protocols to FileZilla
_browser_=$(FileZilla)
; reset all protocols but ftp to Firefox
_browser_\_exempt_;1=$(Firefox)
; so FileZilla = ftp, Firefox = the rest

Be aware that when you click a protocol link from within a specific browser, most likely the browser will want to handle the link directly, ignoring the program that you had associated to that protocol. For this reason, associating a protocol to a separate program is most useful if you need to run the link from outside a browser, for instance from the Windows Run dialog.

Tip

If you want to stop Internet Explorer from checking whether it is set as the default system browser, use the ReREG add-on

Create a ReREG ADD file with these contents: 

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Check_Associations"="No"
"IgnoreDefCheck"="Yes"

Change HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE for a system-wide setting. To restore the default browser check for Internet Explorer, create a ReREG REMOVE file with these contents: 

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Check_Associations"="Yes"
"IgnoreDefCheck"=-

MESSAGE BOX

Action _write_ prints the value of PATH to the GUI detail window, and displays an optional message box. Use \n to print a new-line character. The message box button ID is returned in user-variable $(BUTTON).

Assox verifies if PATH is valid, so you must use '=|' to avoid triggering the find dialog: 

_write_=|----- APPLICATIONS -----
_write_=|ROOT = $(ROOT)\nSHORTCUTBASE = $(SHORTCUTBASE)

MODIFIERS: 

 _box_;OPTIONS[,STYLES]     options and styles - see below
_file_;J:\path\to\FILE  use FILE contents as message text

_box_ displays a blocking message box: 

_write_\_box_;1=|ASSOX BLOCKS UNTIL OK IS PRESSED...

The message size limit is 1024 characters counting two extra characters for each line.

OPTIONS,STYLES

OPTIONS is a single decimal number obtained by summing up some of the many available capabilities, i.e.,: 

_box_;7  means 1(show box)+2(topmost)+4(unless safety)

VALUE

DESCRIPTION

0

write to detail window only (same as no _box_ modifier)

1

show box but do not write to detail window

2

show box topmost (can be achieved also with a STYLE)

4

show box unless processing safety

8

show box and write to detail window

16

show box unless silent (option /S)

32

show box unless REMOVE run (option /unreg)

64

show box unless ADD run

Optional message box STYLES can be specified with a comma followed by as a single number - decimal or hex (0xNNNN) - obtained by summing up Windows own message box style codes, i.e.,: 

_box_;5,0x40000  means 1(show box)+4(unless safety),0x40000(topmost style)

and is equivalent to _box_;7. With styles you can shape the message box in all the standard ways that Windows provides. In particular, you can add a standard icon to the message box, and change the button set (OK, YES, NO, CANCEL, etc.) The button ID is returned in user-variable $(BUTTON) which you should save immediately into another variable because $(BUTTON) gets overwritten.

Following is a short list of styles and button codes. See the MSDN article Message Box Function <http://msdn.microsoft.com/en-us/library/ms645505(VS.85).aspx> for further details on available message box styles.

STYLE DESCRIPTION

CODE

MB_OK (default)

0x00000000

MB_OKCANCEL

0x00000001

MB_ABORTRETRYIGNORE

0x00000002

MB_YESNOCANCEL

0x00000003

MB_YESNO

0x00000004

MB_RETRYCANCEL

0x00000005

MB_CANCELTRYCONTINUE

0x00000006

MB_ICONSTOP

0x00000010

MB_ICONQUESTION

0x00000020

MB_ICONEXCLAMATION

0x00000030

MB_ICONINFORMATION

0x00000040

MB_DEFBUTTON1

0x00000000

MB_DEFBUTTON2

0x00000100

MB_DEFBUTTON3

0x00000200

MB_NOFOCUS

0x00008000

MB_SETFOREGROUND

0x00010000

MB_DEFAULT_DESKTOP_ONLY

0x00020000

MB_TOPMOST

0x00040000

MB_RIGHT

0x00080000

BUTTON GROUP

$(BUTTON) VALUE

IDOK

1

IDCANCEL

2

IDABORT

3

IDRETRY

4

IDIGNORE

5

IDYES

6

IDNO

7

IDTRYAGAIN

10

IDCONTINUE

11

_file_ reads the text of the message from a file of any length, and writes it to the detail window. Message box output is still limited to 1024 characters.

You can use this form to verify that $(Message File) exists: 

_write_\_box_;1;_file_;$(Message File)=$(Message File)

If FILE starts with a dash character, i.e., -C:\temporay_log.txt, Assox will read it then delete it.

STARTING PROGRAMS

Assox provides several ways to start a program:

  1. _set_ action with modifier x starts a windowed program immediately when _set_ is read from Assox.ini. The program window is visible by default but it can be hidden. Assox blocks waiting for the program to terminate execution. See topic VARIABLES.

  2. _set_ action with modifier y starts a console program immediately when _set_ is read from Assox.ini. The program window is always hidden. Console output is captured. See topic VARIABLES. Assox blocks waiting for the program to terminate execution.

  3. _startup_ action - First Assox creates shortcuts in the Windows Startup folder. When it has finished processing all items in Assox.ini it can optionally start the shortcuts in the Startup folder. Assox does not block waiting for the started shortcuts to terminate.

  4. _start_ action - Assox runs start items after it has processed Assox.ini completely, and after it has started the shortcuts in the Startup folder. Assox does not block waiting for the started program to terminate. It is possible to start programs conditionally (if "this thing is true" then "start program").

  5. _refp_ references can run via _start_ items or as operands of conditional expressions. See topic PROGRAM REFERENCES.

ITEM

BLOCKING?

WHEN STARTED

_set_\VAR;_f_;x=program.exe

YES

immediately (visible, can be hidden)

_set_\VAR;_f_;y=program.exe

YES

immediately (hidden, captures output)

_startup_=program.exe

NO

end of ADD run only and at Windows logon

_start_=program.exe

NO

end of ADD/REMOVE run (after _startup_ items)

_refp_\REF=program.exe

see below

_start_=$(REF)

NO

end of ADD/REMOVE run (after _startup_ items)

_start_\_if_;$!(REF)=...

YES

end of ADD/REMOVE run (after _startup_ items)

_start_ syntax: 

_start_[\][NAME][;][MODIFIERS]=PATH[; ARGS]

During an ADD run: start PATH after startup items have started.

During a REMOVE run (including an "undo safety" run): start PATH after all items have been removed. Notice that the following behavior could surprise you: a safety run that includes a _start_ or _refp_ item with an invalid PATH will trigger the find dialog.

PATH is the full or relative path of the program you want to run. PATH resolution follows the same rules and limitations of _shortcut_ items, see topic SHORTCUTS.

NAME may be specified. If left out, the name will be set to the program name or to the program reference name, if the _start_ item references a _refp_ item.

MODIFIERS: 

    _mode_;NUM     0(invisible) *1(normal window) 3(maximized) 7(minimized)
    _wdir_;WPATH   working directory
      _if_;EXPR    conditional execution - see below
_ifsanity_;EXPR    conditional execution - see below
  _unless_;NUM     do not run if PATH is not valid - see below

  * = default value

_if_ and _ifsafety_ allow for starting a program if a set of conditions is met: 

_start_\_mode_;3;_if_;$UNREG .eq. 1=app.exe
; run app.exe maximized if $UNREG is 1

EXPR is a conditional expression combining variables, number/string quantities, and execution status of PROGRAM REFERENCES, with the following operators: 

Equality                  .eq.
Inequality                <>
Less than                 <
Greater than              >
Less than or equal to     .le.
Greater than or equal to  .ge.

Logical negation          Not
Logical conjunction       And
Logical disjunction       Or
Logical exclusion         Xor

_if_ is

_ifsafety_ is

_if_

_ifsafety_

run is: ADD/REMOVE

run is: undo safety

n

n

TRUE

FALSE

y

n

eval _if_

FALSE, ignore _if_

n

y

FALSE, ignore _ifsafety_

eval _ifsafety_

y

y

eval _if_, ignore _ifsafety_

eval _ifsafety_, ignore _if_

_wdir_ sets the program working directory. If _wdir_ is not specified, by default the working directory is set to $EXEDIR, or to the working directory specified in a PROGRAM REFERENCE when PATH is a program reference. You may use _wdir_;$APPLPATH to set the working directory to the program directory, or to any other directory.

_unless_ skips running PATH when PATH is invalid. This modifier works similarly as in SHORTCUTS.

Examples: 

_start_=$SYSDIR\cmd.exe; echo %TIME% $UNREG $SAFETY $INIALWAYSUNREGFIRST

Start CMD.exe in a normal window to show time and relevant Assox variables.

If you run this example most likely you will see two windows started. This is explained in the next example: 

_start_\_mode_;0=$SYSDIR\cmd.exe; /c if $UNREG==1 start "" "c:\app.exe" /opt

Start hidden app.exe /opt after each REMOVE pass, including an "undo safety" pass. Notice that Assox starts CMD, the CMD processes the if statement and starts app.exe.

If AlwaysUnregFirst=1 in Assox.ini app.exe would be executed twice. To execute it only once when AlwaysUnregFirst=1 use either one of: 

_start_\_mode_;0=$SYSDIR\cmd.exe; /c if $SAFETY==1 start "" "c:\app.exe" /opt
; hidden app.exe starts after each "undo safety" run

_start_\_mode_;0=$SYSDIR\command.com; /c if $UNREG==1 .and. $SAFETY==0 start "" "c:\app.exe" /opt
; hidden app.exe starts once after both "undo safety" and REMOVE runs have taken place

PROGRAM REFERENCES

The PATH of a _start_ action, and an _if_ modifier can include a program reference: 

_refp_\NAME=program.exe

; _start_ program reference NAME
_start_=$(NAME)

; use program reference NAME in an _if_ modifier
_start_\_if_;$!(NAME) .eq. 0=Another Program.exe

Notice that the _refp_ line does not run a program, it just declares a reference to it, which then needs to be included in _start_ item with $(), or in an _if_ expression with $!(). The referenced program may not even exist until the referencing item executes the reference.

Note

program references and user-defined variables share the same name space, so be vary of possible name conflicts.

Use the $(NAME) form as the PATH of a _start_ item to start the referenced program in non-blocking mode.

Use the $!(NAME) form in an _if_ expression. On evaluating $!(NAME) Assox blocks while the referenced program is being executed, and it returns the program exit status as the value of $!(NAME). -100 indicates that Assox could not start the referenced program.

Note

If you don't want $!(NAME) to block while the program is being executed, you need to start the application from a launcher which starts the program and exits immediately. Of course, Assox will use the launcher exit value as the value of $!(NAME). Example of a simple launcher: 

$SYSDIR\cmd.exe; /start "" /min "$EXEDIR\plugins\MyApp.exe"

_refp_ syntax follows the syntax of _shortcut_ items.

PATH resolution follows the same rules and limitations of _shortcut_ items, see topic SHORTCUTS.

Working directory resolution is performed as for _start_ items.

You can control execution attributes of the referenced program just like you would for a shortcut, by specifying modifiers _mode_, _wdir_, etc. When _start_ specifies the same modifier of a program reference, the _start_ modifier takes precedence.

Example 1: Font Manager: 

_refp_\Font Manager;_wdir_;C:\Fonts\=plugins\MyFontInstaller.exe
_start_\_mode_;0;_if_;$UNREG <> 1=|$(Font Manager); /install
_start_\_mode_;0;_if_;$UNREG <> 0=|$(Font Manager); /uninstall

$(Font Manager) is a program reference that would start program plugins\MyFontInstaller.exe in C:\Fonts. The first _start_ item runs MyFontInstaller /install hidden (_mode_;0) at the end of an ADD run ($UNREG <> 1). The last line uninstalls fonts at the end of a REMOVE run.

Example 2: skip starting Firefox Portable if Firefox is running: 

_refp_\CHECK FF;_mode_;7=plugins\CMDOW.exe; FirefoxMessageWindow
_start_\_if_;$!(CHECK FF) .eq. 1=FirefoxPortable.exe

This example uses freeware CMDOW v1.4.3 from www.commandline.co.uk/cmdow/ to check whether a Firefox window exists. CMDOW returns a status value of 1 (error) if that window does not exist.

Example 3: sleep a few seconds before starting some program: 

_refp_\SLEEP;_mode_;7=$SYSDIR\ping.exe; -n 3 -w 1000 1.1.1.1
_start_\_if_;$!(SLEEP) .eq. 1=Some Program.exe

Pinging a non-existent IP address (1.1.1.1) is a command-line trick to delay a few seconds. Due to the non-existent IP address, ping exit status is 1, so _if_ needs to test for .eq. 1.

IMPORTANT DETAILS

The first item sets VAR to the single string value "prog.exe; /not-an-option". The second item creates a reference which, when invoked as $(REF), runs "prog.exe" with argument "/an-option".

ADD-ONS

Visit the Assox website to download add-ons as they become available. Or contribute your own add-ons to the community. The concept of Assox add-ons is still in its infancy. An add-on could "just" be an application that works well as a right-click menu extension or as a start item, packaged with a sample Assox.ini which shows how to add and remove the application in a clean way. See also advanced topic PACKAGES.

Or an add-on could be something "more" and take advantage of some Assox-provided service. At the moment, the only "service" that Assox provides is the ability for a 3rd-party program to "dry run" item expansion and the find dialog, getting the expanded file back. This is achieved with the _assist_ item: 

_assist_\[NAME;]MODIFIERS=[|]PATH[; ARGS]

NAME is an Add-on name, for intance "reREG" for the reREG add-on. NAME is currently ignored.

PATH and ARGS are defined as for standard Assox items.

MODIFIERS are mandatory and request some kind of assistance: 

_xp_;1   expand item line according to standard Assox rules and settings.
         So if EnableApplicationCheck is not 0 Assox will check the item line
         for a valid PATH, trigger the find dialog if necessary, and replace
         the line in the configuration file.
         You can alter how Assox chooses to make some relative PATHs by
         setting appropriate values for EnableApplicationCheck.

_ps_;1   request \ to \\ replacement right of = sign if **SUBSTITUTED**
         abc=x:$EXEDIR\\plugins\\app.exe => abc=x:\\Assox\\plugins\\app.exe
         abc\N=x:$EXEDIR\plugins\app.exe => abc\N=x:\\Assox\\plugins\\app.exe
         abc\N=x:|invalid path|          => abc\N=x:\\from\\find\\dialog\\
         abc=x:\path\to\app.exe          => abc=x:\path\to\app.exe (not substituted)

_dh_;TEXT

         If Assox shows the find dialog, replace the default dialog header
         "Assox: Find(line #): _assist_\NAME=c:\path\" with "Assox: TEXT"

An add-on can use Assox to expand variables, check and possibly repair invalid paths listed in an add-on file. This file must be formatted according to standard Assox syntax and should include all necessary settings to guide Assox, for example: 

[Associations]
EnableAssociations=1
[General]
EnableApplicationCheck=2
EnableInputExpansion=2
UseAdminCheck=0
DisableWasComment=1
[Items]
_assist_=|x:\path\to\a file
_set_\OPTIONS=|expand variable OPTIONS
_assist_=|x:\path\to\another file; $(OPTIONS)

An add-on that runs Assox may:

See also topic HOW TO RUN.

Command-line option /add-on=1 - Add-ons that need to start a second instance of Assox must specify this option. This is not an option for general, wide-spread use! This option disables safety copy creation and processing, and Assox Collections.

Warning

When file repairing is enabled and you use option /add-on=1, use also option /ini to specify a private configuration file and avoid the danger that two running instances of Assox write to the same file.

PACKAGES

You can create a click-and-run deployment unit by means of a package, which combines the Assox program file with a preconfigured settings file. Clicking the program icon automatically runs your configuration.

Packages allow you to easily identify which files comprise your own solution, and to avoid overwriting files that belong to other solutions. This is achieved simply by renaming the Assox program file, which in turn makes the renamed program look for a default settings file by its same name. Be wary that this rename rule applies to several other run-time files, as listed in section REFERENCE INFORMATION.

The renamed settings file may set option [General]Arguments to provide Assox with command-line arguments which would otherwise be more difficult to package within your solution. Notice that changing the value of [General]Arguments requires restarting Assox.

You could use a package to start a second instance of Assox, using some of the techniques that are outlined for ADD-ONS, including bypassing the safety run. Furthermore, the package settings file could start another package so as to create a sort of "chained" execution of Assox instances. This mechanism could be repeated several times to create a longer "chain".

In particular, you could also use a package to start some applications before others. Place the first group of applications in the first package, and the second group of applications in the second package, then chain the packages and run the first package.

Example 1 - Disabling safety (not recommended)

Effectively, all you need to do to disable safety is to add this line to section [General] in Assox.ini: 

Arguments=$CMDLINEOPTIONS /add-on=1

/add-on=1 turns off safety. $CMDLINEOPTIONS imports all command-line options as new run-time arguments for the currently running instance. So the above is equivalent to running Assox with whatever command-line options you specify + /add-on=1 + an implicit /ini=Assox.ini.

Example 2 - Disabling safety (not recommended) with packages

This example builds upon Example 1 to show how to create a package that runs with safety disabled. For the sake of comparing results, we will also create a second package that runs with safety enabled. The two packages will share the same set of items.

Copy Assox.exe to NoSafety.exe. Run NoSafety.exe and answer yes when you are asked if you want to create NoSafety.ini, click OK, then select Edit NoSafety settings and exit and press button [Start>]. Change: 

[General]
Arguments=/S $CMDLINEOPTIONS /add-on=1
RedirectItems=Items.ini

Now copy Assox.exe to Safety.exe, and repeat similar steps to create and edit settings file Safety.ini. Change: 

[General]
Arguments=/S $CMDLINEOPTIONS
RedirectItems=Items.ini

Finally use your text editor to create Items.ini with these contents: 

_write_\_box_;2=|RUNNING $PRGNAME $CMDLINEOPTIONS\nREMOVE=$UNREG SAFETY=$SAFETY\nINI=$ININAME CFG=$CFGNAME

This item will tell you which package is running and in which run-mode (REMOVE vs. ADD, and SAFETY). In an actual solution, this is where you should add new items that depend on the run-mode.

This whole example runs in silent mode because of the /S argument in [General]Arguments. Delete /S if you want to see the GUI. Later you could add back /S to run silently again, or you could specify /S in the target field of a shortcut that starts this package.

Click NoSafety.exe to apply items from Items.ini while bypassing the safety feature. Click Safety.exe to apply the same items with safety enabled.

Run NoSafety and Safety several times. Each time modify Items.ini to see when $SAFETY changes value. Try also adding /unreg to the Arguments option to see when $UNREG changes value. Alternatively, add /unreg to the shortcut that runs this package.

Example 3 - Running items before and after Assox

This example builds upon Example 2 to show how to run some items before and after the main Assox run takes place. We will refer to the Shortcutler add-on, which saves and restores the state of desktop shortcuts. Shortcutler must run before the main Assox ADD run has started adding new desktop shortcuts, and after the main Assox REMOVE run has removed all its desktop shortcuts.

The example defines Shortcutler with a shorthand (see topic VARIABLES AS SHORTHAND) so if it is not available on your system you can easily change the shorthand and continue running this test. To run the plugin we define another useful shorthand. You could reuse these shorthands in your real configuration files. Let's go back to the example.

Copy Assox.exe to Sandwich.exe. (The name Sandwich conveys the idea that we are sandwiching Assox between a pre- and a post-run of some add-on). Go to the usual steps to create and edit Sandwich.ini. Change: 

...
[General]
Arguments=$CMDLINEOPTIONS /S /add-on=1

[Items]
; shorthand
_set_\APP BEFORE=|$EXEDIR\plugins\Shortcutler\Shortcutler.exe; /a /c /d
_set_\APP AFTER=|$EXEDIR\plugins\Shortcutler\Shortcutler.exe; /a /c /o /restore
_set_\RUN ON ADD=|_set_\status;_f_;x;_if_;$UNREG .eq. 0
_set_\RUN ON REMOVE=|_set_\status;_f_;x;_if_;$UNREG .eq. 1
_set_\RUN ALWAYS=|_set_\status;_f_;x

$(RUN ON ADD)=|$(APP BEFORE)
$(RUN ALWAYS)=Assox.exe; /ini=Assox.ini $CMDLINEOPTIONS
$(RUN ON REMOVE)=|$(APP AFTER)

_set_\_f_;x is used to run a program and wait for its completion (the variable name status does not matter, but be wary that its value will change value after each run). So here we are sequencing three items: Shortcutler.exe /a /c /d - Assox.exe $CMDLINEOPTIONS - Shortcutler.exe /a /c /o /restore. Notice that the first Shortcutler is allowed to start during ADD runs only, by effect of the _if_;$UNREG .eq. 0 modifier. Similarly the second Shortcutler is allowed to start during REMOVE runs only. Instead Assox starts during both ADD and REMOVE runs. Presumably, it should do something useful, but for the sake of simplicity let's assume that it just displays a message box and exits -- the default Assox.ini file includes a "hello world" example that you can cut and paste.

Lunch time! Click Sandwich.exe, which saves existing desktop shortcuts with Shortcutler then runs Assox ADD (no GUI). To undo all items and restore desktop shortcuts run Sandwich /unreg. Notice that since we have used argument /S, Sandwich will show no GUI so you won't be able to select a REMOVE run directly. Therefore, you should run Sandwich /unreg from the command line or a menu utility. Alternatively, delete /S from [General]Arguments recognizing that you will see two, very similar main windows, the first one for Sandwich, the second one for Assox.

Notice that Sandwich.ini needs to set /add-on=1, which disables the error dialog that prevents running two instances of Assox at the same time. /add-on=1 also disables safety features for Sandwich.exe, but not for Assox.exe which still runs with safety turned on. If you wanted to run Assox.exe without safety (not recommended) you would need to add /add-on=1 to its own _set_ item or to [General]Arguments in Assox.ini.

Example 4 - Running Assox after some items

This example builds upon Example 3. It employs a different method to start Assox, so the package is not blocked in the background waiting for Assox to terminate.

Edit Sandwich.ini from example #3 and change the last three lines: 

$(RUN ON ADD)=|$(APP BEFORE)
$(RUN ON REMOVE)=|$(APP AFTER)
_start_=Assox.exe; /ini=Assox.ini $CMDLINEOPTIONS

If you now run Sandwich.exe in ADD mode, $(RUN ON ADD) starts Shortcutler, $(RUN ON REMOVE) does nothing, and _start_ runs Assox in non-blocking mode, thus allowing Sandwich.exe to terminate.

Recall that _start_ items are always executed at the end of the run. This means that if you run Sandwich /unreg, it will always run $(RUN ON REMOVE) before starting Assox.exe, even if you rearrange the lines in Sandwich.ini. This sequencing differs from the one shown in Example 3.

Example 5 - Passing command-line vs. GUI options

Examples 1-4 use $CMDLINEOPTIONS in various ways to export command-line options from a starter Assox (a.k.a. parent) to a started Assox (a.k.a. child). This is fine if you are in the habit of running Assox from the command line or from a desktop shortcut, where you can specify command-line options. However, if you prefer to use the Assox GUI to select ADD vs. REMOVE runs, then $CMDLINEOPTIONS is limited because ADD/REMOVE selection occurs in the parent's GUI with no effect on $CMDLINEOPTIONS.

In this case the parent should use Environment Variables to pass GUI options to its child. Edit Sandwich.ini from example #3 and change: 

[General]
; remove /S because you need to see the Sandwich GUI
Arguments=$CMDLINEOPTIONS /add-on=1

[Items]
; add two lines
_set_\FROMPARENT;_f_;e;_if_;$UNREG .eq. 0=|
_set_\FROMPARENT;_f_;e;_if_;$UNREG .eq. 1=|/unreg

Next edit Assox.ini and change: 

[General]
; this will start Assox with both its command-line arguments
; and the arguments that Sandwich set in the environment
Arguments=%FROMPARENT% $CMDLINEOPTIONS /add-on=1

On REMOVE runs Sandwich.exe (parent) sets FROMPARENT=/unreg. Assox.exe (child) receives this value from setting [General]Arguments and therefore runs a REMOVE run. Replace your Assox.ini [Items] section with the one below to monitor the state of all involved variables: 

[Items]
_write_\_box_;7=|Hello World!\n\nThis is $PRGNAME $(%FROMPARENT%) $CMDLINEOPTIONS\nin $EXEDIR\nUNREG is $UNREG

When you will try this example you will see two windows, since both Sandwich and Assox run in GUI mode. The next example shows how to reduce those two windows into one.

Example 6 - showing the child's results in the parent's details

This example builds on example #5 to show how the parent Assox can start a hidden child Assox and still display its child's summary results.

Recall from topic HOW TO RUN that option /exit= writes summary results to a file. So the parent can start a child Assox with options /S /exit=exitfile.txt and then show exitfile.txt when its child has terminated.

Edit Sandwich.ini from example #5 and change the four unindented lines below: 

[Items]
      _set_\FROMPARENT;_f_;e;_if_;$UNREG .eq. 0=|
      _set_\FROMPARENT;_f_;e;_if_;$UNREG .eq. 1=|/unreg
_set_\exitfile;_f_;%=|%TEMP%\$ININAME.txt
      $(RUN ON ADD)=|$(APP BEFORE)
$(RUN ALWAYS)=Assox.exe; /ini=Assox.ini /exit="$(exitfile)" /S $CMDLINEOPTIONS
_write_=|Assox details:
_write_\_file_;-$(exitfile)=$(exitfile)
      $(RUN ON REMOVE)=|$(APP AFTER)

The first unindented line sets the name of an exit file in the Windows temporary folder. The second indented line runs the child Assox in silent mode with summary results redirected to the exit file. The third and forth unindented lines show the child's results in the parent's (Sandwich) detail window.

Notice that the "-" sign before $(exitfile) tells Sandwich to delete the exit file after use. This is important because option /exit requires that the exit file must not exist when Assox (Sandwich) starts.

EXPLORER ASSOCIATIONS

Since version 0.7 by default Assox doesn't create Explorer-specific associations in the registry. Experimental evidence on Windows XP and Vista shows that Explorer creates such associations automatically based on HKCR, so there is no need to duplicate them. You can set DisableExplorerAssociations=0 to make Assox create Explorer associations. Note that even when DisableExplorerAssociations=1 Assox /unreg will still make an effort to remove its associations, even some that Explorer created automatically.

CLONING FILE TYPES

When Assox establishes a file type association for the first time, by default it clones the HKCR registry keys of the existing file association to create the new, modifiable file association. All subsequent modifications are applied to the cloned data. No cloning occurs of registry keys already are under the control of Assox.

With this mechanism in place, you can modify the cloned file type while inheriting all its unmodified default system properties, for example, if you are modifying the .bat file extension for the first time with: 

bat\edit=PSPad\PSPad.exe

Assox creates a new .bat file type that inherits the default system definition of 'open' (CMD.exe) and 'edit' (notepad.exe) then it changes 'edit' to PSPad.exe.

In most cases cloning the file type is best practice, because the clone inherits all system properties - including the ones that you can't change with Assox, such as Content Type, Persistent Handler, etc. Modifying a cloned base ensures that your file type association will continue to behave as usual in all situations, excepting the ones where you have explicity assigned different properties.

Mastering file type cloning is not required to be able to use Assox at its basic level, such as associating a program to run when you click a file icon.

To disable this feature set CloneOnCreate=0 in Assox.ini.

RESTRICTED USER SUPPORT

Restricted users who do not have permission to write to system areas can still use Assox profitably. They are limited to writing to their own registry section and can create startup and desktop shortcuts in their own folders only. They may also skip checking for administrator rights, since they obviouly do not have them. Recommended settings for restricted users: 

[Associations]
CurrentUserOnly=1

[Shortcuts]
ShortcutsForCurrentUser=1

[Startup]
StartupItemsForCurrentUser=1

[General]
AdminCheck=0

SAFETY FILE

Scenario: As you change and improve your configuration file between runs of Assox, it is easy to forget that /unreg can only undo what is written in the configuration file. You remove some items, run the new configuration and suddenly realize that your registry still contains the values that linked to the deleted items. But you have lost the means to clear those values from the registry. That is when the safety file comes to your rescue.

The safety file feature alerts you that the previous configuration was not undone, and offers to undo it before processing the new configuration.

Upon running Assox after you have made some changes to the configuration file, Assox prompts you to undo the previous configuration before applying the new one. If you click OK, Assox runs the previous configuration with option /unreg, then resumes running the new configuration.

Note

Pay attention that only the last modification time of the configuration file affects safety. The time of the settings file has no influence.

This feature makes use of three files whose name follows the name of the configuration file, which is Assox.ini by default, or the file specified with option /ini, or with setting RedirectItems or by renaming the executable file Assox.exe (see section REFERENCE INFORMATION):

If Assox.ini includes AlwaysUnregFirst=1 Assox automatically unregisters the safety file without first prompting for a confirmation. If AlwaysUnregFirst=2 Assox also skips performing the first REMOVE run after safety file unregistration. When this happens in GUI mode, Assox prints a status message to remind why the run was skipped, while in silent mode Assox prints no reminder if it skips processing option /unreg.

Shell Links is the name of the technology that implements desktop shortcuts, startup items and send-to items, as well as all other special shortcuts in Windows <http://msdn.microsoft.com/en-us/library/bb776891.aspx>. Shell Links seem simple at first, but users are often baffled by the way links work - or do not seem to work. Amongst the most common problems, we find:

Here we try to explain in simple terms what is going on in each case, and look at some possible work-arounds.

Link icons are not refreshed - This happens quite frequently. No matter what you do - editing the link file to change the icon path, or deleting and recreating the link file, etc. the icon just isn't refreshed. If this is the case, your best option is to force Windows to rebuild its icon cache. You can use Tweak UI or other similar programs.

Link targets are broken - This can happen if you move the link target. When a link is first created, Shell Links store the target path, and they keep re-using that same path as long as it points to a valid target. If you move the link file, Shell Links automatically adjust the link definition in various ways to enhance link portability. If the target definition can't be adjusted, the next time you click on the link, Windows will prompt you to look for a new target. So you may not realize that a link is broken until you click on it. You can use a link manager, such as NirSoft's ShortcutMan, to analyze at once and possibly repair all the link files in your system.

Another possibility of a "broken" target occurs when you specify the target PATH with =| and Windows resolves it to something different than the path you expected. The rules Windows uses to resolve link targets are explained in MSDN Shell Links Resolution topic: <http://msdn.microsoft.com/en-us/library/bb776891%28VS.85%29.aspx#Shellink_Link_Resolutionk>.

Link targets specified with environment variables are created incorrectly - This happens if, upon creating the link file, Windows determines that the target path doesn't currectly exist but that it could exist at a later time. In such case, instead of returning an error, Windows creates a link file with a somewhat arbitrary link target, usually by pre-pending C:\ to the path. Here is a not-so-obvious case: 

_shortcut_\Name=|%MyDrive%\AppFolder\App.exe

Unless %MyApp% is correctly defined when Assox creates the shortcut, you will find that the target path becomes C:\%MyDrive%\AppFolder\App.exe which is most likely not what you want. You must define MyApp before creating the shortcut: 

_set_\MyDrive;_f_;e=J:
_shortcut_\Name=|%MyDrive%\AppFolder\App.exe

Note

In this case, while the link file properties will continue showing %MyApp%\AppFolder\App.exe as the link target, Shell Links really stores J:\AppFolder\App.exe as the target. This distinction is important to understand why other things may go wrong...

Link targets specified with environment variables are not updated, even after the user edits the link - This is easy to explain now. Consider this example: 

_set_\MyDrive;_f_;v!=J:
_shortcut_\Name=|%MyDrive%\AppFolder\App.exe

You would think that since MyDrive is set in the volatile environment, you can change its value and the change will be reflected in the shortcut. Wrong. Recall that Shell Links store the resolved target path and re-use it as long as it is a valid path. So even if you change MyDrive to be F:, as long as J: is a valid path, Windows will not attempt to repair the link and it will continue running J:\AppFolder\App.exe when you click the shortcut icon.

The above example should be re-written to use environment variables exclusively as arguments and not as paths: 

_set_\MyDrive;_f_;v!=J:
_shortcut_\Name=$SYSDIR\cmd.exe /c start "" "%MyDrive%\AppFolder\App.exe"

Now if you change the value of MyDrive to F: you will see that cmd.exe runs the new path and not the old one.

Send-to program arguments are ignored - This is one common misunderstanding related to send-to items. You need to specify send-tos with the following syntax: 

_sendto_\Example=x:\path\to\app.exe; /opt1 /opt2...

Note that there is no "%1" in the line above. This is because Windows automatically appends the file path without quotes when it starts the link. As some applications might expect argument %1 to be passed in another form, for instance as in app.exe /opt="%1" /opt2, they could get confused by the bare file path that Windows appends to the line. If you select multiple files and "send them", their paths will be quoted and appended to the command-line as a single, space-separated list.

Assox can't run link target programs - This could happen on tweaked or otherwise modified versions of Windows, which become incapable or running link files. When Assox runs a shortcut or startup item, what it really does is attempting to run the link file. If that fails, possibly the only cure is to restore the default Windows registry entry of .lnk files. The necessary steps are outlined in many web pages. You could also download a quick repair file here: <http://www.dougknox.com/xp/fileassoc/linkfile_fix.zip>.

Warning

By applying this fix you will radically change the behavior of shell links in your system. So make sure to investigate all implications before you apply the fix. This fix restores Windows default behavior.

Another possible reason why Assox could not run a link target is because you specificed the target with =| and Windows resolved it to something different than the path you expected. See above for information on the "MSDN Shell Links Resolution" topic.

DEPRECATED AND OBSOLETE

Assox syntax has evolved over time, so for backward-compatibility reasons it still supports some old syntax elements although they are deprecated (should not be used):

Obsolete syntax elements are parsed but not acted upon:

UPGRADING FROM PREVIOUS VERSIONS

Start with the section title that matches your current version and work your way upwards through the sections following all instructions.

FROM VERSIONS 8.0.0.0-8.0.0.1

Modifier _ico_ has changed to _icon_. Change all occurrences in your configuration file.

If you have existing configuration files that use _set_ with modifier _f_;x, you need to decide whether to change x to the new value y, because now only y can capture program output as x used to do. Use y for console programs only, and x for windowed programs. x starts visible windows, you can make them invisible by adding the new modifier _mode_;0.

The default value of EnableRegistryBackup changed from 1 to 0.

$APPLPATH now expands to PATH when PATH is a folder. Previously it mostly - but not always - expanded to the parent folder of PATH.

FROM VERSION 0.7.5.1

Version 0.8.0.0 has undergone an extensive set of changes, some of which are not backward-compatible. While compatibility is important, it is better to change bad design in its infancy, rather than have to live with it forever. Since this set of changes involves items that modify the registry, do not take any chances and follow these upgrade steps:

  1. Unregister all items using your previous version of Assox

  2. Locate the safety file, usually Assox.ini.saf, and rename it to Assox.ini.saf.old

  3. Now you can replace your previous version of Assox.exe with the new version. Do not run it yet.

  4. Edit your Assox.ini file and apply the new syntax that is explained further on.

  5. Now you can run the new Assox.exe

Option EnableInputExpansion has a new default value of 2. You should edit Assox.ini and set EnableInputExpansion=2.

Previously when a line included variables and an invalid PATH, Assox would trigger the file/folder find dialog but it would not replace the invalid path in Assox.ini. Now it does replace it. This change should only affect you if your Assox.ini includes invalid paths involving variables. You may set EnableInputExpansion=1 if you prefer the older behavior.

FILETYPE got new, more compact syntax. You can now write all modifiers on the same line. This change is not backward-compatible, so you must edit Assox.ini. Assuming: 

ext=app.exe
ext\verb=app.exe

FROM

TO

ext\_Description_=|text

ext\_des_;text=app.exe

ext\_DefaultIcon_=x:\icons.icl;3

ext\_icon_;x:\icons.icl,3=app.exe

ext\verb;_label_=|text

ext\verb;_label_;text=app.exe

Combine on one line: 

ext\MyAction;_label_;Do MyAction;_des_;ext file;_icon_;x:\icons.icl,3=app.exe

And you may also combine in a single line multiple filename extensions that refer to the same PATH: 

ext1;ext2;ext3=PATH

However, do not combine file type "ico" with any other file types.

_mailto_ got new, more compact syntax. You can now write all modifiers on the same line. This change is not backward-compatible, so you must edit Assox.ini.

FROM

TO

_mailto_\_DefaultIcon_=x:\icons.icl;3

_mailto_\_icon_;x:\icons.icl,3=app.exe

Combine on one line: 

_mailto\_icon_;x:\icons.icl,3=email.exe

_shortcut_ _startup_ _sendto_ got new, more compact syntax. You can now write all modifiers on the same line. This change is not backward-compatible, so you must edit Assox.ini. Assuming: 

_shortcut_\Name=app.exe

FROM

TO

_shortcut_\Name;_description_=|text

_shortcut_\Name;_des_;text=app.exe

_shortcut_\Name;_mode_=|integer

_shortcut_\Name;_mode_;integer=app.exe

_shortcut_\Name;_key_=|alt+F1

_shortcut_\Name;_key_;alt+F1=app.exe

_shortcut_\Name;_workdir_=path\

_shortcut_\Name;_wdir_;path\=app.exe

_shortcut_\Name;x:\icons.icl;3=app.exe

_shortcut_\Name;_icon_;x:\icons.icl,3=app.exe

Combine on one line: 

_shortcut_\Name;_mode_;0;_icon_;x:\icons.icl,3=app.exe

_set_ changed modifier syntax. This change is not backward-compatible, so you must edit Assox.ini.

FROM

TO

_set_\NAME;ev!%x=|whatever

_set_\NAME;_f_;ev!%x=|whatever

_write_ used to do nothing if Assox was running in silent mode. Now it does display the message box, but you can disable it as needed. The _box_ modifier syntax has changed, so you must edit Assox.ini: 

_box_   =>    _box_;1    box is always shown
_box_   =>    _box_;16   box is shown unless silent mode

The new range of allowed values provides more capabilities than before. See topic MESSAGE BOX.

Running shortcuts by means of modifiers _run_ and _rundel_ is no longer possible. These modifiers will be ignored, so your shortcuts will not run, or possibly Assox will create shortcuts to filter programs. You do need to review Assox.ini and replace these modifiers with pre-defined actions _start_ or _set_.

FROM VERSION 0.7.0

If you have named a backup copy of your settings or configuration file using extension .bak you should rename it to use another extension, or it will be overwritten.

FROM VERSION 0.6

If you are upgrading from version 0.6 AssoC to version 0.7 AssoX, you must run v.0.6 Assoc_unreg.exe at least once before running version v.0.7 Assox, since the new version uses different registry keys. Failing to run v.0.6 Assoc_unreg will leave old, possibly junk data in your registry, which may interfere with the correct operation of v.0.7.

Note that v.0.7 no longer creates an "edit" right-click association. You need to explicitly use the new "edit" <verb> in your configuration file. See topic ITEM SYNTAX.

Version 0.7 file format is ALMOST backward-compatible with v.0.6, except for the following changes.

Edit your associations.txt file and change all occurrences of/into: 

shortcut=     _shortcut_=
startup=      _startup_=
install=      _install_=  (-)
playlist=     _playlist_= (-)
mailto=       _mailto_=
skype=        _callto_=   (*)
bigboobs      $APPLPATH

(-) no longer supported
(*) and append:      ; "/callto:%1"
    for instance:    _callto_=P:\Skype\Skype.exe; "/callto:%1"

Rename Assoc.ini to Assox.ini and change: 

CreateShortcutsForCurrentUser       ShortcutsForCurrentUser
CreateStartupItemsForCurrentUser    StartupItemsForCurrentUser

You need to tell v.0.7 that you have a separate associations.txt file - by default Assox looks for one single, merged file for associations and settings. So, assuming that you had been using the default associations.txt file, append this line to section [General] of Assox.ini: 

RedirectItems=associations.txt

If instead you want to merge associations.txt and Assox.ini together (recommended) do this:

V.0.7 removes support for Adobe thumbnails, Install and Playlist items. For historical reasons they can still be included in the configuration file (and their options in the settings file) but they are simply ignored.

REFERENCE INFORMATION

List of reserved filenames

Limits

CONTACT

The Assox team:

Contacting us:

The website includes additional information, add-on downloads, video tutorials, and more.

LICENSE

Assox is free for download and use. By downloading or using it you accept the following license agreement. Note that the terms of the license may change over time: 

LICENSE AGREEMENT

Assox is provided "as-is" without warranty of any kind, express,
implied or otherwise, including without limitation, any warranty
of merchantability or fitness for a particular purpose. 

In no event shall the author of this software be held liable for
data loss, damages, loss of profits or any other kind of loss
while using or misusing this software.

FAQ

Q. I upgraded to version v.X.Y.Z but nothing happens, why?

A. Make sure to apply all the changes listed in section UPGRADING FROM PREVIOUS VERSIONS in the README file.

Q. I try to enqueue an mp3 file and I get error message "Access denied". The menu entry for "enqueue" is: 

mp3\enqueue=|KMPlayer\Portable KMPlayer.exe /ADD "%1"

A. The correct syntax is: 

mp3\enqueue=|KMPlayer\Portable KMPlayer.exe; /ADD "%1"

With a ';' following .exe, which tells Assox that /ADD "%1" is an argument to KMPlayer.exe and not part of the program path.

Q. If I use tabs to beautify Assox.ini I get the file find dialog, why?

A. You can use tabs to align items, but make sure not to split the =| symbol.

Q. I disabled registry backup and on next run it became enabled again. It happens with other settings, too.

A. It is correct. What you enable and disable in the GUI has no relevance to what is enabled and disabled in Assox.ini. It is only relevant for the current run. When Assox starts it reads Assox.ini to determine whether a feature is enabled and thus should be visible in the GUI. If permanently hide RegistryBackup from the GUI disable it in Assox.ini. Likewise for other options.

Q. How can I refer to Assox run drive in a path?

A. Use: 

ext=$EXEDRIVE\path\to\...
Assox run folder: ext=$EXEDIR\path\to\...
and remember that relative paths like
ext=..\..\path\to
always start from $EXEDIR, so the line above is equivalent to
ext=$EXEDIR\..\..\path\to

Q. How can I associate Skype calling?

A. Use: 

_callto_=X:\path\to\skype\skype.exe; "/callto:%1"

Q. How do I enter spaces in prefix and suffix?

A. In Assox.ini you should use quote characters, i.e.,: 

[General]
Prefix="space at the end "

Q. How can I skip the find file dialog? How can I enter a shortcut for a non-existent program?

A. Use =| for instance: 

_shortcut_\Allow me any absolute path=|C:\nowhere\to\be\found.exe
_shortcut_\Allow me any relative path=|..\..\nowhere\to\be\found.exe

Q. I set StartupItemsForCurrentUser=1 but startup items are created for All Users, why? I set ShortcutsForCurrentUser=1 but shortcuts are created for all users, why?

A. StartupItemsForCurrentUser and ShortcutsForCurrentUser are interdependent. If you enable one, you must enable the other one too, otherwise they may clash and misplace items on your desktop.

Q. _start_ items don't run!

**A.**First of all, do your _startup_ (UP) items run at the end of an ADD run?

Assox runs a startup item by running the .lnk file that Windows uses to store the shortcut properties. Some tweaked Windows systems can't run .lnk files anymore. See advanced topic SHELL LINKS in the README file for further help.

If you confirmed that _startup_ items can run, then open Assox GUI and confirm that:

  1. Assox says it has "started" an item. If it does not, probably something is wrong in your startup item configuration.

  2. If Assox says that it is "waiting for" a program, confirm that the program is not blocking Assox forever.

  3. If the start item includes modifiers _if_ or _ifsafety_, double-check expression syntax. If the expression includes blocking program references, such as $[Referenced Program], make sure that the referenced program is not blocking Assox forever.

  4. If you can confirm (1), (2) and (3), and you still can't run the item, then the file type association of .lnk files could be broken in your system, and you might need to restore the standard Windows file type association. Refer to advanced topic SHELL LINKS in the README file.

  5. If none of the above steps fixes your problem... you might have found a bug!

Q. Does Assox support Unicode?

A. No, the GUI doesn't support Unicode characters.

Q. How can I associate an application to a file named MyFile._mailto_?

A. Items that start with _ are considered built-in actions, so you just can't use file extensions that start with _.

Q. Why didn't Assox /unreg completely remove from the registry a new extension for the current user?

A. To be safe Assox /unreg removes all registry information except "OpenWithList", the key corresponding to the "recommended programs" in Explorer's Open With dialog. Explorer fills this key automatically. Use a registry editor/cleaner to determine if you want to delete this key completely.

Q. How can I specify a UNC path?

A. Currently Assox does not fully support UNC paths. However, you can work around this limitation this way: 

_shortcut_\A UNC path=|\\server\share\apps\howdy.exe

While creating the shortcut, Windows will check if the server is on-line, which may result in some delay depending on your network configuration. Be patient.