So, two fold post. Killing two birds with one stone is always a great thing.


First off, I have noticed a lot of software these days has gotten into the habit of skipping some of the most basic steps during install. Namely, asking you where YOU want the program to exist. I can't believe the number of programs that install to where THEY decide, or rather, where some programmer decided they should go. The install of windows I am on is only a few days old, and looking at the Program Files folder on the C drive,... Adobe, AMD, GIGABYTE, Google, Intel, Microsoft, Microsoft, Microsoft,... etc. All of this software installed, all easily could have lived anywhere on any drive, (Or even other computers for that matter. This is the modern age.) and yet not one of them was installed there by my choice.

I don't really remember things like this being as bad in the past. It was standard practice to type/click "Setup.exe", blow through a few warnings/prompts, and somewhere along the line would be a friendly little text box or something waiting for you to tell you were all these files were going. Sometimes they expected you to be so helpful to the software that it wouldn't even provide a default path!

Does anyone have any good reason why so many programs these days Demand the Right to exist on your C: drive?


And to kill the second bird, and the whole reason why I'm noticing this. I will admit to not being the greatest administrator out there, but I only let myself be in charge of my personal computers and a few family systems. (Ok, and one weekend with a super-computer. It only took them a week or two to get things back up again, but it wasn't my fault someone couldn't read their own interface design documents.)

So I'm currently in the process of settling in after a major computer upgrade. One of the key upgrades was going with a SSD for the system drive, but due to budget limits I went with a 50 GB drive with the plan of limiting it to Windows and a bit of "Work Space". All programs and such that had no business being on C: would exist on one of the many other drives I have, but most likely D or G. And by programs that had no business being on C, I mean every last one of them! In theory it was simple, just don't install to C: and the world is golden.

However, as I've already said, many installers assume they are smarter than you, or that your hard drive is a digital bag of holding or something, and don't bother with the notion that another, possibly better, lettered volume exists in the universe, and happily install themselves anyway. Most aren't that bad. After all who can't spare a few KB to a MB or two? But either way it adds up, and its annoying.

I've poked around online, and while not as robust and full featured as symbolic linking in a unix like environment, the incarnation of symlinks that works under Windows 7 appear to meet my requirements nicely. That is, put a friendly little sign at C:/Program Files, and C:/Program Files (x86) that says "Data, That'away!" and happily sends all calls to "C:/Programs Files/SomeStupidTool" to "D:/HahaThisIsDDriveAndYouDontKnowIt/SomeStuipdTool"

In theory this should be simple. Copy data out of the two program folders, plop it in two new folders on another drive to serve as their respective new storage homes, delete the two folders from C, create the symlinked folders with the proper names, and let any other annoying tool install itself to the "C" drive if it wants too, and I go back to not worrying about default install locations.


But there is a catch. I can't delete, move, rename, or do anything to Program Files or Program Files (x86). A little more googling suggests ways of changing premissions to strip these folders of those protections, but they all seem to be lacking the one key detail that I really want,... Putting those protections back when I'm done fiddling with them.


So, advice? Suggestions? Better Google-fu? Anyone have spare torches, pitchforks, and a list of addresses of programmers who write installers that only install to C Drive?
(Any idea of when "Windows We Finally Accepted Unix Had the Right Idea" Edition comes out?)

I have no solutions for you, but I wanted to let you know that I'm glad you ran into these problems, because I would no doubt run into the same problems in the next couple months if I make a new computer.

I've poked around online, and while not as robust and full featured as symbolic linking in a unix like environment, the incarnation of symlinks that works under Windows 7 appear to meet my requirements nicely. That is, put a friendly little sign at C:/Program Files, and C:/Program Files (x86) that says "Data, That'away!" and happily sends all calls to "C:/Programs Files/SomeStupidTool" to "D:/HahaThisIsDDriveAndYouDontKnowIt/SomeStuipdTool"

In theory this should be simple. Copy data out of the two program folders, plop it in two new folders on another drive to serve as their respective new storage homes, delete the two folders from C, create the symlinked folders with the proper names, and let any other annoying tool install itself to the "C" drive if it wants too, and I go back to not worrying about default install locations.

This sounds like the best idea. Though, I'd mirror the directory structure such that C:\"Program Files"\SomeStupidTool links to D:\"Program Files"\SomeStupidTool. (I'd also recommend getting LinkShellExtension to make links from the explorer context menu!)

But there is a catch. I can't delete, move, rename, or do anything to Program Files or Program Files (x86). A little more googling suggests ways of changing premissions to strip these folders of those protections, but they all seem to be lacking the one key detail that I really want,... Putting those protections back when I'm done fiddling with them.
[/quote]

At most, you will only need to change permissions on a few folders inside Program Files... If you can obtain elevated privileges, then you can edit the security tab such that regular users have access read/write to specific folders.

You should be able to do what you want to do from the Windows installation media. A friend did it using that at least (though he changed the C:\Users to point to another disk).

