Starting with the introduction of Windows Vista and subsequent operating system releases, Microsoft added a significant amount of additional security to these operating systems.
Generally referred to as UAC (User Account Control), the sum of these changes dramatically affect named users who might be categorized as "standard" or "general" users. Areas that previously had been quite open, allowing these users to modify, create and delete items like files and registry entries are now protected as default. Users with standard rights and privileges on these systems are now as a default prevented from making changes in such areas as the Program Files folder, the Windows folder and in the Windows registry area known as HKEY_LOCAL_MACHINE.
|
XStudio does not use the Windows registry during normal operations. The only information stored in the registry is created when installing XStudio and is used if you later decide to remove the software from the system. |
In addition, Microsoft published numerous guidelines and usage information regarding these changes. Some of the guidelines would cause applications who require the end-user to be able to modify preference settings, etc., to place files in several locations on the PC. While these changes do enhance the overall security of the operating system, having files and information for a specific application spread all over the system in places not intuitive or easy to find creates a significant support burden for IT managers and the application vendor.
Over the years, we have chosen to try to keep all of our application's files, including those that store preferences, files containing run-time information like exception logging and activity detail, and small database files, in one location for ease in troubleshooting and housekeeping.
For these reasons, our applications are generally placed in a folder other than the Microsoft-recommended Program Files folder. As a default, these other folders historically have been "wide open" in the sense that any user could read, write and modify files.
However, depending on how tightly-secured a system is when running Vista or a later operating system, issues may arise that relate to user rights. The following points may assist you in locating problems with XStudio when running one of these operating systems and the user reporting issues does not have administrative privileges.
1.Make sure that user having trouble with XStudio has read, write, modify and delete privileges in the folder in which XStudio is installed. These privileges might be assigned to an individual user but more commonly are assigned to a user group of which the user is a member.
2.If you are placing files in a location other than the XStudio folder, file locations that are set up in the Preferences area, ensure that the named user has read, write, modify and delete privileges in that folder location.
3.One way that some issues can be overcome is to modify any XStudio shortcuts to cause the application to be run under administrator privileges. [Right-Click] on the shortcut and select the menu item "Run as Administrator". A negative of this approach is that the end-user will more than likely have to enter an administrative password, which defeats the concept of administrative security as you'd have to provide the user with the password.
Another approach some people use is to disable UAC. While this action more or less returns user accounts to the sort of status they had in previous versions of Windows, this too defeats the idea of enhanced operating system security.
4.If an application uses the registry, particularly the portion known as HKEY_LOCAL_MACHINE, you may have to extend rights to specific keys that the application modifies or creates during normal usage. In order to add permissions to the registry, you will need to use regedt32.exe, the extended registry editor.
|
In order to extend additional privileges to a user or user group, either in the file system or registry, you need be be logged on to the operating system as an administrator. |
apt-X™ Issues
The apt-X encoder/decoder uses a software protection scheme that can be tricky to get working under Vista and later operating systems. A hidden file is created by the software, generally placed in either the Windows directory or the root folder of the boot-up drive. Additionally, registry entries are created and maintained in several places in the Windows registry, many of which are normally restricted in in later operating systems.
When setting up XStudio, the apt-X installation, registration, etc., is done by a user with administrative privileges, so no problems occur initially. However, as soon as a user with "normal" privileges tries to use apt-X, errors occur because the underlying apt-X security system is trying to make changes in these prohibited areas.
Networking and Mapped Drives
In Windows XP and prior operating systems, it is a fairly common practice to "map" shared server drives or shared drives on other PC's to a drive letter. Mapped drive letters have been viewed as easier to work with and the network connection to the drive is persistent so long as the mapping is not removed by the user.
In Vista and up, however, the behavior is not the same. While you can map network shares and have them restored each time you log in, these operating systems automatically disconnect the mapping after a period of inactivity. As a default, the disconnect occurs after 15 minutes or so. This can present problems to applications accessing data on mapped drives in these operating systems because of the amount of time it takes the operating system to reconnect after it has auto-disconnected. During the time the operating system is reconnecting, any attempt to read a file or contents of a folder are rejected and the error most commonly seen includes the words "file not found".
If you using Vista or later to run XStudio, we recommend you use UNC paths if you are accessing logs, audio files, exported music data or anything else that is located on a shared network drive.
