jason said:
I always prefer no-install programs, but after learning a few things the
hard way, I've generally not had problems with programs that do
install...except ocassionally, and I've discovered workarounds...Test-Run,
Total Uninstall, backing up my system files, etc. I was wondering what
problems you and omega have had that make you not even want to install
"light" programs ("light" on the system and registry) that just so happen
to have installers. Yeah, I know, it's a pain having to shut down all
running processes beforehand...and I'm never able to get my Internet
connection to work afterwards...grrr...but aside from that, what are the
issues? Or is it just that you don't want to take ANY risk when it comes
to your system files or the registry? I can understand that, but why avoid
an "occasional" program that just happens to install?
My answer might vary from Mike's... I do run installers. Constantly. My
issue is that I dislike them intensely.
I don't shut down processes for an install - so that part is not an
inconvenience. The type of exception might be for something legit, such
as a MSFT update, or a driver. After that, no. A random program installer
is not supposed to be replacing the files I have in use. My system files,
and standard runtimes, are up to date; any changes they might wish to make
will be in the way of error and wrong version.
Nor do I follow that other commandment, about having to reboot. That message
usually comes up because of writes to wininit.ini, or sometimes to an entry
to the runonce reg key. Those writes, if they're to involve commands to have
standard libraries get overwritten, then I'd want to read the wininit.ini
file myself, or same with runonce key. Not blindly reboot.
Most often the writes to the wininit.ini are extremely trivial. The deletion
of temporary files. After an install, after an aborted install, or after
running an installer's uninstall command. Typical entry, pulled just now
from a line in my wininit.ini: "nul=d:\ztmp\xx\_inst1.exe." Cleanup after
an installer's temp files. There is no reason for me to reboot for that
kind of thing.
Btw, you'll have noticed that any entry to the winini.ini, no matter that
it is usually trivial like the tmp file cleanup,is what causes that
automatic message during reboot, from winini.exe, "Please wait while
setup completes...."
Now, if an installer tells me that I need to reboot before the program is
fully ready to use, that's different. I don't worry about trying to figure
out how true the statement is, and usually simply wait to run it until the
time comes that I have rebooted.
One other note, back about the temp files created by an installer. The
longtime major brand, InstallShield, it is rather broken. First, notice
that any time you run it, it leaves resident a couple of its temporarily
generated execs. And the other broken part: If, during a single Windows
session, you've done different installations that all used InstallShield,
you'll often come up with a conflict. Due to that installer being too
dumb to use unique names in the temp directory, for each of those program
installs.
So, to deal with its broken behaviors, you have to do some extra work. Use
a process manager to shut down its invisible windows, those temporary execs
that it leaves running. And next, manually clean up entries in the temp
directory, to be able to run another install, since it wants to generate
out the same names. All this is finally moot for me, having now an unpacker
for that product; but I bring it up as an example of the incompetence you
come across with installers.
Registry entries. There are two sets of registry entries. Those generated
by an installer. And those generated independently from the installer, by
running the executable. If there is an installer, it means that I have to
record both, not one. I take a quick glance at what the installer wrote,
see if there is anything there that I think at all possible the program
can't generate itself, and save it as a .reg to the program's directory,
just in case. (Very rare I need it, but occasionally there is an isolated
entry I do need, such as language choice, and install dir, values written
into hklm\software.)
Then I kill off what the installer did. It tends to be a consistent pattern,
of garbage that I don't want. Vanity about using the app paths key. An entry
into the uninstall section of the registry (often pointing to uninstall.exe,
which, duh, I can remember on my own). New filetypes keys. Taking over an
existing association. Putting itself in a startup reg key.
I also always kill off those twenty .lnks that installers generate. Some
ask your permission about adding one to extra places, like desktop, or the
quicklaunch toolbar, but most give you no option about doing a dump into
your startmenu.
Finally, installer done, its attempted reg writes nulled, I run the program,
and log that. That gives me the information I need. To know what affects
its settings and behavior. And to be able to remove its registry entries
at a later point in time. This second log, the real one, makes it portable.
I can transfer that information to another system, together with the
program.
There is rarely reason to keep information about what an installer did,
if I clean up after that installer. I only want information about the reg
entries the program wrote. Then I can transfer or delete those, from
whichever machine I use the program.
An installer writing files to the system directory. This is the big, primary
area of my annoyance. If you have a no-install program, then you are free
from that concern. Most that might occur with a no-install program is
something like an .ini to the windir (ok, also can happen the annoying
folder under the "application data" path, but that one is fortunately
not too common).
In contrast. If you have some cryptic setup.exe sitting there, as the only
thing you can see, then you have no idea at all...what plans lurk within.
It takes only seconds to record a before and after snapshot of my registry.
To remove entries is fast enough. For a really bad installer, it is also not
too huge a deal to revert entirely to a previous state of the registry.
But files to the system directory? First, logging that, it takes longer.
Then there is the involved matter of cleaning up.
To move files out of there, those the installer put there and which should
have gone to the program's own directory, that is not instant, dropping the
filenames to the find: dialog, and so on.
To deal with overwrites to your shared system files? Now, that right there
is the bad-case scenario, and the one that particularly makes all of those
secretive setup.exes, as a tribe, a matter always for suspicion and caution.
Thus, before you run any of them, you have to make sure to have your system
files backed up, and that you have to have a way of tracking (pref with
version records) any system directory changes that they hit you with.
When they do commit that crime, you might spend time to analyze whether it
was reasonable, or wrong. If the latter, then you're best off reverting to
your previous registy. This total revert, since the value changes, with the
CLSIDs and so on, that can be pretty involved, not at all handled easily by
normal recordings. Then, you have to restore the correct system files from
backup. Generally, you have to go through the work of setting that up to
happen when Windows is not loaded.
All this means stopping everything you were doing, immediately. Expending a
lot of time and attention, for the work of undoing the obnoxious installer's
damage.
My main strategy is use of a temporary partition, where I do a big group
of those installers, as a project together. It's still extra work, but
I don't have to clean up afterwards, nor deal individually with their
damages.
Yet, significantly, what that means is that those installer-distributed
programs will sit in my download directory for a delayed length of time
(days, months, sometimes years), having to wait until I'm ready to boot
to a temp partition in order to spend the time dealing with them. Keep in
mind, all this work and hassle about the installers, it's before we can
even achieve the most small objective. That is, it's the work required to
be able to even take a glance at a program, a quick run, enough to find out
whether it looks to be a program we might want to keep, or one to do away
with.
Wholly different is the no-install program. Right away you get to see what
it does. None of the worries, about an installer suddenly interrupting the
various tasks you were in the middle of, because its damage made you stop
everything, reboot, revert to a previous registry, restore files from
backup, etc. None of the time-consuming cleanup after an installer.
The no-install program, you can look at it immediately. Nothing long, and
sneaky, and time-consuming, as with installers, to bring it up. A fast
download, then a click. Ready to go.