The question you should ask before "why are there so many bad installers" is why do we need installers at all. The answer is because the people who made the key decisions 25 years ago were terribly shortsighted, but as long as it kind of works, nobody sees a reason to change anything. Plus, it is terribly bad luck to tell your software developers that what you told them to do for two decades was wrong, and it would be entirely out of the scope if software that is 15-20 years old stopped working at some point.
Having a central point of failure and central point of congestion (Windows registry) and not explicitly versioned shared objects which are overwritten with every program install were two of the most stupid design decisions in the history of computing, if you ask me. 3/4 of all end user problems during the last 2 decades came from these two things.

About Google and Adobe etc. installing their crap just where you want (and installing what they want, too, without asking), this is easily answered: There is a massive misunderstanding from your side. You believe because you paid money for the computer, you are the owner. That's of course fundamentally wrong.
Google, Adobe, and Gigabyte own your computer, and as a user you are too stupid to decide what's good for you anyway. Therefore, they not only have every right of installing programs where they want, and secretly installing services that run at startup and send data over the internet, it is even their civil duty to protect you from yourself.

As a solution to your problem, I recommend junctions (you can also mount drives directly in folders, but junctions are nicer, more flexible, and work on more systems). Over shortcuts, junctions have the advantage of being transparent and undetectable for programs in normal operation (they could detect them, but practically no program does). Junctions are a feature of NTFS that was secretly available since Windows 2000, although no tool of creating them was shipped prior to Vista. However, you can download Sysinternals Junction from Microsoft, which does just what you need.
Note that a junction works much more like a (possibly cross-drive) hardlink under Unix than like a traditional Windows shortcut, so you will want to use a little care with them (Deleting a folder in Explorer, as you know, first deletes all files inside it and then removes the folder. But a junction does not merely point at another folder, it basically is the original folder, so naively deleting a junction with Explorer deletes the original files which the junction points at!).

Am I not right in thinking that as of Windows 7 - microsoft is now actively encouraging programmers to install applications to the Program Files folder? I believe only applications installed in Program Files can access or modify resources within their own folder, if they are installed to, say, C:\MyApp then the MyApp folder would be read only, and the user would receive a permission prompt if the application decides to write to this folder.

The solution is therefore to move the location of the Program Files and Users folders, thusly: http://tuts4tech.net/2009/08/05/windows-7-move-the-users-and-program-files-directories-to-a-different-partition/


As Samoth points out - why do we have installers at all (or more exactly - why must they ask us questions at all). I'm a big fan of Joel Spolsky's blog, and one of the things he talks about is that programmers should make the decision, and not ask the user unnecessary questions. 99.9% of users do not care where the application installs to - so why ask every user, just for the 0.1% that do want to be different? A good installer should just install the application, without hassling the user.

I used to work for a company producing software for oil rigs. All our software came with a wise script installer, containing the usual wizard - confirm you want to install - accept license - select location - confirm install. I then pointed out to them that our software was going to be installed by our own engineers, and that if it was installed anywhere but the default location, it wouldn't work. 3 of the 4 screens were therefore completely irrelevant, and were only ever added because that is the standard way of doing things.

No one had ever bothered to sit down and think about it, but instead just accepted the norm. You will find this a lot, particularly in IT. The companies that really stand out, are the ones that break from this norm and actually think about what they are doing, Apple is a great example of this.

The single correct way to install software in my opinion would be to not install it at all. Installing in this case would mean to copy the folder containing the program from the CDROM to some location on your harddisk or unpacking a zip file that you have downloaded.

Shared libraries are in the same folder as the executable from where the OS will load them. Only libraries that are not found there (e.g. the system-internal libraries) are loaded from the system folder. ---> every program has the correct versions of all shared libraries, no tampering with operating system files needed.

If a user wants to take advantage of the "shared" part of shared library, he can copy the shared libraries to the system folder, saving disk space and memory pages. Nobody except the user the file manager runs under has write access to this location. If you will, this could be done as "extended install process" by telling the file manager to do these moves if an "automatic install" is really wanted, but still it would need to go through the "special authority", you cannot just copy any file to the system.

Each distinct major version of each shared library must have a unique (maybe monotonously incrementing) serial number in its filename and bears a signature with a revision number. Shared objects with the same serial number in their name must be binary compatible to earlier versions with the same serial number in the filename. Thus, any [font="Courier New"]foo.1234.dll[/font] is compatible with any previous [font="Courier New"]foo.1234.dll[/font], but not necessarily with [font="Courier New"]foo.1235.dll[/font] or any other library.
The file manager verifies the signature of each object copied to the system folder. If an object with the same name exists, it will be overwritten only if the signature of the new object comes from the same institution and has a newer release number.

