Quote: Originally Posted by PackersFTW
Quote: Originally Posted by Britton30
When the software gives a folder to install to, let it do that. As Dwarf points out it will go where it needs to be.
As for having to "search" for programs, right click on it's shortcut and pin to Start Menu or Task Bar whichever is convenient for you. this way you will have quick, easy access to it.
Windows 7 search is capable of finding it wherever it is.
You can also right-click on the program object (in Windows Explorer, for example) and then select "Send to... Desktop (create shortcut)". Now you don't need to search at all to run a program, because it's on your desktop. You can of course then rename the desktop shortcut if you want to anything else, since it's just renaming that shortcut, not the original program object itself.
Furthermore, you can then PIN that desktop shortcut to the taskbar or start menu, for quick access. Again, this avoids having to search anything to run a program.
And of course, once the desktop shortcut for it gets pinned to the Start Menu or Taskbar, you now really no longer need it on the desktop as well... unless you want it there as a duplicate. But (a) the taskbar will provide true single-click launching of the program (really, just like the Quick Launch bar of WinXP), (b) the start menu provides fairly direct and organized launching of the program (assuming you organize your Start Menu into high-level folders and then move the "raw" folders put there by installers into the hight-level organizational folders), and (c) the desktop shortcut requires a double-click to launch. Up to you.
Personally, since moving to Windows 7 I've tried to keep my desktop program objects to a minimum, preferring to pin the several dozen I use regularly to a double-high taskbar using small icons. Everything is, of course, "organized" into a high-level menu structure on the Start Menu, because I can't stand multiple columns of first-level folders for software products that spread out across my entire screen (as they used to in Win98 and WinXP) or otherwise make themselves inconvenient to locate even if they're now automatically alphabetical (since Windows 7 now handles it as a huge scrollable list of Start Menu folders, which is just as clumsy to navigate through although it looks a bit more organized).
It says to install it to C:, and I found out the program won't work properly otherwise. I was told the installer is 32, but the program is 64, so it can't go in either PF folder.
This is probably a residual from a very old original installer approach taken by that product when it was 16-bit DOS and FAT files structures, before before FAT32 when the era of "long file names" arrived.
The problem is not one of Windows 7, it is one of the software product and its design and implementation. I assure you, your observed restriction where the program folder HAS to go into the root of C rather than under one of the two flavors of \Program Files or \Program Files (x86), well that's the fault of the application program... not Windows 7.
So I want to know, what are the non PF folders? How is C:, for instance, different from the PF folders? Why did that program work there?
Again, not a Windows 7 issue. It's an application program fault... take it up with the vendor (assuming it's not a 10-year old legacy program, but rather is "current" and actually maintained by the author).
As far as \Program Files vs. \Program Files (x86) on C, and as far as putting a second pair onto a second drive (so that you now have 4 folders), in my experience there is really no difference in the first two. They are BOTH in the PATH variable (e.g. if you use a DOS-like launching method of Start -> Run, rather than using a program/shortcut which is obviously MUCH easier and more convenient), so a program of any kind (32-bit of 64-bit) will be found an executed just fine from either location when Start -> Run is used.
If you have both 32-bit and 64-bit versions that both work, on a 64-bit system you would prefer to run the 64-bit version of the program. That will happen automatically because \Program Files (where the 64-bit programs get installed if the author packaged the installer file correctly) occurs EARLIER ON PATH. Searching of \Program Files (x86) will occur LATER ON PATH, so the 64-bit version will be used if both exist.
But EITHER will work, because BOTH are on the system PATH variable. And of course launching a program from a shortcut object is far and away the absolutely most convenient method, topped by the Taskbar shortcut which is a true single-click launch.
If you want to create your own "private" off-C version of an executable location for installed programs (say on D), I would suggest only making one, not two. There's really nothing magic about either of the names... only how a well-written installer script will create the program file directory by default, and in fact whether or not it will in fact put everything it installs on D or whether some "straggler" pieces will actually get installed onto the C-version anyway, because of sloppily written installer script.
Now is you want to make the programs installed onto your D-version "target" folder be accessible through Start -> Run as easily as those installed in your C-version are, you would need to add your D-version(s) of \Program Files to the PATH environment variable.
Otherwise, there is really no difference between \Program Files and \Program Files (x86) other than to support old poorly-written installer files, when everything was either 16-bit or 32-bit. This is simply an implementation approach to differentiate 32-bit from 64-bit, but programs of either flavor placed in either directory WILL STILL RUN JUST FINE.
Using program objects or shortcuts to program objects, this is the "modern" way to launch programs. And having the object/shortcuts pinned to the Taskbar or Start Menu, or sent to the Desktop... that's the most convenient way to organize and utilize program objects for easy launching.
There is no reason to "search" anything to launch a program you use frequently. Simplify your life and create a launchable shortcut somewhere.
Also, you should enable "RUN" (like it used to be on the WinXP Start Menu) to appear on the Start Menu popup (see my screenshot above), which for some reason is NOT enabled by default in Windows 7. Personally, I couldn't live without it.
That's just my opinion.