dBASE and Windows Vista™

Back to Ken's dBASE Page

This page was set up to help dBASE developers deal with Windows Vista™ issues. It is not comprehensive, and I hope to update as more information becomes available.

The biggest difficulty that will come up is that Microsoft "enhanced" the security of Vista to the point of making it hard to run some software properly.

The security issues are the primary focus of this article. The information is from developers who actually have Windows Vista™, and any questions should not be sent to me, as I do not at this time have Vista, and do not see getting it anytime soon (financial concerns among others).

Most of what is here is aimed at dBASE Plus as the current version of the software, but at least one developer has worked with Visual dBASE 5.7 on Vista, and his conclusions will be included as well.

dBASE Plus   Visual dBASE 5.x

dBASE Plus

The dBASE Website -- one of the first places you should check is the dBASE website itself -- there is a page dedicated to Vista and possible concerns there: Vista Compatibility for dBASE Plus and dQuery. Note that you can download the manifest files mentioned below from this website.

The following information is from dBASE Developers working with Vista.
PvH is Paul van House
RM is Rich Muller (AutoTraker)
KJM is Ken Mayer

Manifest Files
Basically you have 3 security levels in the manifest:

1. runAsInvoker -- The application should run with the same Windows privileges and user rights as the parent process.
2. runAsHighest -- The application should run with the highest Windows privileges and user rights the current user can obtain, but the application does not necessarily require the user to be an administrator.
3. runAsAdmin -- The application should run only for administrators, must be launched with a full administrator access token, and will not run correctly in a standard user context. This requested execution level marking is reserved for pre-Windows Vista applications that require the user to be a member of the local Administrator group.

If you wish to have dBASE code modify the registry for the BDE, you must be logged in as an administrator and the application must be run with administrator privileges. If you do not run as an administrator, even if you have administrator privileges, you still will not be able to write to the registry. Add your user to the administrator group and use runAsAdmin in your manifest file if you need to modify the registry.

I have found there are different security requirements depending on if you upgraded from XP to Vista, fresh install of Vista, or have different versions of Vista. On a fresh install I found I had to give the user read/write privileges to my application's directory and with the IDE I also had to give the user read/write privileges to the dBASE BIN directory. -- RM

Deployment of dBASE Plus Applications
Note that the dBASE Runtime Installers ("PlusRuntime-b2054.exe" and other versions) do not include the Vista manifest files. If you wish to deploy those (and you should), you will need to add code to your deployer to handle it.

It appears that applications must be installed by an Administrator (or a user with Administrator rights ...).

No testing has been done with Inno Setup so far. Anyone?
If you do test, can you check this in the [DIRS] section -- an option to make sure that a folder has granted full rights to the user to modify files, create new files, etc.? I am suggesting with Inno something like the following:

   ; -----------------------------------------------------------------------------------------------------
   ; Set up the directories on the network:
   ; Modified to do allow users to modify (which deals with editing/creating new/deleting/etc.)
   ; for tables and whatever other files are in the folders. This is done with the
   ;     Permissions: everyone-full;
   ; option. This may become more important for Windows Vista.
   [Dirs]
   Name: "{app}\Main"; Components: Net; Permissions: everyone-readexec;
   Name: "{app}\dUFLP"; Components: Net; Permissions: everyone-readexec;
   Name: "{app}\Other"; Components: Net; Permissions: everyone-readexec;
   Name: "{app}\Images"; Components: Net; Permissions: everyone-readexec;
   Name: "{app}\Tables"; Components: Net; Permissions: everyone-full;
   ; Where to install the dBASE Plus Runtime and
   ; the BDE:
   Name: "{pf}\dBASE\Plus\Runtime"; Permissions: everyone-readexec;
   Name: "{cf}\Borland Shared\BDE"; Permissions: everyone-full;

This might solve the issue with permissions in the BDE folder, for example. (The above assumes the BDE will be installed to the "C:\Program Files\Common Files\Borland Shared\BDE" folder during installation, using the "Silent" install option, such as:

   [Run]
   ; Silent install of runtime suppresses the runtime install display, and the installshield stuff ...
   ; PlusRuntime-bNNNN_en.exe -s -a Runtime=d:\dBASEPLUS\Runtime BDE=d:\dBASEPLUS\bde Silent -sr
   ; In order to get this to work properly, the double-quotes are doubled up in a few places
   ; if you look at the statement ... that embeds a single double-quote (as it were) in the
   ; parameters needed for the runtime and bde installs.
   Filename: {tmp}\PlusRuntime-b2059_EN.exe; Parameters: "-s -a Runtime=""{pf}\dBASE\Plus\Runtime"" BDE=""{cf}\Borland Shared\BDE"" Silent -sr"; StatusMsg: "Installing dBASE Runtime and BDE...";

The other thing to deal with of course is making sure you deploy the manifest files needed for Vista to the appropriate folders. If the manifest files available from the dBASE website are installed in the dBASE Plus folders (C:Program Files\...) you might try something like the following:

   ; Windows Vista Manifest Files
   Source: "C:\Program Files\dBASE\PLUS\VistaManifest\Administrator\plusrun.exe.manifest"; DestDir: "{pf}\dBASE\Plus\Runtime"
   Source: "C:\Program Files\dBASE\PLUS\VistaManifest\Administrator\bdeadmin.exe.manifest"; DestDir: "{cf}\Borland Shared\BDE"

Make sure you tell your users to run the Inno Setup installer "as administrator" -- this is done by right clicking on the install program (Setup.exe or whatever you have it named) and selecting the "Run as Administrator" option.

Installshield Plus -- A security warning when the installer was run, even when logged in as Administrator. The deploy worked, however. Adding a manifest for for the setup.exe program had no effect. It is probably that a deployment as a "standard user" would not work. -- PvH

Operation of deployed applications -- Running Local/Single-User
Logged in as Administrator and as Standard users, running applications, no problems. Adding, deleting records, packing, creating temp files, etc., no problems. This is with or without Manifest files. -- PvH

BDE
Applications that modify the BDE's Registry entries, including the BDEAlias.cc apparently lock up when creating a BDE Database Alias. Using Task Manager to exit the program, starting it again, the Alias has been created, however. -- PvH

Setting permissions on the "Program Files\Common Files\Borland\BDE" folder to allow users "Full Access", it appears the problems with adding/modifying BDE Aliases, both through the BDE Administrator and through code (i.e., :dUFLP:BDEAlias.cc), appears to work without the lockup mentioned elsewhere. This was attempted with the "runAsAdmin" manifest files for the application, BDE and PlusRun, and with the "runAsHighest" manifest files for the same. -- PvH

Note from Ken: If someone can come up with a way of setting these permissions from Inno Setup (and any other installer) that would be useful. (Later ... see notes above on Inno Setup, this appears to work, but I can't test it directly ...)

Network Installations
Application and data on a network drive, PLUSRUN and BDE Installed locally:
Network drive set as a "Trusted" site does not avoid the "Unknown Publisher" warning, unless the user is logged in as an Administrator, the version of the Manifest files used does not appear to have an effect. -- PvH

HTML (.CHM) HELP: PvH fixed this by doing the following:

1. Make sure the network domain is in the "Trusted Sites".
2. Added a Registry Key (had to be logged in as Administrator to do this): Default security settings in Windows 2000 and Windows XP security help files with an extension of ".CHM" from working across a network. To re-enable use of these help files you must perform a "registry hack" on each work station which needs to use the help files. Please note that if you are NOT familiar with working with the registry you should not attempt this change. Any mistakes made can disable the computer or cause unpredictable and undesired behavior in applications.
   • Open Regedit
   • Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x
   • Make a backup of this key
   • Expand the "1.x" key.
   • If a subkey "ItssRestrictions" does not exist, create it as a subkey of 1.x
   • Right-Click the ItssRestrictions subkey, choose "new" then click DWORD Value.
   • Type MaxAllowedZone and press ENTER.
   • Right-Click the MaxAllowedZone and click "Modify"
   • In the Value Data box, type 2 and click OK (this will allow html help/.chm files to be opened from the local intranet and trusted sites zones.

BDE Administrator
It appears that only a user logged in as "Administrator" (with Administrator rights) can use the BDE Administrator with impunity. You can change or create an alias as a "Standard" user, but once the "Apply" button (or Ctrl+A) is selected, the BDE Administrator program "locks up" and requires use of the Task Manager to close. However, the alias is created/modified, once you start the BDE Administrator again. -- PvH

See notes above about setting permissions for the folder in the installation ... -- KJM

I have suggested people take a look at and try working with the program SETACL.EXE, which has a command line ability. In Windows XP, you can set the rights to modify the registry keys for the BDE using:

   setacl.exe "MACHINE\SOFTWARE\Borland /registry /grant S-1-1-0 /set_val /sid"

You can download this freeware program at: http://setacl.sourceforge.net/

Not having access to Vista myself, I can't test this under Vista. If this works, perhaps other permission issues can be fixed as well. I hope someone who has access to Vista can try this and see. If so, you can deploy this using Inno Setup by making sure it is in the Files section of your Inno Setup script as:

   Source: "C:\Software Patches and Updates\dBASE\setacl.exe"; DestDir: {tmp}; Flags: deleteafterinstall; MinVersion: 0,4.0.1381

And in the Run section of your Inno Setup Script as:

   ; setAcl is used to give users full access to the registry keys at HKLM\SOFTWARE\Borland
   Filename: {tmp}\setacl.exe; Parameters: MACHINE\SOFTWARE\Borland /registry /grant S-1-1-0 /set_val /sid; WorkingDir: {tmp}; MinVersion: 0,4.0.1381

Visual dBASE 5.7 (and earlier versions)

Deployment:

"Dashboard" Deploy tool -- A security warning when the installer was run, even when logged in as Administrator. The deploy worked, however. Adding a manifest for for the setup.exe program had no effect. It is probably that a deployment as a "standard user" would not work. -- PvH

Icons in Applications:
Icons embedded in EXEs and 16-bit DLL's are not recognized by Windows Vista Explorer. The .EXE will have a generic looking icon. When you create a shortcut (for the desktop) you are told there are no icons in the .EXE. If you try to create a shortcut using an icon from a 16-bit .DLL the same error will occur.

Use Borland Resource Workshop to extract the icons you need for shortcuts, and this apparently works fine.

Running the 16-bit EXE, the icon embedded in the .EXE appears to work as expected. -- PvH