I have recently started addressing issues regarding installing and running my existing MFC applications in Windows Vista. For installation this involves getting rid of my old 16-bit installer (which will not run on x64), while for the programs themselves it involves taking note of the fact that the default user account in Windows Vista does not grant administrative privileges to normal programs.
To deal with installation issues, I decided to look at InnoSetup, because it is sufficient for my simple installation needs (static linked applications), and leads to a small and completely self-contained download.
To deal with users without adminsitrative privileges, I modified my application so that it did not write to the Program Files folder, or to the HKLM hive of the registry.
Somewhat to my surprise, I discovered a number of problems (listed below). All problems listed occur in Vista RC1 (build 5560), and (unless otherwise noted) apply to both x86 and x64 versions. They all appear to me to be bugs in the Vista operating system, or at the very least features that will trip up a lot of installation programs and/or applications that were written for previous versions of Windows.
All the problems listed below have been posted on one (or more) of the following newsgroups:
This problem is fixed in build 5728.
The first thing I noticed when I installed my 32-bit app on Vista x64 was that the program icon was missing from the shortcut on the program group. It turned out that this was because the shortcut generated by InnoSetup was defective.
32-bit programs on x64 operating systems (XP or Vista) are typically installed into
Program Files (x86)\MyCompany\MyApp
If I look in this location in Explorer, the program is there with its application icon on both x64 platforms.
On XP x64, the shortcut is installed to
C:\Documents and Settings\All Users\Start Menu\Programs\Myapp
My application icon is there, and the target is the above location. So all is good in XP x64.
In the new and confusing Vista, the shortcut is installed to
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\MyApp
However, the target is
C:\Program Files\MyCompany\MyApp\MyApp.exe
The (x86) is missing, see? The shortcut actually works (somehow?), but this is why my icon is missing - the target is "wrong". Worse yet, if I click on the "General" tab of the shortcut Properties, a message comes up that
C:\Program Files\MyCompany\MyApp\MyApp.exe
is not a valid target (it's true!), and refuses to open the tab. If I manually change the target to
C:\Program Files (x86)\MyCompany\MyApp\MyApp.exe
then everything is fixed: the icon appears on the shortcut, and I can view the Properties of the shortcut.
This problem is largely fixed in build 5728. The icon is still missing, but the "shortcut to the shortcut" is now working.
If I install an internet shortcut in my application directory, with a shortcut to it in the program group, the latter is non-functional and its icon is missing.
Interestingly, in build 5472, if you created an internet shortcut on the desktop, and then used Explorer to create a "shortcut to the shortcut" the resulting shortcut was also non-functional, and did not inherit the browser icon. This "pure Vista" problem is gone in builds 5536 and 5560. However its manifestation for the shortcut to the internet shortcut created by InnoSetup is still there.
This problem is fixed in the x86 version of build 5728, but not in the x64 version
If an aplication is uninstalled from Programs and features, and the uninstaller uses a message box to ask if you are sure you want to uninstall the application (as does InnoSetup), then the message box is displayed behind the Programs and features window. This will confuse the user
This does not happen if
This problem is fixed in build 5728.
When a message box is displayed which should contain a question mark icon, the icon is missing. This occurs both in my MFC application, and in the uninstall program generated by InnoSetup when it asks if the user really wants to uninstall the application.
I have not observed this myself, but in some cases involving re-installation without previous uninstall the above message will be received, even though nothing is wrong. This will be confusing to the user.
The above message is received if you start to uninstall an application, and then change your mind and abort by answering "No" to the "Are you sure that you want to completely remove ..." question.
This is not an error, and this message should not be issued. It will confuse the user.
Suppose I use ::SHFileOperation() with
SHFILEOPSTRUCT::wFunc = FO_COPY SHFILEOPSTRUCT::fFlags = FOF_FILESONLY | FOF_SILENT
then on Windows XP (and earlier I would imagine), the effect of the FOF_SILENT flag is to suppress the progress dialog box (as documented). It does not suppress the dialog that asks if you want to overwrite pre-existing files.
However, on Vista, this flag causes the call to fail silently if the copying operation would overwrite pre-existing files. This would seem to have the potential to destroy a lot of existing programs, and is contrary to the documentation on ::SHFileOperation().
Actually, it seems that CWinApp::RegisterShellFileTypes() was always broken if the application did not have administrator privileges, but this will be far more common in Windows Vista, because the default account type does not give administrator privileges to ordinary programs.
CWinApp::RegisterShellFileTypes() writes to the HKCR registry hive, which is a merge of
For regedit display and reading, the HKCU value (if present) dominates. But for writing, the value is always written to the HKLM hive unless the HKCU key is present, in which case it is written there.
So if the keys are not present in HKCU, CWinApp::RegisterShellFileTypes() will attempt to write to HKLM, which a standard user cannot do. So it can never write anything, unless the keys have been added to HKCU in some other way. There is no provision for this in MFC.
Vista virtualization could potentially have fixed this, but it seems that writing to HKCR is not virtualized, even though for an admin user it is usually equivalent to writing to HKLM. Vista therefore reproduces the old broken behavior, rather than making the program appear to run as it would for an administrator.
So it seems that CWinApp::RegisterShellFileTypes() is broken in Vista (and was before for non-admin users). The solution, I think, is to make the relevant changes in a setup program that has administrator privileges.
This issue occurs only in Vista x64
Many installation programs require input of a name and organization, and take the initially displayed (default) values from the registry. On NT-based systems this information is located in the RegisteredOwner and RegisteredOrganization keys in
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
When Vista is installed, RegisteredOwner is set to the name of the user account, and RegisteredOrganization is empty. Not an ideal strategy, but OK.
However, 32-bit installers on x64 systems will take this value from
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion
When Vista x64 is installed, both RegisteredOwner and RegisteredOrganization are set to "Microsoft" in this location. This provides a negative user experience for users installing 32-bit software on Vista x64.
This bug is new in release RC2.
If you open the Programs and Features applet from the Control panel and select an item, the information previously displayed at the bottom of the page is absent.
These issues are perhaps not bugs, but may create unexpected problems for some applications, even those that have been made "Vista-aware."
Previously, my application had sample documents in a Samples subdirectory of the installation directory, which was in Program Files. If the user opened one of these documents, modified it and then saved, it was saved within Program Files. In Vista, this will trigger virtualization. So I decided to modify my app so that on first activation after each install, it copies the sample documents to a location of the user's choosing (defaulted to Documents\MyApp\Samples). Unfortunately, if the unmodified version of my app was installed previously, and then the modified one, the virtualized copy of the sample file is copied to the user location, so the user does not obtain a fresh copy of the sample files.
Personally, I preferred the behavior in XP with the original version of my app. If the user had administrator privileges, then the document was saved to within Program Files. If not, then the user was denied access, and would have to choose an alternative location.