---> all DLLs have guarantee integrity and binary compatibility, but no complex trust chain or "official signatures" are strictly necessary (though possible).
The programmer of Foo-Office might supply [font="Courier New"]foo-library[/font] which could be shared with Foo-Paint. He can use his own (self-made) signature key for that. Since no other program loads this library, the worst thing to happen in case Foo has malicious intent would be a malicious library in the system that is only used by Foo programs.
The system will not overwrite any other object because the signature owners won't work out. It will not overwrite Foo's objects with a malicious third party's libraries either. Foo can also provide a copy of the CRT library, but cannot replace the system object with a tampered one, since again the comparison wouldn't work out. If Foo maliciously copies a (not yet existent) [font="Courier New"]bar-lib[/font] to the system hoping to compromise a future Bar program that the user might install, this will apparently work. However, he will still not be successful. By default, the Bar program uses the libraries in its program folder, and if the user copies these to the system, the signature check will fail (since Bar will have used his own signature key). Many different programs can have many non-compatible versions of a library at the same time, upgrades/fixes on a library automatically work for all programs using the same version.

Settings are stored similarly to how it's done on Unix-like systems, in a file with the program's name inside a sub-directory of the per-user home directory. If a program needs "global" settings, they go into the "all users" config dir. The system has its own config somewhere (e.g. for startup files etc.), which is owned by the "system user".
---> no registry needed, no tampering with the registry needed, and indeed no easy tampering possible, no installer needed.

Well, enough dreaming... we'll probably never see something as easy as that.

About Google and Adobe etc. installing their crap just where you want (and installing what they want, too, without asking), this is easily answered: There is a massive misunderstanding from your side. You believe because you paid money for the computer, you are the owner. That's of course fundamentally wrong.
Google, Adobe, and Gigabyte own your computer, and as a user you are too stupid to decide what's good for you anyway. Therefore, they not only have every right of installing programs where they want, and secretly installing services that run at startup and send data over the internet, it is even their civil duty to protect you from yourself.

Sarcasm aside, matter of fact is that install location is an irrelevant technical detail that will overwhelm 99% of all non-technical users. It is also a way to phenomenally screw up an install when you don't know what you're doing (keep in mind that we technically literate users are a small minority). Why increase workload on support lines and make your main user base confused/unhappy just to please maybe 0.1% of power users ? Not asking for install location makes indeed perfect sense for an installer. You wouldn't believe how many people try to install software on a DVD drive or USB key without even realizing it.

What doesn't make perfect sense is the whole installer framework on OS side. It should not be the reponsability of the installer to decide on install location. All that should be handled transparently by the OS, configurable through policies for power users and/or administrators.

As a sidenote, this problem is much much worse on Linux. It is almost guaranteed (and even accepted practice) that even the smallest piece of software can distribute its files to more or less fixed locations all around your file system as soon as you do a make install. OSX on the other hand, takes a completely opposite approach. An application is a sealed and self contained package that can be moved around at will.

Am I not right in thinking that as of Windows 7 - microsoft is now actively encouraging programmers to install applications to the Program Files folder? I believe only applications installed in Program Files can access or modify resources within their own folder, if they are installed to, say, C:\MyApp then the MyApp folder would be read only, and the user would receive a permission prompt if the application decides to write to this folder.

MS has indeed created strict guidelines on where code and user files should go. That is a good thing. But unfortunately not all developers adhere to these guideline, and MS needed to provide backwards compatibility. Basically, no one should ever write to Program Files, except for install, update or uninstall. In normal operation, this location should be strictly read only. And that is indeed enforced by Windows, if you tell it that your software adheres to the guidelines (using the application manifest). If you don't let it know that you're a good boy, then Windows will run your app as legacy code, virtualizing part of the filesystem. Your code may think it writes to Program Files, but it actually doesn't.

The single correct way to install software in my opinion would be to not install it at all. Installing in this case would mean to copy the folder containing the program from the CDROM to some location on your harddisk or unpacking a zip file that you have downloaded.

Shared libraries are in the same folder as the executable from where the OS will load them. Only libraries that are not found there (e.g. the system-internal libraries) are loaded from the system folder. ---> every program has the correct versions of all shared libraries, no tampering with operating system files needed.

That's basically the way OSX does it.

OS X does that and it's wonderful (I love it, anyway), but OS X also has installation packages, and I've made one before. This was to set up a daemon which needed to enact some system-level configuration change and I decided against putting this onto users (nevermind why).

To the OP:

This isn't super well known, nor does it directly address the installer issue, but... Windows actually lets you map folders to volumes just as UNIX does. Windows 2000 (NT 5) did this and I assume this feature hasn't been removed.

So you could, for example, mount a partition on a different drive altogether to "C:\Program Files" with a little legwork (file shuffling).

In any case, I had a software that had to be installed, and secondary packages which had to place files in the first software's program folders. Mindful of how annoying it is when you can't specify, I did take the effort to use the Windows resource GUIDs or whatever they're called (can't remember the jargon) so that you could install the base program wherever and the secondaries would be able to find their place. MSI and WiX are winners.

Symbolic links to other drives are remarkably easy to set up on Windows. I use this on a regular basis, as I share your small SSD/large HDD setup. You create them by opening a command prompt in administrator mode and using mklink /D

http://en.wikipedia.org/wiki/NTFS_symbolic_link