Command line options

Start wihu.exe /? for full description.

Environment variables

Following environment variables can be used in command line:

  1. Each default windows environment variable like %WINDIR%
  2. %WIHU%, %SRCDRIVE%, %SRCPATH% and %CURDIR% whereby %WIHU% points to WIHU application directory and %CURDIR% points to directory from where WIHU was started. For example "c:\>cmd.exe /c c:\Application\wihu\wihu.exe" will set current directory to c:\, but relative paths here will be expanded to c:\Application\wihu\. %SRCDRIVE% points to installation (CDROM) drive and %SRCPATH% to %SRCDRIVE%\i386
  3. %INIDIR% points to the directory from where ini file was loaded

WIHU specific environment variables

  1. %OwnerName% is the name of the registered owner of the system
  2. %OrgName% is the name of the registered organization of the system
  3. %WorkGroupName% is the name of the joined work group
  4. %USERPASSWORD% is the password of the specified user. This depends on where this variable is used. This is only available if password is set.

%USERNAME%, %USERDOMAIN%, %USERPROFILE%, %COMPUTERNAME%, %HOMEPATH% and %HOMEDRIVE% will be updated with the new values. %ThisUser% will be the same as %USERNAME%

In addition also %ThisProfile% and %ThisHome% may be used. In [users] section it's only safe to use these ones to override shell folders, no where else.

Relative paths

Each relative path will be expanded to WIHU application directory. This doesn't apply to paths specified in command.x key like command.0 = msiexec.exe /i .\data\setup.exe. The second string (.\data\setup.exe) will be expanded but not parsed by WIHU. Application (in this case msiexec.exe) is responsible to find correct path. Please consider to use workdir.x keyword here.

Ini File Syntax

Each section name like [Windows System Files] is the topic of the kind of software that should be installed. Each section can contain keywords which are described below. There is a special section which is called [Environment]. This section stores environment variables which will be added to installer process as soon as it is started. To override section name you could use Description = <Alternative name>keyword.

[Environment] Section


MozillaFireFoxVersion = HKLM:SoftwareMozilla\Mozilla Firefox\CurrentVersion
MozillaFireFoxPath = HKLM:Software\Mozilla\Mozilla Firefox\%MozillaFireFoxVersion%\Main\Install Directory
SomePath = C:\MyPath
wmp.dll.version = %SystemDrive%\System32\wmp.dll?version

Values can be registry keys (which may store the requested path) or other data. Registry keys will be initiated with keyword HKLM: which stands for HKEY_LOCAL_MACHINE or HKCU: which stands for HKEY_CURRENT_USER. The last component before the \ letter is the registry value name which should be readed like CurrentVersion in the above example. To read the default value just add \ like in HKLM:Software\Mozilla\. It uses the same syntax as a path\file name in windows with the difference that path is the registry key and the file is the registry key value name. If ?version is appended to a filename, WIHU tries to read the file version of this file and store it in corresponding environment variable. Please also take a look at the software section descriptions for more information about using ?fileversion, ?productversion and so on.

Please note this environments variables are only valid within WIHU i.e. while WIHU is running.

Shell Environment Variables

There are special environment variables which will be expanded to corresponding shell folder path. If this is set in environment section WIHU will use this as default shell folder paths for each new user. How to override this per user basis is described below. You may use this variables also if you don't change them in this section. In this case it will be initialized with user default shell folders.

Administrative Tools
CD Burning
Local AppData
Local Settings
My Music
My Pictures
My Video
Start Menu

[Environment.x] Section

Contains user specific environment variables which will be stored persistent in corresponding user profile later. Please note, x is an index of the corresponding user specified in [users] section. This section must reside in same ini file as [users] section.

[Users] Section

Contains user accounts that should be created by WIHU. Please note, x must be an continuous number.

  1. User.x = Will create a new user with specified name and set Password.x
  2. Group.x can be either 0, 1 or 2. 1 means that new user will be added to "Administrators" Group, 0 means "Users" group, 2 will cause WIHU not to move the user to any group or not to change it's group.
  3. Status.x set account status. For valid numbers please take a look at NetUserAdd API in USER_INFO_1 struct at "usri1_flags". Description can be found on Please combine them by adding one or more values. Here is a list of values: (Not all keyword may be used)

UF_SCRIPT = 0x0001
UF_LOCKOUT = 0x0010
UF_USE_DES_KEY_ONLY = 0x200000

Example Usage (will create a normal account where the user can't change it's password):

status.0 = 0x240

  1. Profile.x specifies the users profile path
  2. RoamingProfile.x specifies the roaming profile path
  3. Home.x specifies the path of the home directory for the new user
  4. Comment.x contains a comment to associate with the user account
  5. Script.x specifies the path for the user's logon script file. The script file may be a .CMD file, an .EXE file, or a .BAT file.
  6. Domain.x Domain/Computer where to create the user. If none is specified local system will be used.
  7. Crypted.x = do not change this, it will be generated automatically by calling "WIHU /EncryptIni" and will be removed by "WIHU /DecryptIni". If you remove Crypted.x key, you have to adjust corresponding password.x key otherwise password.x will not be decrypted correctly. If some of the specified users already exists, user data will be updated with this new one specified here.
  8. Default = x/Primary = x specifies the index of the user which should be used as primary user i.e. this which will be used for software installation later.
  9. ShowOnWelcome.x = 1/0 shows/hides the user account on welcome screen (if welcome screen is enabled). Please note: If the specified user account exists and this user account don't has local logon rights, WIHU will add this rights. However if the user is member of a group which has no local logon rights, WIHU will not remove this user from specified group.

Predefined volatile environment variables are following
%ThisUser% will be replaced by the corresponding user name

These variables may be used outside:

Personal = %SystemDrive%\%ThisUser%\Personal
User.0 = New User
Profile.0 = %Personal%\Profile
[Windows System Files Installation Section]
Description.0 = Microsoft DirectX
Command.0 = directx.exe /unpack:%Personal%

In first example, WIHU will create a new user account with name "New User" which profile path will be set to %SystemDrive%/New User/Personal/Profile because %ThisUser% in default %Personal% will be replaced by the corresponding user, in this case "New User". In second example Personal will be replaced by %SystemDrive%/PrimaryUser/Personal, whereby PrimaryUser is this name which was entered in WIHU before. In each software section, %ThisUser% will be the same as %USERNAME%.

To override default shell folder paths which may be specified in [environment] section, please redefine it with it's corresponding index:

User.0 = New User
Personal.0 = %SystemDrive%\My Personal

To set all user defaults, it's allowed to specify keywords without appending an index like
Home = %Personal% or Group = 1 (meaning see above)

Please note: [users] section default keywords like in example above only applies to new user accounts! Existing account will be excluded.To override existing user account settings you have to use indizes like Home.0 = %Personal%

Currently setting any shell folder environment variable without and index isn't allowed here.
Please specify default user shell folder in [environment] section

General section keywords:

  1. command.x specifies the command that should be executed by CreateProcess like command.0="c:\application folder\JavaSun.exe /Silent". Multiple commands can be specified per section, whereby each is appended a continuous number.
  2. description.x describes the component to be installed.
  3. selected.x = (0 or 1) set the checkmark in software component selection list. If this is 1 software will be installed by default. *1
  4. hidden.x = (0 or 1) Hides this command from software selection control. The will never see this item. *1
  5. collapsed.x = (0 or 1) Initially collapse a subtree. *1
  6. locked.x = (0 or 1) Locks this item, i.e. user can't select/unselect this later. *1
  7. disabled.x = (0 or 1) Disable this item (greyed). The user can't change the item later. *1
  8. group.x = (0 or 1) If 1, the software subtree will contain option controls instead of checkboxes. *1
  9. flags.x = italic, bold, underline, striked (one or more of this can be selected) or flags.x = italic:if.true, italic:if.false ... *2
  10. workdir.x = <path> will set the relative directory of the corresponding running command.x process. This will NOT set relative path of current command.x item, only those of the running process which only may be used by this process.
  11. description = x see point 2. This will override [section name]
  12. help.x = helpfile.rtf (Helpfile that will be displayed in software description panel) *1
  13. helptext.x = (RTF) Text, that will be displayed in software description panel*1. This keyword will be overriden by help.x if one is explicitly specified .


command.x = apps\myapp.exe myscript.iss
workdir.x= %inidir%\apps

This will NOT set relative path for apps\myapp.exe, it will even not used by WIHU in any way, expect it will set the current directory for myapp.exe process only. So each relative path that myapp.exe encounter will be relative to "workdir.x".
So myapp.exe would search in %inidir%\apps for myscript.iss

*1 This keyword may also be used without index. Conditionals aren't allowed here. See *2.

Other keywords which could be used to prevent installing outdated or already installed versions are following:

test.x.n = [!]<expression>[?<comparison><operator><data>]

