Windows 7: Installers. Why?

This thread is just a pondering, not a real technical question. That's why I've put it here. Sorry if it's in the wrong place! New poster here.

Why use installers? A recent experience has made me question the purpose of installers in general. Why not just have big Zips that you unzip into Program Files or wherever you want, and just run all the contained files? Why create registry entries and all that mess with installers?

For example. New game out, Aion. I had major installation problems. Got it installed on an XP system, couldn't get it working on a Vista system. So, I decided what the heck, I'll just copy the whole folder over to my Vista box.



Wouldn't you know, it worked. About a 3 minute copy, no patching, everything was already updated from the other PC. It just plain worked.

Is the purpose of installers just to create Start Menu > Programs shortcuts, and add (apparently unneeded!) registry entries?

This leads me to think, what if I had two hard drives and installed everything to the 2nd hard drive, and Windows was on the 1st. This way when I reformat Windows I don't reinstall all my apps. Seems in theory this would work, but I always scoffed at it working because of missing registry entries, programs not being in Add/Remove Programs or Programs and Features, etc. Stuff like that.

If it would work, why not just do it? Anyone got experience doing this? Experiences with problems, or nothing but good luck from it? I may try it out since I like experimenting with stuff, and plus I have massive installs sometimes (mostly big games!).

Because there is much more going on than simply copying files. The installer sets up folders and files, registry entries, configuration files, environment variables and shortcuts. See here for a detailed article on what installers do.

Good reply swarf. Except that I think the OP's point is that, why is it necessary? He has a valid question. PC programmers are lazy, or more specifically, spoiled. An effective and even highly complex program can be written in assembler, for example, as one self-contained executable, negating the need to create all of the other dependencies you describe. Beyond a simple .ini, the vast majority of programs shouldn't need installers.

I still think they are necessary considering the amount of scripted items they have to perform. Imagine asking the user to extract the files, configure inis, edit the registry, etc.

They simplify the whole process so that even the most novice of users can install an important program in order to get what they want done.

You may call an ini file simple, but to a computer novice they wouldnt have a clue.

^^ Point taken but not initially refuted, either.

With the exception of file associations (a pesky throw-back to the 90's if you ask me), there's not much more a program should need to do to alter a systems' already inherent functionality. DLL's can be placed in the program's folder (negating the need for system32/ write access altogether), not to mention any other dependencies. The whole concept of AppData and the MyDocuments folder that preceeded it was included purely for downward compatibility issues with legacy software. This is the same mid-90's coding that, to this day, *requires* a swapfile or a TMP folder. The point being, it's legacy nonsense and entirely unnecessary.

Steve Gibson at GRC is the best example I can come up with, for the moment, if you consider that his applications of exceedingly powerful, yet none (that I am aware of) require any form of installation. Just think how PCs would run if everything were written in pure assembler? Wow.

An important reason could also be shared libraries, aka DLL's.

In DOS, every program was an island on it's own, using it's own files.
Because of that there could be a large number of duplicate files on the system.

With programs getting bigger and bigger and the need for interoperability, shared libraries were introduced.

Almost any program nowadays uses windows libraries and common files to make use of pieces of the OS.

To make this work, a registry is necessary to tell each program where parts of the OS can be found, and tell the OS where parts of the program are, how the program is set, and what it's properties are.

I think that's the main reason you cannot just dump a program in a folder and let it run. (some little proggies do without registry, but they carry their own dll's)

Greetz

I will say this: installers have been getting very fast in the last few years. I remember 3-4 years ago waiting 30 mins to install programs.

OK, a couple of points here.

1) I have 3 HDs - and I routinely install games (manually) to my second HD - not to have he game after an OS reinstall, but to keep them away from the pesky issues that the permission-protected Program Files tree in Vista and 7 (XP does not protect that folder tree at all - yet another reason why viruses and other malware were able to run amok on XP). It works - and it works well. Even if you have a single HD, if you have a good amount of space, shrink it down and make a separate partition and manually install games onto that partition (I'd recommend well over 40 GB if you game a lot). The difference is staggering - I routinely play games that most people have issues installing in Vista and 7 b/c of this very fact.

2) Using the information I just listed above, you can see why unzipping an app into the PF tree would not work in Vista and 7 - again, b/c of the permissions. Older programs written for 2000 and XP want to have write access to the folder that they are installed in - a big no no in the world of NT 6 (aka Vista and 7). This obviously causes issues, and installers today are written with elevation modules to gain the accepted level of permissions to be able to not only write to the PF tree but also the Windows system folders, the registry, etc - all these are now considered protected areas of the system, and thus need special permissions to be able to perform even the simplest functions in them - writing, editing, etc.

Finally, 3) Installers will also copy pre-requisite files to appropriate locations (uninstaller files to system folders, DLLs to system folders, initialization files to your settings folder (usually now located under your user tree), etc. If you have one big ZIP, again, you need write access to where you want to put it as well as having to make sure that your DLL in the ZIP is not older than one you already have on your HD (something the installer does for you when installing), etc. One very big problem would be if your app is hard coded to read a .DLL from a default location - if you unzip it to a completely different folder, then it doesn't know where to look. If it is accessed using relative paths, then unless your app polls the system to make sure another version is not already loaded into memory, it can make for a massive headache as you have 2 different versions of the DLL being used on the same system simultaneously.

There are other issues as well, but some of the posts after yours also deal with them so I'll answer them there....

Good link

Wrong. a simply .ini would have to be saved in the users tree in order to allow for custom settings on a per user basis - if it is saved with the App itself, then you either have to edit (append) every single users' settings into that file - on a workstation that has 50 users, with 2000 lines of settings strings per user, that would be a large file that needs to be loaded every time. If you have a ZIP file with an app that reads the .ini from the local (relative path) directory that it is installed in, you lose the ability to easily allow for multiple user configurations.

Extraction is actually relatively easy, seeing as XP+ supports ZIP file viewing....

applications that are modeled as Steve's are, using his "Small is beautiful" credo, if you will, are great - but when you think of the fact that the entire OS that you are using is object oriented, modular, and does not load all at once, but loads modules as need, then you begin to realize that it is not *laziness* of coders but rather following the same model. If I need to, say, edit a document, I won't want to run an app that takes 1.4 GB of RAM but can, in one single executable, edit a document, create spreadsheets, check my mail, share files through office interconnectivity, preform desktop publishing, query a database, or even *shudder* draw diagrams. It is all about object oriented programming, and the entire OS is modeled on VB - all these .DLLs, other resource files, etc. are very very different from C programs.

Granted, we could have several large 500 MB programs that can be called from each as needed, but you lose extensibility. Show me one of Gibson's programs that we, as a layman, can extend - add format support, add functions to, etc. The model now is such that it allows extensibility (even if limited) and my conspiracy theory is that this was set up this way as a direct retaliation aimed at Apple for the proprietary nature.

Finally, there is a lot more going on these days with our modern OSs (Visa and 7) then there was back then, and now is the time for a greater need for installers than ever in the past.

Another good way of putting it; however, there remains the inherent problems I noted above for all but the smallest of programs, as squon also points out.

I think the real answer is that ultimately we really don't need installers for much else than file associations, and that is why there are bazillions of portable apps available, even for very complex programs (for example Adobe Premiere Pro CS4 and After Effects.) Interestingly, almost none of them work in Windows 7! For this reason I have started using XP and Vista more often because I can carry my setting in the portable apps from machine to machine.

Just for the record, it usually works just fine in Vista for me, but not in 7. Anyone know why?