Working with the Windows Registry
The Windows Registry is defined by Microsoft as:
The registry is a hierarchical database that stores the values of variables in Windows and the applications and services that run on Windows.
The operating system and other programs also use the registry to store data about users and about the current configuration of the system and
its components. Because the registry is available whenever the system is running, programs that start and stop can keep persistent data in the registry.
In other words, almost all Windows and programs settings are maintained in the Windows Registry and
therefore working with the Windows Registry is essential in all scripting.
In this article, we will go through
how to interact with the Windows Registry through FastTrack Scripting Host.
Please refer to the official Microsoft documentation
on the Windows Registry for general information on the registry structure.
Read and writing values
In most case, interacting with the Registry is simply reading and writing values. Reading from the Registry is done
with the RegistryValue function and writing to the registry is done with the WriteRegistry command.
Let us look at writing to the Registry first:
This example is from the General how to examples page
, where the
information about the user is set in the Registry for Microsoft Office 2007/2010. If this was put
in a logon script, it wouldn't matter if the user edited the initials or full name in Microsoft Office,
because it will simply be set at every logon. Often the information is wrong to begin with and if
information is changed in the Active Directory, this will automatically be enforced in Microsoft Office.
You may have noticed that the hive name in the example was HKCU. Generally speaking, FastTrack Scripting Host supports
abbreviated hive names, which is a proprietary naming. It is up to you, if you prefer HKCU over HKEY_CURRENT_USER
and HKLM over HKEY_LOCAL_MACHINE and so forth. All examples on this website use the abbreviated versions, because
it is the opinion of FastTrack Software that full names have no value in itself and thus just takes up space.
Reading values from the Registry is just as easy as writing values using the RegistryValue function.
The script below is an advanced script from the SmartDock
the custom value named "LastBackup" is kept in the Registry to store when the last SyncDir backup
was performed. Note how in the second line, it is checked that the Registry key that holds the value exists,
because if it doesn't, the SyncDir backup has never run.
If Portable And Alive AcmeProxy Then
If Not RegistryKeyExists HKCU\Software\Acme
If Ask "You never backed up your
documents.[Return][Return]Would you like to do this now?","Backup
Notice","Harddrive" Then DoBackup
If [RegistryValue HKCU\Software\Acme
Corporation\LastBackup]<[SubtractDays 3] Then
If Ask "You
have not backed up your documents for over 2 days.[Return][Return]Would
you like to do this now?",_
Notice","Harddrive" Then DoBackup
32-bit and 64-bit
One of the major pain points to most scripters is the fact that writing to the 32-bit and
64-bit Registry on a 64-bit machine are completely different. If you install a 32-bit
application on a 64-bit machine, it is not stored in the "normal" 64-bit registry, but in
a separate hive and emulated for 32-bit applications. This means that you would normally need two
different scripts, one for running on 32-bit and one for 64-bit. FastTrack Scripting Host
handles this differently. All Registry and Path functionality have two versions.
One that is postfixed with "x86" and one that is not. What is great about that is that on
a 32-bit machine, the x86 version behaves the same as the one without
the x86 postfix, but on a 64-bit machine, they behave differently. And the reason why this is
great is that you never need two versions of your scripts.
Said in another way, if you need to extract a Registry value of an application that is always 32-bit
(meaning installed in the x86 version of Program Files on 64-bit),
you can just use the RegistryValuex86 function and you can ignore the fact that your script may run on a 32-bit
or 64-bit machine. This same logic applies to path functions, as shown here
Microsoft Office does exist in both 32-bit and 64-bit versions. If you install the version
that matches the operating system bits, the example further up will work on all operating system versions.
If you for some reason always install a 32-bit version on both 32-bit and 64-bit machines,
the modified script below will work for the 32-bit version, regardless of the operating
For other Registry functionality, please look under
"Registry" in the Script Editor's Engine Browser, where you will find functionality for all other operations
like creating keys, deleting keys and values and looping through keys and values.