Dear Ron,

How can I make my programs start programmatically on Windows startup? Do I need to use API calls or modify the registry? How do I do that with code so that my programs start automatically whenever Windows starts up?

Good day,

Abid

Dear Abid,

There are a number of techniques that allow a program to be launched automatically by Windows at startup. Some of these (at least in my opinion) are quite pernicious. You can, for instance, use the TextStream object in the FileSystemObject object model to write the path and name of the program to autoexec.bat. This is, though, a technique inherited from the days of DOS; many users, when they decide that they don't want the program loaded at startup, are not likely to know that they should check their autoexec.bat file. An even worse alternative is using the initialization file functions in the Win32 API to write to the Load= or Run= lines of Win.ini. In my experience, applications started in this manner often tend to behave erratically.

The two best methods for automatically launching a program at startup are to use the registry or the system's Startup folder. Which method you choose depends on how easy you want to make it for the user to remove the program if he or she decides that it shouldn't run at system startup. Using the Startup folder gives the user more control; to prevent the program from running at startup, the user just has to remove its shortcut from the folder. Using the registry makes it less accessible; the user will have to be familiar with the structure of the registry and will have to know how to use an editing tool like RegEdit in order to prevent the application from running at startup.

If you decide that you want to use the registry, you need to make two major decisions. First, you must select the registry key in which you will write the startup information. This decision depends in large part on the character of your application and on why you want to launch it at startup. Second, you need to select a method for writing to the registry. Let's look at these two issues.

You can run an application automatically by writing a value entry (a complete name/value pair) to any of the following registry keys (I'll use abbreviations here for the top-level keys):

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Launches a program automatically when a particular user logs in. This key is used when you always want to launch a program when a particular user is using a system.

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Launches a program the next time the user logs in and removes its value entry from the registry. This key is typically used by installation programs.

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Launches a program automatically at system startup. This key is used when you always want to launch a program on a particular system.

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

Launches a program the next time the system starts and removes its value entry from the registry. This key is typically used by installation programs.

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices

Launches a service (a standard NT service or a background process) automatically at startup. An example of a service is a Web server such as Microsoft Internet Information Server.

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

Launches a service (a standard NT service or a background process) the next time the system is started, then removes its value entry from the registry.

In each case, you load your application by writing a name/value pair to the appropriate key. The key's name is arbitrary, as long as it is unique among the value entries belonging to that key. The entry's value is the complete path and filename of the file to be run.

There are also two additional keys, HKLM\Software\Microsoft\Windows\CurrentVersion\RunEx and HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx, that allow more fine-grained control over the applications and components that are loaded, and that therefore use additional registry value entries. These are documented in Microsoft KnowledgeBase article Q232509, "Syntax and Flags Used for the RunOnceEx and RunEx Keys."

Once you've selected the key to use, you have to select a method of writing to the registry. The most commonly used method is to call the registry functions in the Win32 API. If you're interested, these are carefully documented in my now out-of-print book, Inside the Windows 95 Registry. A more accessible method (at least in my opinion) is to access the registry using the Windows Script Host object model.

Ordinarily, you may not associate Windows Script Host with Visual Basic; after all, Windows Script Host is designed primarily to be invoked from small script files written in languages like VBScript or JScript. However, Windows Script Host exposes an object model, and all but the top-level Windows Script Host object (called WScript) can be instantiated from a Visual Basic program. To early bind to Windows Script Host, you just need to add a reference to Windows Script Host Object Model to your project.

Within the Windows Script Host object model, you want to call the Shell object's RegWrite method. Its syntax is:

oShell.RegWrite strName, Value [,strType]

where oShell is a reference to a WSH Shell object and the parameters are as follows:

strName

The complete registry path to the value entry to be written. If strName ends in a backslash, the method writes to the key's default value; otherwise, it writes a named value indicated by the substring that follows the last backslash. The three most commonly used top-level keys can be abbreviated as HKCR, HKCU, and HKLM.

Value

The value to be written to the registry. To run an application on startup, this should be the complete path and filename of the application to be launched.

strType

The datatype of Value. The default is REG_SZ (a null-terminated string), though REG_EXPAND_SZ (a string with embedded system macros), REG_DWORD (a long integer), and REG_BINARY (binary data) are also possible.

The following code from our sample VB6 application uses the HKEY_LOCAL_MACHINE Run key to automatically load an application named TestStartup whenever Windows starts up:

Click here for code example.

If we decide not to use the registry and instead to create a shortcut to our application in the system Startup folder, we need to know the physical location of the folder, and we need to decide how we want to create the shortcut. Here again, we can choose from the Win32 API or the Windows Script Host object model. The WSH Shell object allows us to determine the physical path of the Startup folder and to create a shortcut. The Shortcut object returned by the Shell object's CreateShortcut method alows us to set one required property (the physical file to which the shortcut is linked) and to save the file. The code from our sample VB6 application that creates a link in the system StartUp folder is:

Click here for code example.

If you're using VB.NET and want to configure the system to load an application automatically at startup, you can use the registry classes in the Microsoft.Win32 namespace. The code from our sample VB.NET application that uses the registry to load TestStartup.exe automatically whenever a particular user logs in is:

Click here for code example.

Note that in either case, a reference to a Window object is obtained from the Document object for which the window serves as a container.

One final comment on windows and ProgIDs. Since you can instantiate a Word Window object using the fully qualified string Word.Window, you might think that this is Word window object's programmatic identifier. However, it is not. ProgIDs are defined in the registry as direct subkeys of HKEY_CLASSES_ROOT. If you search the registry for a subkey named Word.Windows, you won't find one. The string simply specifies the particular type library (i.e., Word) in which a particular class (i.e., Window) is defined.

Download the code examples for VB6 and VB.NET.

--Ron

Return to: Ron's VB Forum