Guides

The install order that works for most of the library, and the handful of problems that account for nearly every report of a failed install.

Before you start

Read the install notes on the listing first. They are written per entry rather than copied across the library, because a small utility and a forty gigabyte collection do not install the same way. Most reports of a failed install come from skipping a step that was written down on the page.

Check the requirements table too. Disk space is the one people misjudge most often, since several of the larger packages need considerably more free space during install than the finished application occupies afterwards.

The install order that works

1. Remove any earlier version of the same product first, using the maker's own removal tool where one exists.
2. Disconnect the machine from the network, and leave it disconnected until the install has finished and the application has been opened once.
3. Extract the package to a short path near the root of a drive rather than deep inside a user folder.
4. Run the setup file as administrator.
5. Apply whatever licensing step the listing describes, before the first launch rather than after it.
6. Open the application once, close it, and only then reconnect the machine.

That order is the same across most of the library, and the per entry notes only differ where a product genuinely needs something else.

Short paths and why they matter

Windows has a path length limit that installers routinely run into. A package extracted to a downloads folder inside a user profile, with the archive name added as a folder, can push internal paths past that limit and produce failures that look like corruption but are nothing of the kind. Extracting to a folder such as C:\Setup avoids the entire class of problem, and costs nothing.

Security software during install

Installers that write into protected locations, register components and modify licensing state look exactly like the behaviour security software is built to stop. Expect flags, and expect some packages to be quarantined mid install, which leaves a half finished installation that fails in confusing ways later.

Pausing real time protection for the length of an install and resuming it afterwards is the usual approach. If you are not comfortable doing that on a particular machine, the honest answer is not to install that package on that machine.

Very large packages

Several entries in the library run to tens of gigabytes. For those, three things matter. Check free space before you begin rather than halfway through. Extract to a drive with room for both the archive and the extracted contents at the same time. And where the installer offers a component selection, take it, because a full install of everything usually wastes hours and a great deal of disk space on components that will never be opened.

When something goes wrong

• Install stalls near the end. Usually normal on large packages. Give it several minutes before deciding it has hung.
• Install fails immediately. Almost always a leftover previous version. Remove it properly and try again.
• Application starts then closes. The licensing step was applied after the first launch instead of before it. Remove, reinstall, follow the order.
• Startup takes a minute or more. A licensing component trying to reach the network and timing out. The per entry notes say when to expect this.
• Missing components on first launch. The package was extracted from too deep a path and part of it did not unpack. Re-extract to a short path.

If none of that helps, the contact page takes reports. Include the entry name and the version, and describe where in the order it failed rather than only that it failed.