forum.vdsworld.com

[PGWARE]

Here is some information on how to program generally and using VDS when programming for Windows Vista. I'll try to do some bullets, please be aware I'm no expert but try my best to act like one

DONT's

- Do NOT store any information into \Program Files\ directory or any subdirectory. This means any configuration files, log files etc that your program requires. Consider the entire \Program Files\ directory off limits. * If you really need to, look below for a method how and explanation on virtualization. *

- Do NOT attempt to write files into \Windows\ directory or any subdirectory (including the TEMP directory). If you need to write to a temporary directory use the current USER TEMP directory.

- Do NOT WRITE, DELETE any registry entries to HKEY_LOCAL_MACHINE. Store all information into HKEY_CURRENT_USER, this has a side effect that each user on the computer has his/her own settings, but also means you cannot have global system wide settings. * If you really need to, look below for a method how and explanation on virtualization. *

- Do NOT use SendMessage or API's to windows that are running in a higher privilege, it simply will not work. It is okay to use api's including sendmessage to application/windows in the same privilege as you (ie. lower level - lower level, or higher level - higher level, and higher lever - lower level). You can as a higher level privilege application sendmessages to lower privilege windows and to other higher level applications. Vista runs applications as lower level privilege as the default. * To gain a higher privilege (administrator) look below. *

DO's

- Do store any information you need to into \Users\All Users\ if you need to write configuration files that needs to be read by all users on the computer. If you only wish for the files to be read by the current user then write to \Users\UserName\.

- Do WRITE, DELETE to registry entries in HKEY_CURRENT_USER. This allows your application to store options on an individual basis for each user on the system.

- Do READ from registry entries from HKEY_LOCAL_MACHINE. You can of course read from any portion of the registry, but cannot modify (delete, write) entries in HKEY_LOCAL_MACHINE.

Explanation: Vista runs in two security contexts, as an administrator and as a limited account. Your program will run as a limited account, all programs in Vista do as the default. This means you cannot write to global areas of the computer (windows directory, program files directory, hkey_local registry). The reason for this is to shield the computer from malware, viruses, etc that take over a computer by writing global changes.

The side effect to this means, you need to write your applications so they run on a per-user basis. That means you need to store program information (files, log files) into \Users\ directory. That you need to use HKEY_CURRENT_USER to store registry entries, and that you use the current USER TEMP directory to store temporary files.


Bypassing Windows Protections

Well you aren't really doing anything wrong here, Windows Vista knows that some applications will require system wide changes to HKEY_LOCAL, to the \Program Files\ and need acess to all administrator privileges. There are ways and they are easy to achieve

Method 1:
Around the middle of the page explains the manifest file and what to use

You simply need to include a .manifest file into your exe or in the same directory as your exe to notify Windows Vista that your program needs to run under an adminstrator/higher level privilege. When an end-user runs your program Vista prompts with a dialog box that asks if the user wants to run your program and elevate the privilege. If granted, your program now has the ability to access any part of the computer.

The problem with this method is that many applications that require admin privileges will take advantage of this option and cause security privilege prompt fatigue. It will become tiresome to continually click on prompts to allow programs to run in a higher privilege. But one benefit is that it shields the system from most of the malware and viruses out there. You are asked before any system wide changes can ever occur, obviously you still need to make sure the program you are running is safe because once you allow it a higher level privilege it can do as it wishes to your system globally (including the ability to shut off the entire windows protection altogther and allowing other apps to gain higher context with no prompts - MS says they are looking into ways to prevent this).

Microsoft recommends splitting your code into multiple exe's. For instance if your application has a user interface, let the user interface run as a limited privilege app. If the program needs to make registry/system file changes, then create another exe with this code in it, include the .manifest file into the exe that notes it requires admin privileges. Then have your original program execute the other exe when it needs to write to the registry. The user is prompted for higher privilege access only during this step. Obviously if your program requires constant changes to system files or to HKEY_LOCAL registry then splitting up the code into multiple exes is not a good idea as your program would constantly prompt the user to run your code. It would be better to stick the manifest file into the main exe and the user will only be prompted once during the initial run of the program.




Method 2:
You can run the program as a limited user but still gain access to \Program Files\YourDirectory, and HKEY_LOCAL_MACHINE\YourKey. You however still cannot use api's that interact with higher level privilege apps, and cannot write to any other portion of the computer system globally. This method involves modifying the Windows ACL on a directory and on a registry key for your application.

I use the InnoSetup installer program for my applications, by simply including Permissions: everyone-modify on Directories, and Registry entires in the innosetup installer script your program allows any user on the computer access to the directory and to the registry key you specify.

