While not often covered in computer science or software engineering courses, the process of getting a program to work on a given computer is often nontrivial. In the early days of PCs, installation generally involved simply copying the main program file and any needed settings files to a disk directory and possibly setting up the appropriate driver for the user’s printer. (A cryptic user interface sometimes made the latter procedure a frequent occasion for technical sup-port calls.) Users generally did not have to make many choices about what components to install or where to put them. On the other hand, installation programs sometimes made changes to a user’s system without notification or the ability to “back out.”
The ascension of Microsoft Windows to dominance as a PC operating system improved the installation process in several ways. Since the operating system and device drivers written by hardware vendors took over responsibility for installing and configuring printers and other devices, users generally didn’t have to worry about configuring programs to work with specific hardware. Particularly with Windows 95 and later versions, a standard “installation kit” allows software developers to provide a familiar, step-by-step installation procedure to guide users. Generally, installation consists of an introductory screen, legal agreement, and the opportunity to choose a hard drive folder for the program. A moving “progress bar” then shows the files being copied from the installation CD to the hard drive. A “readme” file giving important considerations for using the program is usually provided. Increasingly, software registration is done by launching the user’s Web browser and directing it to the vendor’s Web site where a form is presented.
The installation of drivers accompanying new hardware such as a printer or scanner has been simplified even more through the “Plug and Play” feature in modern versions of Windows. This allows the system to automatically detect the presence of a new device and either install the driver automatically or prompt the user to insert a disk or CD (see plug and play).
Installation becomes a much more complicated matter when an enterprise has to install from tens to hundreds or thousands of copies of a program on employees’ PCs. While small businesses may simply buy consumer-pack-aged software and install one copy on each PC, large busi-nesses generally obtain a site license allowing a certain number of installations (or in some cases, unlimited on-site installations). Organizations must monitor the number of installations of a particular program package to ensure that licensing agreements are not violated while trying to use available software assets as efficiently as possible. (This is sometimes called software asset management or SAM.)
An automated installation script can be used to install a copy of the same software on each PC on the company’s network—or a utility can be used to copy an exact hard disk image, including fully configured operating system and applications, to each PC. Alternatively, it is possible to buy networked versions of some programs. In this case the application actually runs on a server and is accessed from (but not copied to) each user’s PC. This technique has also been adopted to provide consumers with an alterna-tive to stand-alone installation (see application service provider).
Installation is only the first part of the story, of course. Most significant programs will experience a steady flow of minor version updates as well as security patches. For individual users, setting the program to update automati-cally (if possible) or periodically checking for updates may be sufficient. For organizations, the task of making sure all the deployed copies of the software are up to date can be nontrivial, although tools such as Microsoft System Center can help. (Many Linux distributions such as Ubuntu can automatically retrieve all updates for installed packages.)
Linux and UNIX systems have also evolved more sophis-ticated installation systems in order to keep up with today’s more complex applications and distributions. One common solution used by Red Hat and other Linux vendors is a “package” system where the user selects programs and fea-tures and the system identifies the components (packages) that must be installed to enable them.
No comments:
Post a Comment