Divide by Nought

Archive for February 2011

Windows Path Compatibility

with one comment

There are lots of options when storing application data (that is, non-user data) in Windows.  Microsoft defines environment variables for a number of them and have a couple documents that list them.  I’ve yet to find a source that pulls all the information together.  This is the information I’ve collected to at least help make reasonable decisions about where to store application specific data for applications that are expected to exist on multiple versions of Windows.


  • Unmodified environment variables represent the appropriate location (i.e. a Microsoft standard/default) for certain types of data.
  • Application data is user-specific data used by the application; not user’s document’s etc.
  • Program data is non-user-specific data used by the application; again, not user’s documents, etc.

The last 2 assumptions are based on how Microsoft sets up the default Windows environment variables (“variables”). Essentially that application data is always in a user’s home location and program data is not.  The term “program data” is new to Windows Vista/7 but the concept was in Windows XP as application data for all users.  At least kind of, more on that is below (under the heading “Inconsistency between AppData & ProgramData on Windows XP and Widnows Vista/7”).

Local, LocalLow and Roaming Application Data

Windows Vista/7 introduced the idea of local and roaming application data; in  Windows XP application data is just application data.

The follow is from Microsoft’s Managing Roaming User Data Deployment Guide (it references Vista but seems to hold true in Windows 7):

Windows uses the Local and LocalLow folders for application data that does not roam with the user. Usually this data is either machine specific or too large to roam. The AppData\Local folder in Windows Vista is the same as the Documents and Settings\username\Local Settings\Application Data folder in Windows XP.

Windows uses the Roaming folder for application specific data, such as custom dictionaries, which are machine independent and should roam with the user profile. The AppData\Roaming folder in Windows Vista is the same as the Documents and Settings\username\Application Data folder in Windows XP.

Roaming data (data in the AppData\Roaming directory) roams in the context of Domains.  That is, a user that exists in a domain will have the same data on all computers within that domain.

LocalLow is used for low integrity data for things like Internet Explorer add-ons when run in protected mode.  But what is a “low integrity” data?  This gets into the world of system security and execution rights. Integrity levels are what’s used to assign default security tokens.  Generally speaking something is low integrity if the originating user cannot be authenticated.  This is pretty uncommon for most applications so really only needs to be considered if the application uses user created executables/plugins.  For more information this is a good starting point: http://msdn.microsoft.com/en-us/library/bb625963.aspx

Inconsistency between AppData & ProgramData on Windows XP and Widnows Vista/7

In Windows XP there is a variable for an “all users profile” (%ALLUSERSPROFILE%) but not an “all user’s application data”.  Whereas in Windows Vista/7 %ALLUSERSPROFILE% points to the same place that  “program data” (%PROGRAMDATA%) variable points to.  This shift makes sense given the assumption that program data is application data that isn’t user specific.  However, it also creates a conflict between how data is represented in Windows XP and Vista/7.

In Windows XP it’s appropriate to place user specific application data in %APPDATA% and the same is true in Vista/7.  In Vista/7 it’s also appropriate to put non user specific data in %PROGRAMDATA%, which is the same as %ALLUSERSPROFILE%.  However, in Windows XP %ALLUSERSPROFILE% generally shouldn’t be the final resting place for application data; it should go one directory further into “%ALLUSERSPROFILE%\Application Data\”.  Of course placing application data directly in %ALLUSERSPROFILE% isn’t really that big of a deal (Microsoft does it) but it is inconsistent with how user-specific data is handled.  This isn’t a critical point but it’s good to keep in mind.

From Wikipedia:

Variable Windows XP Windows Vista/7
%ALLUSERSPROFILE% C:\Documents and Settings\All Users C:\ProgramData
%APPDATA% C:\Documents and Settings\{username}\Application Data C:\Users\{username}\AppData\Roaming
%COMPUTERNAME% {computername} {computername}
%COMMONPROGRAMFILES% C:\Program Files\Common Files C:\Program Files\Common Files
%COMMONPROGRAMFILES(x86)% C:\Program Files (x86)\Common Files C:\Program Files (x86)\Common Files
%COMSPEC% C:\Windows\System32\cmd.exe C:\Windows\System32\cmd.exe
%HOMEPATH% \Documents and Settings\{username} \Users\{username}
%LOCALAPPDATA% C:\Users\{username}\AppData\Local
%LOGONSERVER% \\{domain_logon_server} \\{domain_logon_server}
%PATH% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;{plus program paths} C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;{plus program paths}
%PATHEXT% .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.WSF;.WSH .com;.exe;.bat;.cmd;.vbs;.vbe;.js;.jse;.wsf;.wsh;.msc
%PROGRAMFILES% %SystemDrive%\Program Files %SystemDrive%\Program Files
%PROGRAMFILES(X86)% %SystemDrive%\Program Files (x86) (only in 64-bit version) %SystemDrive%\Program Files (x86) (only in 64-bit version)
%PROMPT% Code for current command prompt format. Code is usually $P$G Code for current command prompt format. Code is usually $P$G
%SystemDrive% C: C:
%SystemRoot% The Windows directory, usually C:\Windows, formerly C:\WINNT %SystemDrive%\Windows
%TEMP% and %TMP% %SystemDrive%\Documents and Settings\{username}\Local Settings\Temp %SystemDrive%\Users\{username}\AppData\Local\Temp
%USERDOMAIN% {userdomain} {userdomain}
%USERNAME% {username} {username}
%USERPROFILE% %SystemDrive%\Documents and Settings\{username} %SystemDrive%\Users\{username}
%WINDIR% C:\Windows C:\Windows
%PUBLIC% %SystemDrive%\Users\Public
%PROGRAMDATA% %SystemDrive%\ProgramData
%PSModulePath% %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\

Written by me

Friday, February 11, 2011 at 12:30 pm

Posted in coding, Software, System, Windows