Using this method means that there is no prompt to the user to gain privileges. Only during installation of your application will they be asked to gain privilege to run as a higher level, and your installer makes the ACL changes to the registry/directory. There are no longer any more prompts for your program because your program is still being run as a limted account, but has access to the directory/registry since it is marked as 'everyone-modify'.

VERY IMPORTANT This sounds like a good method because it helps elimanate user fatigue to security prompts everytime your app is run. It also allows your app to write to the registry and to your program files directory. BUT there are security implications. When you modified the ACL for the folder and registry key you subsequently gave every single user on the computer (including guest account) access to do whatever they want to any files within your custom directory and within your custom registry key. So it is very important NOT to changes ACL's on registry entries and directories that do not belong to your application. Doing so can lead to security breaches on a users computer and liability on your part.



Windows Virtualization
Windows Vista will allow many older programs to run and continue to write to \Program Files\ and to HKEY_LOCAL_MACHINE, and to several other directories. While it appears the programs are writing to these areas of the computer, they are in fact not really. Windows Vista 'virtualizes' these areas, so really your entries to the registry and file changes in \Program Files\ are stored elsewhere, but your program and if you open explorer/regedit it looks like they are in the right place - but they truely are not. If you log into another user account you will in fact see that the entries in HKEY_LOCAL and \Program Files\ is not there. Vista does this to allow older programs to still write to these areas but these programs cannot write system wide changes/configurations, they only appear to do so. Microsoft notes in their documentation that they will later down the road remove virtualization completely for the registry, and leave it in for \Program Files\ and for other directories. Virtualization is a stop gap for older programs to still be compatible, DO NOT write programs to rely on Virtualization, write any new applications to take into account these considerations for Vista. Seperating your code and writing changes on a user level will work for all versions of Windows; it is a better practice to follow and will ensure your applications will work for future versions of Windows too (hopefully ).

Code Signing
You should sign your exe's with a signature. Most certificate companies provide Microsoft Authenticode signing certicates. Typically around $100+ dollars per year. You need to be a valid business and have documentation to prove this before the certificate authority distributes a code signing key. Code Signing is important because in Vista there will be an option for computer administrators to only allow programs that have been signed and also contain a manifest file to be run under an administrator context. Not having your code signed and not having a manifest means your program will not have the ability to run in a higher context on these computers. By default this option is NOT ON within Vista, an administrator has to specifically select this. Likely this will only be used by users that want tight security on their machines but more likely by Enterprise and Schools where security is crucial.

[GeoTrail]

Actually you can't store any files on the base of the Program Files folder on Vista. And you can't create any keys at HKEY_LOCAL_MACHINE either. If you try you will get a success return from your apps, but nothing has actually been written

Been a Vista user since before PR1
Now a legal owner and everyday user of Vista

[PGWARE]

According to Microsoft their virtualization technology actually does let you 'appear' to write to HKEY_LOCAL_MACHINE and Program Files directory. If you call these areas from your app they are mapped to the actual directories that the files/entries are written to - they really are not in the Program Files or LOCAL_MACHINE but mapped to user directory and HKEY_USER_USER. But your program can still call the old methods allowing them to still run without changes.

Microsoft said they would eventually turn off this virtualization down the road but kept it in to allow older applications to continue to work without having to be rewritten.

So while it looks like your app is writing to program files or hkey_local it really is not.

Now if you elevate the security token in your application and the user runs your exe and allows admin access you absolutely do have the ability to write to any part of the registry or any part of the computer including Program Files.

Another method is during the install of your application (which the installer has been given elevated permission) you can write the ACL permissions on both the registry and program files directory your software is in to allow everyone-modify permissions giving any app the ability to modify any key or file/dir that you set those ACL permissions on.

I have tried these methods with RC1 and they do in fact work, now if there has been a change with RC2 that could very well be the case, but it is very unlikely the virtualization support has already been removed.

[Skit3000]

Be sure to, when you save files, to always save it into the directory returned by @env(HOMEPATH). This will point to something like C:\Users\Username. When you have a non-English version of Vista, when running the Explorer you will see the word "Users" translated into your own language. If you use C:\Gebruikers (the Dutch word for Users) to save files, it does work but please note that people with other languages may have problems with it when running your application.

[jules]

You are certainly right that you should never use hard coded folder names, but I think it is better to use the registry to determine the folder paths to use. Environment variables are so 1980s MS-DOS, and I'm never 100% sure that they will always be present or contain the correct information, because they can be modified by SET commands and such.

You can always obtain the location of the desktop folder using @windir(Desktop).

If you need a special folder to store your program's data, create a folder with the path @windir(AppData)\<appname> and use that.