Making an Application UAC compatible
What is UAC?
With the advent of UAC (User Account Control), beginning with Windows Vista, Microsoft embedded default permissions and behaviors into Windows to ensure that the default environment in which applications are installed and executed is much more secure than previous versions of Windows.
What exactly are the UAC rules from a software developers viewpoint?
Window's UAC rules are intended to:
- Protect installed program files and registry settings from being modified or damaged by users or programs that should not have access to them.
- Keep each user's files, configuration settings, etc. separate from other users except where shared files or settings are needed.
- Restrict access to any machine wide settings to the maximum extent possible.
By default, only users with Administrator privileges have access to machine wide settings. Microsoft implemented these rules by carefully limiting default permissions on folders under the Program Files folder tree, the ProgramData folder tree, the Windows folder tree, and the Users folder tree. In addition, permissions to registry keys are carefully limited so that standard users will not be allowed to modify any settings that can affect other users.
In order to follow UAC rules a program must:
- install executable code under
the Program Files folder tree and NOT attempt to modify or create any
new files under this folder tree while running the program.
(Standard users generally have only read and execute permissions to
files under this folder tree. In
order to modify or create files under this folder tree, a program would
need either administrator permissions or custom permissions. However,
standard users would not be able to run such a program).
- place shared configuration
and non-updateable data files under the ProgramData folder tree - but
NOT attempt to modify or create any new files under this folder tree while
running the program.
(By default, standard users have readonly access to this folder tree).
- place master copies of files needed by each user under the ProgramData folder tree (to be copied to each user's private folder tree).
- place any updateable shared data files under a custom application data folder, either under the ProgramData folder tree or off of the root directory with permissions set to allow specific users or a custom user group to have read and write permissions on the files.
- setup a private folder tree under the Users folder tree for each user when a user first runs the program so that each user can modify their private files however they wish without interferring with other users.
Private files would include:
ini file or other configuration files with user specific settings
private copies of files each user may need which they can modify without affecting other users
any user specific data files that an application may be designed to create or modify
any temporary files created while running the application
- install any system wide registry keys for the application under the HKEY_LOCAL_MACHINE\SOFTWARE node
- install any user specific registry keys for the application under HKEY_CURRENT_USER\Software node
Implementing UAC in dBASE Plus Applications:
When installed on Windows Vista, Windows 7, Windows Server 2008, or newer version of Windows, the dBASE Plus 2.70.x Runtime and BDE are configured to default to following the UAC rules automatically unless overridden by application specific settings or an application command line switch.
This default takes care of ensuring that many UAC compatibility issues are handled automatically for you.
However, there are likely to be additional changes or updates required to make an application fully UAC compatible.
Here are the main steps to consider:
The application project file
or build script may have to be modified to:
- optionally embed enabling of UAC into the .exe
- optionally disable use of an application .ini file
- optionally move the location of each user's .ini file to their private
roaming folder instead of their private non-roaming folder (which is the
default)
- add any new source files to project that are used to:
*
manage User BDE Aliases (see
version of qBDEMgr.cc installed with 2.70.x)
*
make private copies of certain files installed under the ProgramData folder
for the application (see initnewuser.prg and copyfolder.cc installed with
2.70.x)
Application .exe's and installer should be code signed to avoid operating system delays and warnings when attempting to run them.
The application installer must
be modified to install application files according to the above UAC rules.
-Ensure correct application manifest file is installed
The first time a user runs the
application, the dBASE runtime will create a private user folder for the
user's application data and, if not disabled, and if one does not already
exist, it will create (or copy in) a
private user copy of the application's .ini file.
However
an application's startup code may need to be modified to perform additional
user setup, such as:
- creating user BDE aliases required by the application (if
any).
(Remember
that BDE aliases stored in the BDE's config file require Administrator
rights to create or change. This means they would have to be created at
application install time or through a separate setup program that is run
with Administrator rights)
- creating source aliases required by the application (if any)
- copying files from the ProgramData application folder to the user's
private application folder
- creating any other user specific files or settings that are needed
by the application
Folder
paths used to specify the location of any temporary files must be modified
to place such files under _app.currentUserPath or a subfolder beneath
it.
Folder paths used for any custom configuration files must be updated. Folder paths to updateable data files (if BDE Aliases are not used) must be updated to point to the correct location.
The location of any resource files such as icons or image files must be updated to match their locations under the ProgramData folder or the private user folder.
If the application creates or modifies any registry settings while running,it must be updated to ensure that these settings are located under the HKEY_CURRENT_USER node in the registry.
-----------------
Any additional DLL files your application may use should be installed as required by the application. They can be installed into whatever folder the application expects to find them in.
Also note that...
on 64 bit versions of Windows, any 32 bit applications should be installed under:
C:\Program Files (x86) instead of C:\Program Files
Registry settings for 32 bit applications should be created under:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
or under:
HKEY_CURRENT_USER\Software\Wow6432Node