I've nearly completed developing a game for Windows and I'm curious where I should have the installer install it. I know it used to be in "Program Files" but has that changed under Vista?
I know that World of Warcraft now installs under Users/Public/Games... what is the Microsoft-recommended location for games?
In Vista, the recommended directory is still %PROGRAMFILES%.
Note that in Windows 7, Microsoft has enabled the creation of true per-user installations, including support for per-user Program Files. This is a feature of Windows Installer 5.0, and you can read more about it here:
http://msdn.microsoft.com/en-us/library/dd408068(VS.85).aspx
You should use the Environment variables.
Namely %PROGRAMFILES% for you.
Just read the question a little more thoroughly. From my experience of Vista, most of the gubbins still install to %PROGRAMFILES%. Perhaps the /users/public... path is somewhere where things can install (and update) without having to get admin perms all the time. (A complete guess)
Looks like you should use SHGetKnownFolderPath to ask for the location of the FOLDERID_Games KNOWNFOLDERID.
EDIT: Nope, doesn't look like that is right. This thread has a discussion of FOLDERID_Games and notes that it is a virtual directory. This knowledgebase article discusses the Windows Vista Games Explorer. And this article has some more Vista specific information.
Sorry - this has turned into a non-answer but maybe the links will help you find the answer.
The recommended directory is still Program Files, as everyone has said. However, if you want a per-user install, you could install it in the AppData folder. I know Google Chrome does this to allow installation without being an administrator, and also for user-specific installation.
Related
I have a French client with the French version of Windows 10. However, our Installshield-built installer is looking for C:\Users\username\Local Settings\Application Data, and fails with "Error 1320. The specified path is too long"
We tried to see if we could connect to the appropriate Local Settings\Application Data folder (in English), but it is either not accessible or even as admin we don't have privileges to go there (even from an admin command line).
I understand Windows 10 has some sort of invisible aliases or compatibility for these standard folders?
Are there any tricks we could use to get the software installed?
Disclaimer: this is a hack and the correct answer was provided by slugster - rebuild the MSI
Now that that's out of the way I do have a suggestion for you that might be able to resolve the problem for you. You can try creating the path that the installer is looking for and then creating a symlink to link that folder to the correct folder on the users machine. no guarantee that this works but might be worth a shot. If you need more info on creating symlinks check out hte TechNet page for MkLink
As you know, Windows has a "Add/Remove Programs" system in the Control Panel.
Let's say I am preparing an installer and I want to register my program to list of installed programs and want it to be uninstallable from "Add/Remove Programs"?
Which protocols should I use. Any tutorials or docs about registering programs to that list?
I am coding with python and I can use WMI (Windows Management Instrument) or Win32 API. IMHO, it is done with Registry keys but I am not sure with it.
I also want to execute an uninstaller upon the Uninstallation to remove installed files. Any related docs or tutorials are highly appreciated. Thanks.
As stated on IRC:
"Windows keeps its uninstall information in the registry"
Its in HLLM\Software\Microsoft\Windows\CurrentVersion\uninstall\ keys.
You need a few things from the Win32 API, but I belive there's a fair amount of Python support for the win32 API.
Basically, a key in ...\Uninstall\ with a unique name (like "MyApp") with a few special values stashed in there. Add/Remove programs looks through there.
Its pretty self-explanatory.
If you are developing for Windows platform I think using Windows Installer from Microsoft won't be a problem.
You can check documentation of Windows Installer from Microsoft.com Windows Installer Page
Inno Setup is open source so perhaps you can get some ideas from that.
I have an application written in Delphi 2006 that was working fine in Windows XP. I packed the application using Inno Setup, using Program Files as the default folder. A few users migrated to Windows Vista and Windows 7. The issue here is that the application creates some files inside its installation folder by its own. This was working in XP but in Windows Vista the users were having problems with the created files (they don't appear and so on). After investigating the users' reports I discovered KB 927387: "Common file and registry virtualization issues in Windows Vista or in Windows 7."
Running the application with administrator rights just solves the problem, but that is (I think) an awful workaround. I would like to know if there are any directives or tips for making the application compatible with Vista and 7, because more users will migrate to these OS soon.
You need to re-write your application to store its files in the proper locations, even in XP, but especially in Vista onwards, particularly if UAC is enabled. This is becoming more and more important to get right as Microsoft keeps locking down and enforcing its security models with each new OS version. The rules for how to properly manage application- and user-related files is documented on MSDN, for example: "Application Specification for Microsoft Windows 2000 for Desktop Applications, Chapter 4: Data and Settings Management" and "Application Specification for Microsoft Windows 2000 for Desktop Applications Appendix A: Best Practices" (yes, they are old, but are still quite relevant). Look at SHGetSpecialFolderLocation(), SHGetFolderPath(), SHGetKnownFolderPath() and other related functions to help you.
For Vista/Win7, your app can't put the files in a subfolder of Program Files / Programs unless UAC is turned off or the app is running as elevated. Note that "elevated" does not necessarily mean "logged in as Administrator." Non-administrator users can elevate, and Administrator isn't necessarily elevated.
If the app does attempt to write to Program Files but is not elevated, the OS will either block the app or "virtualize" the write (put the files somewhere else), depending upon how UAC is configured. Neither one helps the app succeed at what it was trying to od.
So it needs to put them somewhere else. Where depends on why the files are being created, and you haven't told us that. You can read this article to learn about the options. Note that in addition to the user's AppData and Roaming folders, there is also an "All Users" (shared) profile.
You should probably look at this article and screencast, which discusses UAC in depth from a Delphi point of view.
Files you create for use by your application other than at installation time should go into the ProgramData directory if its global to the workstation, or into the users ApplicationData directory if its specific to the user.
For cases where you absolutely must place a file in the program files directory, you can use com to request elevation. This is discussed in great detail, and delphi specific bits are also available. One example that I have used this is in patching my users installation base. They are warned by UAC that the system needs to make changes, so if your doing this as an automated task, you might need to rethink the logic to be more user driven.
Here is another article, by Zarko Gajic, which shows how to get different system directories. Also have a look at this related question.
I had a similar enquiry here (Stack Overflow).
In the end I realised that I needed to put my application into Program Files at install time (requiring UAC/elevation) and then store my app's data in the user's App Data folder. I had to change the way my program generated 'default' configuration settings and also where I was saving this stuff, but it was worth the effort in the end - we ended up with something that installs and runs fine on XP, Vista and Windows 7.
The only UAC hit we get is at installation time, which makes sense to me (and you get a similar hit at install-time on the Mac too). We didn't have any data that would be common to all users in this particular case but I would have looked at the Program Data special folder if that had been the case.
The installer software we use (Setup Factory) made this fairly straightforward (we just wrote a small bit of code to detect XP versus Vista/Win7 and choose the right special folder accordingly). It would be easy to do this in Inno Setup too, from what limited experience I have of it.
I need to find out all the file system and registry operations that installer of some application performs. Is there a software tool for this?
OS is Windows XP, if that matters.
Look into the Windows SysInternals Utilities.
Specifically RegMon & FileMon
I'm not sure about tracking file system changes, but you can export the Windows registry as text before and after the install, and then use a diff tool to see what's changed. There's an O'Reilly hack about that here.
You could conceivably do the same with a DIR/S at the root of your drive, although it would be pretty time consuming.
Why not use one of those "uninstall monitoring programs" ?
Total Uninstall is the first that comes to mind, although there is a bunch of them, really.
This site has a list of some installer monitors.
I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?
Windows still lacks a convention for per-user installation.
When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.
(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)
What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.
One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.
I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.
As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.
The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.
In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.
Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).
The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.
That said, the option to install per-user is quite nice, as it means no permissions issues.
Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:
https://www.google.com/intl/en/chrome/business/browser/
I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.
Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !