Why an installer?

[Leauki]

I work with Windows but am at home a Mac user.

I have always wondered why Windows programs require an installer, especially tools which consist (or could consist) of only one file.

I am using DiffMerge at work on Windows servers, I like it a lot. It's a very handy tool.

However, since the usual way to use it for me is to copy it to a server and then run it, having to copy the installer and run the installer is inconvenient. I am wondering why DiffMerge requires an installer at all.

(I am also in general wondering why pure binaries without installer are so rare in the Windows world. The few that exist seem to be very related to the UNIX world, like Putty.)

[jeffhostetler]

While true that DiffMerge.exe is pretty much self-sufficient, there are several related files that also need to be distributed to known locations. This includes the on-line manual (both .CHM and .PDF), as well as the Windows Explorer Shell Extension .DLL which needs to be installed and registered with the system. We also need to put icons on the desktop and in the start menu. The installer does all of this.

If you don't care about these related files, you could probably copy the .exe from system to system and take care of the assorted details yourself, as needed, but it's probably just easier to use the installer.

As for the bigger question of why Mac software, in general, tends to be cooler/easier to use than Windows, well, I'll leave that to another forum.... :-)

jeff

[Leauki]

While true that DiffMerge.exe is pretty much self-sufficient, there are several related files that also need to be distributed to known locations. This includes the on-line manual (both .CHM and .PDF), as well as the Windows Explorer Shell Extension .DLL which needs to be installed and registered with the system. We also need to put icons on the desktop and in the start menu. The installer does all of this.

Couldn't the binary itself do that?

Microsoft Office on Mac OS X does that. You can copy it from one machine to another (or use the installer, if you feel want). When it runs for the first time (or probably whenever it finds it necessary), it copies fonts etc. to the correct locations.

The binary itself could check if the necessary has been done, and if not, copy the DLL to the right location and register it and copy the manual to wherever it should be, i.e. the binary could contain the installer plus necessary archives.

This would make for a far more userfriendly and convenient setup, especially for a tool that gets copied to servers a lot (during Web application testing in my case).

If you don't care about these related files, you could probably copy the .exe from system to system and take care of the assorted details yourself, as needed, but it's probably just easier to use the installer.

Perhaps... the shell integration is useful, but I don't see why an installer is required to make it work.

As for the bigger question of why Mac software, in general, tends to be cooler/easier to use than Windows, well, I'll leave that to another forum....

I wouldn't say easier in general, just the installer concept is a problem. When I find a cool tool for Mac OS, I just keep that file or bundle around. In Windows, I always have to keep track of the installed version (to use it) and the installer version (to copy it to another machine). That can be annoying (and usually is).

I don't think I have seen a better diff tool on Mac OS (apart from the UNIX diff, which has its own advantages and problems). I have in general found developer tools to be better and more logical in Windows than in Mac OS (or UNIX, ironically I find UNIX easier to use than Windows).

Seems to me that a lot of the reason for an installer is just the Windows philosophy/religion of distributing everything as an installer. I often find Mac users surprised when they learn about "installers" and Windows users surprised when a Mac user simply moves a program around (even across CPU architectures because of the NEXTSTEP bundle system).

The Mac method seems more closery related to the user's view of how things should happen though. In real life you also move the book from one desk to another if you need it somewhere else. You do not look for the book installer and re-install on the new desk.

[jeffhostetler]

Couldn't the binary itself do that?

Sorry, it just doesn't work that way on Windows.

On the Mac, the application bundle (the thing you see in the finder window) is actually a directory that contains all of the necessary files -- the actual executable is hidden about 3 layers down inside. it also contains the various help files and profile settings and etc. Dragging the bundle to your /Applications folder copies the entire application bundle tree into the right place.

On Windows, the executable (the .exe) is just that -- the executable. All of the other related files are independent files. The installer .msi is a glorified zip file that contains all of these files, instructions for where to place them, and the gui script/application that does all of the work. When it is done, you will have a folder in Program Files that contains all of the files that we ship (a lot like what you get on the Mac in a single drag).

I'm not stating a preference here -- or saying that you're wrong or anything -- all I'm saying is that's just the way it is; that's the way the systems work and I have to build packages that work the way each system expects -- regardless of my personal likes/dislikes (and yes, writing a Windows Installer was a pain in the butt).

Hope this helps,
jeff hostetler

PS. Oh, BTW, I forgot to mention in my first reply that we do off a .ZIP file for Windows. There's a link to it on the same page as the .MSI installer.
http://www.sourcegear.com/diffmerge/downloads.html This will just expand to a folder and not do any of the other installer things.

[Leauki]

Sorry, it just doesn't work that way on Windows.

I don't see that. If a ZIP archive can be self-expanding than so can an application create other files, including DLLs, and register them.

On the Mac, the application bundle (the thing you see in the finder window) is actually a directory that contains all of the necessary files -- the actual executable is hidden about 3 layers down inside.

