Divide by Nought

Archive for the ‘coding’ Category

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

Object Design

leave a comment »

Too often developers and engineers miss the point of objects within object oriented programming (OOP). Many create ever-larger containers, objects sets with lots of implicit knowledge about each other, and seem to have disdain for passing variables.  Object oriented programs are still procedural even if they also have a nice way of packaging related data and operations.

Objects should behave like objects.  They are not massive amalgams of things that are sort-of related because that’s how they’re needed right now.  If objects aren’t treated as automatic components, the whole point of object orient programming is being missed.

When creating an object some simple considerations can increase the readability of the code as well as reducing the amount of knowledge needed to update it (which should avoid a whole lot of maintenance).  In almost every situation all of these things are easy to do.  In fact, if they’re not easy to do, that probably means there are extraneous complexities in the overall design.

Things to remember:

  1. Objects represent a single instance of some logical grouping of data.
  2. Objects can contain only 2 types of things: operations (methods) and properties (variables).
    • Properties represent something about the Object.
    • Operations do something based on the Object’s properties (internally provided) and/or passed Parameters (externally provided).
  3. Operations are always initiated externally; method calls, event callbacks, etc.

This implies that:

  1. Properties specific to the Object should be stored in the object.
  2. Parameters specific to an Operation should not be stored in the Object.
  3. Parameters specific to an Operation should be passed to subsequent Operations.
  4. Parameters created in/during an Operation should be treated as though they are Parameters; i.e. they are not Properties and should not be stored in the Object.

You may have noticed that all of these statements say “should”.  While this is nice and soft language in almost every case you should replace “should” with “must”.  If you’re not, your code is probably lower quality than it could and probably should be.

A good rule of thumb is that if you can’t explain it easily, it’s probably overly complicated.  You should be able to explain how and why something works to anyone.  Not any engineer, but anyone (using laymen’s terms of course).  These are some other good rules-of-thumb:

  1. Prefer generic types.
    Using generic types lowers the amount of dependencies and knowledge of a system need by the implementing engineer.
  2. Avoid using generic types if it overcomplicates the code.
    While generic types are great, they aren’t always appropriate.  It’s a balancing act.
  3. Prefer enumerations over generic types (int, bool, etc).
    When passing a political party “3” doesn’t mean anything.  And there are always more options than on and off, running and idle, even male and female.
  4. Prefer parameter only input into methods.
    Using parameters helps to keep methods constrained as automatic units that can easily be called by anyone, at any time and in any order.
  5. Avoid using globals or class-globals as input into methods.
    Using class-globals reduces the reusability and concurrent usability of a method.

Written by me

Thursday, October 22, 2009 at 11:53 pm

Posted in coding, design, Software