An Argument for the Elimination of Setup Programs
Origin Research Fellow White Paper #3
Zachary Booth Simpson
Origin Research Fellow
14 Dec 1998
- Setup programs are an annoying reality with almost every piece of commercial software delivered today. They tend to be clunky to both create and execute. I believe that their time has past; their functionality can be moved into the primary application.
- Why were setup programs created in the first place? Back in the DOS floppy days, where the trend for install programs began, the requirement came from two primary factors, and a variety of lesser ones. The two primary reasons are:
- Quick feedback - It was so slow to execute a program off of the floppy, that one wanted a very small program (often a batch file) which could load quickly and would then copy the real files on to the HD.
- Hardware configuration - applications often loaded drivers at initialize time. Thus, this required that the user stop running the main application in order to change drivers; setup programs provided an external user interface for changing drivers since the main application not change them dynamically.
- These two requirements are, for the most part, now obsolete. So, why are we still using setup programs? Let's analyze the various other things that setup programs do today, some of which are becoming obsolete or have already become so.
Copying / Deleting files
- Select install directory / copy files from shipping media.
- Select/disable optional components to save HD space.
- Setup uninstall keys / perform uninstall.
- Run system hardware profiling to determine initial configuration (such as hardware vs. software rendering, for example).
- Select I/O devices such as joysticks, sound cards, etc.
- Setup icons on "Start Menu".
- Install DirectX and other required OS upgrades in the form of DLLs and drivers.
- Run network diagnostics (detect firewalls, configure proxies, etc.).
- Create/register a character.
- Check/create feature-limited demo keys (usually distributed online).
- Run electronic registration.
- Select language if different languages shipped on same CD (which is rare due to desire to minimize gray market products).
- Setup / Execute optional OEM products such as other games' demos, co-marketed ISPs, browsers, etc.
We should move all functionality of setup programs into the primary application. The advantage of this is simplicity both for the developers and the users.
It should be a goal that our game CDs are placed into the CD drive, auto-run should start the real game, and the customers start playing. The following enumerates what needs to happen to do this following the list of setup features listed above.
Copying / Deleting Files
- Cache files to HD. The usual copying of files should be considered at HD cache, not an install. When the program runs, it simply begins a thread copying the necessary files to a temporary directory (such as \windows\temp). By the time the user has looked at the flashy title screen, the other thread will probably be done with the vital files. (This is currently being addressed by Microsoft, see below). If the thread is not complete, it displays a wait status message.
Don't create save-game directories immediately. Delay the creation of permanent directories (save game files, etc.) until the users actually have something to save. The save game menu should be able to create the directory wherever the user wants it. It should, of course, assume a reasonable default.
- Demand-cache optional components. Few games even include optional installable components anymore since disk space demands have been reduced. However, in the cases where some components can be avoided the solution is again solved by treating the entire file system as a CDàHD cache.
- Uninstall save games / flush cache option in main menu. The main menu should simply contain an option "Clean System" which explains that all save games will be lost and requests verification. There should be nothing special about uninstall, the next time you stick in the CD, it is just like it always is. It may be desirable to allow the users to delete the save games via the uninstall option on the control panel without the CD. In this case, we should just point the uninstall key off to a simple batch file in the save game directory which deletes the files eliminating the need for an additional setup-like user interface.
- Run profiling in game. Most games have already moved profiling and hardware configuration in- game to avoid customers having to re-run setup when they install new hardware. Thus, this is already a mute point.
- Select hardware in-game or not at all. Ideally, the PC would be treated like a console system - there would be no hardware to twiddle. More realistically, the hardware twiddling should be done via the appropriate control panels and hardware selection should be automatic or at least very simple. Like profiling, this too has already moved in-game so again, this is already mostly mute.
- Avoid creating shortcuts on the Start Menu / do it automatically. In most games the CD is required, so simply stick the CD in and start. (For systems which have auto-run disabled, the user can double-click on the CD icon under My Computer). Some people may disagree with this approach, in which case the application should just create the shortcuts automatically the first time it runs in a default place. If the users wish to change the location from default, they can do so easily within the OS GUI.
- Check for necessary drivers at startup. During game load, the game should always check for the correct DX drivers and other required files. If they don't exist, they should be copied and a reboot offered if necessary. No special code is needed after reboot since the check is performed every time.
- Move network diagnostics / configuration in-game. Like most hardware configuration enumerated above, this functionality is already moved in-game in most products. It is usually more convenient to write this in-game anyway since it requires game network protocol code which would annoyingly have to be linked into the setup program if it weren't in-game.
- Create/register character. Ditto 8.
- Check feature limit keys automatically. Again, already in-game in most products.
- Offer electronic registration via the web. The internet is becoming the universal digital communication system. E-reg programs that supported internet-less modem connections should be phased out and replaced with URLs. The main-menu in the game should offer a shortcut to the registration URL at all times (so it can be updated if person wished) which simply launches the web browser to the appropriate page. This has the extra advantage that the sales department can maintain the e-reg system totally independently of the developers since there will never be any code on the client side and it obviates the need for maintenance of backward compatibility on the server side.
- Allow language changes dynamically. If the game has multiple language support on the same CD, the language should be changeable dynamically in-game. This is usually fairly easily done by reloading resources and keeping all language dependent variables in a hash-table. This is good coding practice in general since it keeps these strings out of static data and eases translation. As mentioned above, the desire to reduce gray-market sales usually means that there isn't language selection on the same CD so this may rarely be an issue.
- Provide links to optional software in-game. Games and other systems are usually simply forked in separate processes in most setup programs today. Moving this in-game is trivial.
- Microsoft is currently planning several features of DX8.0 aimed at making games more console-like. Much of their work complements this white paper well. For example:
- They will be providing HD cache areas specifically for games which wish to avoid install.
- They will be implementing I/O device configuration which simplifies mapping. This will probably be similar to mapping proposal agreed to at Origin in 1995. See http://www.mine-control.com/zack/joystick/joystick.html.
- They plan on specifying profile levels and reporting this from the OS at least partially obviating the need for custom system profiling.