I know. It's the NEXTSTEP bundle system I mentioned above. I believe GNUstep uses it too. However, the example application (any of the Office apps) isn't a bundle but a plain traditional PowerPC PEF executable.

It can still copy fonts to the required directory.

it also contains the various help files and profile settings and etc. Dragging the bundle to your /Applications folder copies the entire application bundle tree into the right place.

And dragging the Microsoft Office folder there does the same. Should be possible with DiffMerge too. You can either put all the files in one folder (and have DiffMerge copy the files that need to be elsewhere to that other location when run for the first time) or you can offer DiffMerge as one binary (and have it create the other necessary files at their locations when run for the first time).

Both scenarios would work under Windows, or not?

On Windows, the executable (the .exe) is just that -- the executable. All of the other related files are independent files. The installer .msi is a glorified zip file that contains all of these files, instructions for where to place them, and the gui script/application that does all of the work. When it is done, you will have a folder in Program Files that contains all of the files that we ship (a lot like what you get on the Mac in a single drag).

I know how the installer works. I still think it's an unnecessary burden.

I'm not stating a preference here -- or saying that you're wrong or anything -- all I'm saying is that's just the way it is; that's the way the systems work and I have to build packages that work the way each system expects -- regardless of my personal likes/dislikes (and yes, writing a Windows Installer was a pain in the butt).

I think it's a Windows philosophy thing. If DiffMerge needs a specific DLL in a system directory and registered, it could simply copy it there when run and register it. Microsoft Word does it with fonts on Mac OS X and it has nothing to do with bundles (because Word is not a bundle).

If DiffMerge needs administrator rights to do so and the installer offers that, it could

a) not install the DLL unless the user starts DiffMerge with admin rights for the first time or

b) start the installer and supply it with an answer file.

There is no technical reason for an installer here and bundles merely make the act looking at the application (one icon instead of one folder) easier.

One folder with a usable DiffMerge in it would be good, but one binary that can create the needed DLL etc. would be even better.

I am not trying to be smart here. I honestly don't understand why this isn't done in the case of small tools. Can an .exe file not contain a DLL and create a copy of it?

If it's difficult to do, maybe Microsoft should include that as a standard feature in Visual Studio (i.e. create a binary containing DLLs that the binary can then create and register when run as an administrator).

[jeffhostetler]

Um, yeah, I suppose that several of the steps you've suggested are possible, but I have to ask if are they ***really*** necessary or even a good idea?

I mean, is running a .MSI installer *really* that much of a burden? You only have to do it once and it takes care of everything and it registers the package with the system so that "Add/Remove Programs" in the Control Panel knows about it and deals with the Vista temporary Privilege Elevation stuff exactly once.

Distributing a self-contained .EXE could probably be done, but would combine three independent activities (unpacking, installing, and the actual diffmerge proper functionality) into one .EXE. These are seriously non-trivial things to be casually lumped together -- we'd have to invest a lot of time to get such a non-standard distribution package working. I'd rather spend that time on improving the diff/merge features and let the unpacking/installing features be handled by a pretty much stock .MSI builder.

One thing you might try is to take the .EXE from one installation (or from the .ZIP distribution) and copy it to the desktop on all of your other systems. (You could also just put the .EXE on a network share.) Then you can just double-click on it and run it directly from the desktop/share. You won't have the on-line help and you won't have the Start Menu items and you won't have shell integration, but you won't have to run the installer on each system.

Hope this helps,
j

[Leauki]

Um, yeah, I suppose that several of the steps you've suggested are possible, but I have to ask if are they ***really*** necessary or even a good idea?

Absolutely. Moving just one file or folder around totally beats keeping track of an installer. For applications it doesn't really matter, but DiffMerge is, for us, a tool that we install on random test servers to compare code drops.

I mean, is running a .MSI installer *really* that much of a burden? You only have to do it once and it takes care of everything and it registers the package with the system so that "Add/Remove Programs" in the Control Panel knows about it and deals with the Vista temporary Privilege Elevation stuff exactly once.

Exactly once per server. I am using DiffMerge on test servers. I have development unit test, integration test, and system test environments, two per release, with four releases pending. All the tools I use I find myself

a) looking for, because knowing that it is installed on a server close to the current one (network-wise) will not help (since the installer might already have been separated from the installed version and erased

and

b) needing on all servers sooner or later.

I never really saw DiffMerge as a static application used on one development machine for good.

On the Mac side of things, knowing that something is installed on another machine also means knowing that it can be copied from there. It's more convenient, especially for small tools.

[jeffhostetler]

One thing you might try is to take the .EXE from one installation (or from the .ZIP distribution) and copy it to the desktop on all of your other systems. (You could also just put the .EXE on a network share.) Then you can just double-click on it and run it directly from the desktop/share....

It sounds like you have a large collection of test servers. Just take the .EXE and pass it around and don't worry about the other parts -or- the installer. The .EXE is statically linked, so you shouldn't have any library issues.

j