Divide by Nought

Archive for the ‘Software’ 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

Intergalactic Software publishes The Wedding Checklist

leave a comment »

Intergalactic Software has published a new application to the app store.  It’s great for determining what you need to do when planning a wedding.  Check it out here: The Wedding Checklist, or view it in iTunes.

Written by me

Tuesday, August 24, 2010 at 1:03 pm

Posted in Productivity, Software

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

Finding Code Issues with Regular Expressions

leave a comment »

Finding dead code removed with pre-compiler directives:
^:Wh*\#~(else|endif|if DEBUG|region|endregion):i*

Finding unused exception blocks:

Visual Studio (single line only):


Finding console outpout:


Finding trace outpout:

Written by me

Thursday, July 23, 2009 at 3:32 am

(Mostly) Free Software Tools

with 2 comments

My list of good free software (at least most of them) tools for common operations for Windows and as much as possible Linux & Mac:

Written by me

Monday, February 9, 2009 at 8:12 pm

Posted in Software

Create a Dedicated SCCB User

leave a comment »

Creating a dedicated SCCB (Software Change Control Board) user and using it only during SCCB meetings can make history tracking easier to handle.  This is because it…

  1. Clarifies the context of the change; i.e. during an SCCB meeting.
  2. Keeps the user consistent regardless of whether the SCCB chairperson changes.
  3. Avoids confusion for the current chairperson when trying to determine who made a change, when and why; i.e. whether the given SCCB chairperson made changes during the SCCB meeting or as part of his or her “offline” work.

Of course it doesn’t tell who the chairperson was at the time.  Often that doesn’t really matter since the point of the meeting is group consent for changes; so the individual matters less.  If it does matter a field can be added to each record as to who the SCCB chair was or it can be captured in meeting minutes.  And of course only a limited number of people would have access to the account.

Written by me

Wednesday, December 3, 2008 at 12:17 pm

Things vs. OmniFocus

with 3 comments

OmniFocus and Things are both great GTD/PIM/Productivity applications.  I’m using them both just too see which one I end up using more and then I’ll stick with the winner.  I would simply choose one, but they both have their limitations.  Omnifocus is a little too structured while Things is a little too loose and, even worse, manual. Nothing is ever perfect, but a couple small changes to either and my life would be so much easier.

OmniFocus being too structured appears to be the result of strict adherence to the GTD scheme.  As a seeming result it doesn’t offer things like deep projects (projects with sub projects that have their own sub projects…ad nauseam…).  It does have folders (aka groups), but that’s a completely different concept and requires manual organization.  That’s a big deal, manual operations take half of the value out of a task management applications.  It does, however, allow for hierarchal contexts.  This is a good thing overall, but even there it would be nice to have a little more depth.  A cross between relational organization and hierarchal organization would be super powerful.  Then again, nothing that I’m aware of offers that right now, so maybe I shouldn’t be surprised.

Things has projects, areas, hierarchal tags, and people.  All good things and allowing finer control over tasks than OmniFocus.  But it doesn’t allow for anything but tags to be entered (associated) during task entry.  Odd.  What this means is that project and area associations must be manually created after the task is created via a wizard like menu system.  This is the definition of kludgy and is Things biggest limitation.  Why?  Because entering new tasks needs to be very fast and shouldn’t required that I do anything else to organize them beyond that initial entry.  Unless of course I want to change something because I didn’t do something.

Finally, they’re both only available for the Mac.  I think Macs are great (more specifically OS X).  But I do have Windows machines both at work and home.  Why, oh why, must I use a Mac to have good task management software?  At a minimum a nice Ajax enabled web client is in order.

…at least they both have iPhone apps.

Despite my criticisms I do like both of these programs and think they’re better than anything available for Windows (Outlook doesn’t even come close).

Written by me

Sunday, July 13, 2008 at 3:56 pm