I have already submitted the same feedback in the past and I know the reasons behind this design choice, nevertheless I prefer the "conventional" approach of Windows clearly detailed by tmenke.
V is a software with a really long history and, I suppose, a quite large number of users. What I've seen since I started using it in the late nineties is that the author always tries to do his best to include new features or adapt the program following user requests. And this behaviour comes from one of those requests, so changing it may adversely affect some users that rely on it.
On the other hand it is also important to consider how much the operating system changed since the 95/NT4 days (when V was first released). Today users have a lower security profile with limited privileges and also administrators are required to confirm some tasks through the UAC prompts. While it is still possible to find older operating systems not supporting UAC or disable most of it on newer OS, none of these is considered a best practice, so I'm considering the usage in two different scenarios: out of the box Windows (running the default settings) and enterprise users. In these scenarios there's no way to remove a software without admin permissions.
Some software, usually installed directly from webpages or supporting side-by-side installations with previous versions, installs in the user profile. In this situation the software doesn't rely on the user admin privilege and thus it cannot write on either the %ProgramFiles% directory or the HKLM hive, so the software is installed in the %LOCALAPPDATA%\Vendor\AppName path and all the settings are saved in the HKCU hive.
Given that, I think there's an inconsistency in the way the current version of V is installed, because it uses a global binaries repository (%ProgramFiles%) along with a private settings repository (HKCU), triggering some issue such as the one mentioned by tmenke:
By tying it into the installers account, you unnecessarily make that account crucial/special to the uninstall process. Say the person who installed the software leaves the organization and the account gets deleted. Now you can no longer easily remove the software if need be, an administrator needs to manually start deleting files and registry entries by hand instead of having an automated process.
Note @tmenke: given the really reduced footprint of V, the easiest way to remove V in the described scenario is to reinstall V (same architecture, possibly same version) from another user account and then to remove it.
You can tell if V has been installed by the existence in the Registry of HKEY_CURRENT_USER\Software\Prineas\FileViewer.
However, I am not sure if it is possible for an Administrator to query the Registry for all user accounts.
The way registry is loaded doesn't permit to access the hive belonging to another user unless the user is currently logged on. Furthermore it requires to know the SID of the user who installed the software and this SID may be local to the machine or belonging to a directory service (e.g. Active Directory). This makes it a really hard task.
Also if I'm not wrong the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\V64 mentioned earlier in the thread refers to a 64-bit setup, while the 32-bit setup uses a different key ("V" instead of "V64") and is probably placed in the HKCU\Software\Wow6432Node branch if the 32-bit setup is executed on a 64-bit computer.
One option is to write a small script that actually fixes the registry as soon as the software is installed, but of course it's up to the user who installs the software to also fix the registry, and it's often left behind for a future time. Not to mention the update/upgrade process which may be triggered by V itself, eventually from a different user account, spreading registry keys all around.
A better option is to rely on the Application Compatibility Toolkit (from Microsoft) and write a small fix (actually a registry key redirect. Look at
CopyHKCUSettingsFromOtherUsers and
VirtualRegistry) to redirect all the access to the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Vxx key to the HKLM hive. I don't know if this actually solves the 32/64 bit problem described earlier in this post because it depends on a built-in registry redirection feature of Windows.
Links to the Application Compatibility Toolkit
A note from the CopyHKCUSettingsFromOtherUsers page on the TechNet website (
http://technet.microsoft.com/en-us/libr ... 38375.aspx):
Applications should be modified so as not to apply per-user settings while elevated. In addition, you should consider whether to apply settings to the per-user or per-computer registry for any application that administers the computer or requires Administrator privileges.
I think that the best and most conservative solution is to allow the user to choose the preferred setup behaviour, possibly saving this choice in the settings/preferences (HKLM) so that further updates use the same setting.