On Wed, 25 Apr 2007 18:40:00 -0700, LabTechnician
If you can accept advice from a very "ex-"programmer...
Vista makes a lot of changes, and there are 2 ways to develop for it:
1) Do what you normally do, make changes when this fails
2) Research the intentions behind the changes, develop for Vista
It may be a pain, but I'd strongly recommend (2).
Without an understanding of why Vista is designed as it is, you'll
find it harder to anticipate the collisions that reactive approach (1)
will require you to work around.
You'll be faced with a sea of inexplicable and seemingly-unrelated
issues, from UAC to virtualized locations etc. that only make sense
when you get into the design goals for Vista.
As Vista RTM is the first step towards the new design approach, what
works today may not work tomorrow... IOW the pain of (1) won't stop
when you ship your own working app, but may pop up again and again
over the years, as SPs and fixes discard some of the
backwards-compatibility stuff that may still work in today's RTM.
I did find it interesting that if our program is run by right clicking our
shortcut and then select run as administrator, the hidden files now appear
within the softwares, program files folder. Thus appearing to bypass the
virtualization folders.
Yep; that's the design intention. So whenever you "touch" one of
those protected locations, you have two separate behavior sets to
tshoot, depending on whether the user was elevated or not.
As you've already discovered!
Problem 1: Installer issues:
Our installer does not overwrite the files which end up in the
virtualization folder, Possibly because it is not aware of this feature, so
we are looking into trying a new version of our existing installer or
entirely new installer.
If you're licensing an existing 3rd-party installer that you're
well-familiar with, see if they have a new Vista-orientated version.
That may cost you money, but if they can hide the details in a way
that is robustly in line with Vista's design, the value added may well
be worth it. Installers may be close to the advice one hears about
encryption; "don't try to roll your own, rather user one that works"
OTOH, if the installer vendor is still "huh?" on the way Vista works,
and appears to mired in approach (1), find something else ;-)
AFAIK, the design intention of Vista is that a bone fide installation
process can write to and populate restricted areas such as "Program
Files", but thereafter the normal operation of the sware should not
attempt to change these. IOW, you'd treat the code installation
footprint as "read-only", perhaps designed to be writable only by your
own designated update facility, whereas everything that needs to be
touched in runtime is stored on a per-user basis.
The problem comes to settings that you wish to apply across all users,
and the answer is probably to access the new "shared" store that may
also be where the "system" stuff is virt'ing to.
To some extent, use of %variables% may allow you to gloss over the
changes such that your dev will work for both Vista and XP, but there
may well be limits to how far that will go.
Our current installer also allows the user to select which folder they
want to install our software to
That's a good feature; don't lose that ;-)
Seriously, I often gong apps clean out of the selection ring because
they force me to locate their code and data in fixed locations.
For best marks, allow user-settable paths for:
- program code
- inactive material, e.g. patches, backups, .MSI, etc.
- user data and settings
- incoming material, e.g. "received files"
- Start Menu flyout, with [x] "...for all users" checkbox
This fits strategies that wish to locate programs in C:, inactive
bloat in F:, user data within a backed-up subtree off C: while
excluding incoming material (as a malware risk) from all of the above.
Specifically; do not mix or nest program code, data, and settings.
Vista would see program code under "Program Files" (so that it is
protected by the mechanisms that frustrate you for now), whereas
settings etc. would be within an AppData subtree and data would
default to within the user's Documents subtree.
If you don't do the above, then what happens is that some users will
move things around (or rename them) and then your uninstaller can't
clean up. For example, your uninstaller would miss Start Menu icons
if these were moved or renamed, and not everyone likes to be stuck
with pointless "Vendor, App, App Name " flyout structure.
thus nothing stops them from using protected folders like
program files (which is still our default folder to install to).
It's a good location to install to. You just need to scope what goes
there, so that it can enjoy the protection without the hassle.
Else any passing malware with user rights can "update" your software's
code, which is Ungood.
Problem 2: Config file writting:
So now since we can no longer write to our .cfg files in program files, we
are left to finding an alternative location for these files, or start writing
this data to some other non standard madeup extension file other then .cfg.
The suggested fix there is to nest these within your own space in
AppData subtree. If the data is small, it may be acceptable to use a
fixed subtree name within this space, rather than off the user the
ability to change it, or you can store your own pointers to this and
other paths within HKLM\Software\YourSubTree
Don't mix code and material that needs real-time updating in the same
place, even if you can find ways to do this. I can see trends that
may break the desirability of this in the future, along similar lines
as the concept behind DEP (No-eXecute).
If you get this right, you position your app for readiness for running
from optical or otherwise write-protected storage. There may also be
efficiencies if material is known not to be subject to runtime change.
Problem 3: Unidentified Publisher:
We now have to look into how we can become an identified publisher.
That, too, is a trend that may pick up momentum and grow teeth in the
64-bit age. Already, the intention to kill unsigned drivers and
kernel access is there, even if it annoys large av vendors etc.
Problem 4: Run without Administrator:
Right now if we run manually select our software shortcut and run as
administrator, the files show up in our usuall program files folder, and
everything works as usuall. So maybe one option is to find a way to always
run our software with full admin, yet avoid the annoying warning signs
That's appropriate (if not inevitable) for certain types of software,
such as hardware diagnostics, data recovery, etc.
OTOH, if your sware has nothing to do with the system as such, and is
purely user-orientated (e.g. games, accounting apps) then strive to
work within limited rights.
This is obviously a requirement if you are trying to sell into the
space of managed IT (or may possibly grow into those shoes) but it is
becoming a necessity for home consumers as well.
without resorting to disabling UAC, which we dont want or plan on doing, as
we wouldent expect people who use our software to have to do this.
Don't force users to take system-wide risks just to use your software,
else you may find yourself left with the empty end of the Xmas cracker
Unfortunately, for the first few years of Vista at least, some folks
will disable UAC, so you have to test under those conditions too.
a better option is to do what is necessary to our software so that it fully
operates in the least permission normal accounts.
At some point, that may be the only way you're allowed to run.
This should have happened when XP pushed NT into consumerland, but it
didn't - developers could still write for Win9x and things would
generally work as long as users didn't try to use NT's strongest
security feature, i.e. limited per-user rights.
It's because of this complete disregard for XP's design goals
(especially in consumerland) that Vista is cracking the whip now, by
moving the mountain to Mahommad. If devs don't write for non-admin
accounts, Vista will force non-admin restrictions into admin accounts.
It's an ugly mess, but we mainly have app devs to blame - QuickBooks
and other accounting apps that still "need admin rights" and insist of
saving data within their installation subtree, games and children's
software that "require admin rights" to run, etc.
So don't blame the pooper-scooper (as Vista has to be) ;-)
In regards to the above problems we have found some websites that do explain
a few things, but some of this is confusing, with various possible solutions
making it difficult to select our best path forward, this is somthing that
will take some time for us to test out and discover.
I'd start by looking into MS's site, especially those sections written
with the developer community in mind. Horse's mouth, and all that.
------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope
