Omnis Technical Note TNWI0001 April 2010

Windows User Access Control (UAC)

for Omnis Studio 4.3, 5.0 and later
By Bob Mitchell & Götz Krija

What is User Access Control?
UAC is a security measure introduced with Windows Vista designed to restict access to certain Windows registry keys and program folders to users with administrative privileges. The same technology also exists with the Windows 7 operating system. User Account Control means:

  • Only programs with administrative privileges can write to Program Files and registry keys beneath HKEY_LOCAL_MACHINE.
  • Programs are expected to run as user processes without administrative privileges.

Before Omnis Studio 4.3
Prior to version 4.3 Omnis Studio runs on Vista in a compatibility mode. In this mode, when Omnis writes to a file in the Program Files directory, a shadow copy is created in a Virtual Store directory, and the write actually occurs there. Similar functionality exists for the registry entries beneath HKEY_LOCAL_MACHINE. This is confusing because for example a user can copy a library to the startup directory in Program Files, start Omnis, and see the library open. If the user then stops Omnis, deletes the file from Program Files, and then restarts Omnis, the library still opens because Omnis opens the copy in the Virtual Store. (Note that Omnis is unaware of the Virtual Store - Vista causes this to occur behind the scenes).

Omnis Studio 4.3 and User Account Control
In Studio 4.3 we have implemented the following changes

  • Application manifest:
  • Omnis now has an application manifest which indicates that it will run with the same security level as its invoker. This typically means that Omnis runs as a user process with no admin privileges. The presence of the manifest also disables the Virtual Store functionality in Vista, so APIs that write to Program Files or HKEY_LOCAL_MACHINE now return errors.

When running Omnis as a service, ntserv.exe now has a manifest requiring elevation to the admin privilege level.

  • Omnis now uses two locations:
  • For executable and read-only files: "C:\Program Files\Omnis Software\Omnis Studio xxx". or
    ( "C:\Program Files\Omnis Software\Omnis Studio xxx". )
    We call this the program directory. Note that executable files do not include Omnis libraries, as these often need to be writeable.
    For writeable files, either:"C:\users\name\AppData\Local\Omnis Software\Omnis Studio xxx" or or
    "C:\Windows\System32\config\systemprofile\AppData\Local\Omnis Software\Omnis Studio xxx" when Omnis is running as a service. We call this the data directory.

Note that Omnis can still run from a single location, provided that the location is not in Program Files, and the user has write access to the tree in that location.

  • Installation Issues
  • Windows Vista recommends that per-machine installations like Omnis are fine, but any user-specific files (in our case files for the data directory) must be installed the first time the program is run by the user.
    For Vista, the installed tree in Program Files now has a directory called "firstruninstall" in the program directory. This contains the following directories and files, previously present in the program directory:

      Adhoc Appbuild Charmap.ini
      Convert Help Html
      Icons Java Local
      Localclient Startup Studio
      Welcome Serial.txt (if present)

    After installation, when Omnis starts up for the first time, it copies any files found in "firstruninstall" to the data directory. Files already present in the data directory are skipped.

  • Program Registration
  • There is a new program called studiorg.exe. The Omnis installer runs studiorg.exe in order to update the registry with the entries required by Omnis Studio beneath HKEY_LOCAL_MACHINE (file associations, event logging settings, etc). studiorg.exe must also be present in the program directory, so that Omnis can invoke it at startup if the registry needs updating.

Omnis Studio Tree
When Omnis starts up on Vista it first checks the registry to see if it is up to date (if for example you move the Studio tree, or run multiple copies of Studio from different locations, the registry needs changing to reflect the new path to omnis.exe). If the registry needs changing, Omnis invokes the program studiorg.exe. If Omnis is not running with administrative privileges (the default), it will display a message explaining that studiorg.exe needs to run, and after the user clicks OK, the Windows Vista UAC dialog will open, asking permission to run studiorg.exe can run. It is not essential to run studioorg.exe at this point, however failure to do so will cause file associations and event logging to be setup incorrectly.

Omnis then checks for the presence of the Studio directory in the directory containing omnis.exe. If it exists, then Omnis runs from the single directory. If it does not exist, then Omnis constructs a path to the data directory. This path is made using the name of the directory containing the Omnis executable:

<local app data directory> \ Omnis Software \ <name of folder containing omnis.exe>

where <local app data directory> depends on the current user - this is typically C:\users\name\AppData\Local.

IDE Help
This applies to all platforms, not just Windows Vista. The IDE help directory, omnis, now resides in a directory called idehelp. On Vista, idehelp is in the program directory to avoid having to copy these files from firstruninstall into the data directory. (This would have caused a noticeable slowdown otherwise).
Normal/ application help resides in the data directory.
As a consequnce of this, when the user opens the help window for IDE help Omnis now opens the help in read-only mode.

Additional Functions & Commands
The following sys() functions have been added/modified for Omnis Studio 4.3:

  • Sys(115)
  • Sys(115) on Vista returns the path of the data directory. This makes sense, because most people will use this to get or create the path of a writeable file.

  • Sys(215)
  • Sys(215) is a new sys() function which returns the path of the program directory on Vista. On all other platforms, it returns the same value as sys(115).

There is also a new external command: getOmnisProgramFolder provided by the EXTfile component.
Under Vista this returns the path to the program directory. On all other platforms, this returns the same path as getOmnisFolder. The external component SDK also includes an equivalent callback: FILEgetOmnisProgramFolder to use in obtaining the Vista program directory. (Complements the exisitng FILEgetOmnisFolder callback).

Disabling Studiorg.exe

By Götz Krija

When Omnis is started under Windows Vista it checks whether or not the entry in the Registry is still current. If this is not the case the studiorg.exe program will be called and the Registry is updated. If at that time the User Account Control is activated (which is the default), a dialog will appear that has to be confirmed by the user.

When Omnis is opened again, this dialog will not appear. However, when a different version of Omnis is started this dialog will be displayed again. This can be quite distracting for developers as they often have to switch between different versions of Omnis Studio. Since Omnis Studio 4.3.1 it is now possible to switch off this behavior.

To do this create a file called omnis.ini with the following content:

[General]
UpdateFileAssociations=0

and copy it into the Data directory of the user, either your own development installation, or the end user's.
e.g. C:\User\Username\AppData\Local\Omnis Software\OS4314 .. or OS50

Please note that hidden folders under Windows have to be displayed in order to be able to see the Appdata directory.

Search Omnis Developer Resources

 

Hit enter to search

X