Will test for certain conditions and return TRUE or FALSE which will be evaluated by test.eval.x.

<expression> could be a filename or a registry key as described in [environment] section above. If no ? operator is appended WIHU will test for file/registry key/registry value existence and will return TRUE if this was found. If ! operator is prepended WIHU will invert this result, i.e. TRUE become FALSE and reverse.

<comparison> specifies the comparison operation that should be performed (on files only!). Allowed operations are date, version and size which test for file date, file size or file version respectively. As file (modification) dates, only ISO 8601 date/time format is allowed here like "1993-02-14T13:10:30" or "1993-02-14". To compare only for year and month it is also allowed only to specify something like "1993-02".

Instead version only you may also explicitely specify fileversion or productversion. Please note here, WIHU tries to convert the data into x.x.x.x form whereby x is an integer value. So each non integer value is truncated here. If you need full raw version information you may read it by version.ProductVersion or version.FileVersion. You may also specify other version specific data like version.FileDescription and so on.

<operator> may be !, =, < or > to compare against not equalness, equalness, greater or less respectively.

<data> that should be compared against. This depends on <comparison> operation.

Please note, n must be an continuous number. Gaps between indices are not allowed.

test.eval.x = <n.0>[[|&]<n.1>]... will evaluate logical expressions. Indices may be catenated with operator AND (&) or OR (|). Allowed indices are those n 's specified in test.x.n whereby those indices represent evaluation result of corresponding test.x.n expression.


Example File comparison (Test if version of wmp.dll is greater
Check against ProductVersion.
test.0.0 = %SystemRoot%\System32\wmp.dll?productversion>

Example File Existence Check (Test if wmp.dll exists)
test.0.1 = %SystemRoot%\System32\wmp.dll

Example File Non Existence Check
test.0.2 = !%SystemRoot%\System32\wmp.dll

Example Registry Value Comparison
If Key version does not exists, it returns false
test.0.3 = HKLM:Software\Microsoft\DirectX\Version?>

Example Registry Default Value Comparison
test.0.4 = HKLM:Software\Microsoft\DirectX\?=Test

Example Registry Path Existence Check
test.0.5 = HKLM:Software\Microsoft\DirectX\

Example Registry Key Existence Check
test.0.6 = HKLM:Software\Microsoft\DirectX\Version

Each expression may be negated by prepending ! operator.

test.eval.0 = 0 & 1 | 5 & 3 & 2

Above will return TRUE, if test.x.0 AND test.x.1 are TRUE, OR if test.x.5 AND test.x.3 AND test.x.2 are TRUE.
Remark: Although no braces are supported currently, braces will be implied as follows:

test.eval.0 = ((((0 & 1) | 5) & 3) & 2)

*2: Following keywords may hold special values which should be used with test.eval.x only:

flags.x, selected.x, hidden.x, collapsed.x, locked.x, disabled.x and group.x.

selected.x = if.true will select this item only if previous test.eval.x returns TRUE. selected.x = if.false will select this item only if test.eval.x returns FALSE and so on. If no test.eval.x key is defined, value if.true is the same as 1.

Default keyword values ( will be used if not specified):

selected = 1 (Note this is the selection key for entire section)
hidden.x = 0
description.x = <missing description>
selected.x = 0
collapsed.x = 0
group.x = 0
workdir.x = %WIHU%
disabled.x = 0
locked.x = 0

There can be theoretically up to 65535 items per subtree.; Note: One key "key.a.b.c.d.e.f.g.h...=" must not exceed 255 characters entirely.
To create a subtree just append sublevel indices to commands like:

description.0 = "command 1"
command.0 = ...
description.1 = "command 2"
command.1 = ...
description.0.0 = "sub command 0.0"
command.0.0 = ...
description.0.0.0 = "sub command 0.0.0"
command.0.0.0 = ...
description.0.0.1 = "sub command 0.0.1"
command.0.0.1 = ...

... Will create following sub tree:

"command 1"
    "sub command 0.0"
        "sub command 0.0.0"
        "sub command 0.0.1"
"command 2"           

Remark: If you hides a tree, also each of it's subtrees will be hidden also if not specified explicitly.

If you don't want a subtree/item to be an executable command but just a descriptive header key, set command.x=*. In this case item texts will be bolded.
Note also, if a tree is unchecked none of its subtrees/items will be executed. (This also applys to descriptive keys which contains one or more subitems)

Some words about continuous indizes

If you add /HasGaps switch indizes may have gaps. But reading ini file with this switch may take longer!