Files Remain Hidden Even though I selected show Hidden & Protected

Hello.
We have a computer with Windows Vista Business 32bit on a Machine here in
our Lab.
We are trying to figure out why some of the files in our software are always
hidden.
We are logged in as administrator, and we have set the folder options so
that it always shows hidden files and folders, and to always show protected
operating system files. and to always show file extensions.

In windows xp we see these files in windows explorer, with no problems.
However to see them in windows vista we have to use the following application
http://farmanager.com/
With this application we can see all the hidden files in the folder, however
for some reason windows vista's explorer does not show these files, and we
can not see them even in the windows vista Dos comand prompt.

We have no idea why these files are hidden or how to make it so that they
are not hidden in windows vista, after they are installed through our
installer.
some of the file names are as follows.
_config.cfg
_sa.cfg
We are not sure if it is because vista will always hide files named this
way, we tried renaming one of the files to random dfl.bda, and then all of a
sudden we could see the file.

We appreciate all the help anyone can give us.
Thanks in advance.

 

Lab Technician

Have you searched the drive for these files?

These files may be subject to the Virtualization for Vista, this is for
non-compatible programs that store user configurable files such as .cfg,
..ini, and other user files out of the

%systemroot%\Program Files\program name, folder(s)

and places them in the

%systemroot%\Users\username\AppData\Local\VirtualStore\Program Files\program
name, folder.

If this is the case, then when you open your software programs folder In
Windows Explorer, you should see a "Show compatability files" button on the
Command Bar. Clicking this button will take you directly to the Virtual
Store folder.

 

This is the first time I have seen anything about Virtualization. Did a web
search but did not find any really useful info. What is it?

Thanks

Stan

 

Hi Stan

A little background first.

Vista is built on a new security model that is based on what's called a
"Least User Privilege" environment. What this means is that for software to
be compatible with Vista, it must be designed to run under a Standard User
account. This means that software programs are no longer allowed to write to
sensitive areas such as Program Files, System32 folder, HKey_Local_Machine
in the registry, etc.

Software developed for previous versions of Windows pretty much required
that the user must use an administrative account to use that software
because this software did write to these system wide, sensitive areas (even
though the Microsoft guidelines for developing software tried to deter this
practice). These developers designed their programs to have system wide
access, even though this was not really required. This left the system wide
open to attacks from malware that would use the privileges of the logged on
user (administrator).

Virtualization.

Going to the next level, Vista now 'requires' that software programs 'must'
use the least user privileges for software to be compatible with Vista.
Microsoft recognized that this could have a disastrous effect since so many
legacy programs would not be compatible with Vista so they implemented file
and registry Virtualization.

This Virtualization simply means that if a software program attempts to
write to a restricted area, (such as C:\Program Files\software program
folder) then that write function will be silently re-directed to a
non-restricted area, such as C:\Users\username\Local\Virtual Store\Program
Files\software program folder.

This allows the program to run as designed while still protecting the
system.

However, file and registry Virtualization is not permanent. It is only there
to allow the software developers time to update their programs to be
compatible with Vista. Virtualization will disappear sometime in the near
future and programs that are not compatible will simply not run on Vista.

Here are some links with more information, if you want to dive deeper into
this.

Common file and registry virtualization issues in Windows Vista:
http://support.microsoft.com/kb/927387

Getting to Know User Account Control: MVP Article of the Month - October
2006:
http://www.microsoft.com/technet/community/columns/secmvp/sv1006.mspx

Developer Best Practices and Guidelines for Applications in a Least
Privileged Environment:
http://msdn2.microsoft.com/en-us/library/aa480150.aspx#accprotvista_topic4

 

Thank you for your help Ronnie.

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. Its also still intersting that by using the FAR
program i listed, you can still see the files in the original folder.

Virtualization was somthing we were not very aware of in vista.
Functionally speaking our software works well in xp, and also vista however
this new virtualization is giving us some difficulties in
installing/uninstalling and updating our software, as well as some
annoyances in running our progam.

Some of the issues we are having which may be in part to the virtualiztion
and new permissions/security UAC systems are as follows:

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. This is problematic when it comes to uninstalling or
installing over our software. Thus upgrading our software is currently not
possible without manualy deleting these hidden virtualized files or their
containing folders (which is somthing we want to avoid). Our current
installer also allows the user to select which folder they want to install
our software to, thus nothing stops them from using protected folders like
program files (which is still our default folder to install to). This is
somthing we have to resolve, and i guess we may have to put limits on which
folders our software is allowed to install in, and maybe change our default
folder to somewhere else avoiding program files.

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.

Problem 3: Unidentified Publisher:
We now have to look into how we can become an identified publisher.
Basically what is necesary to avoid these warnings that pop up every time we
try running our program as administrator.
So we are searching to see what is necessary, and what this is going to cost
us.

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,
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. Also a
better option is to do what is necessary to our software so that it fully
operates in the least permission normal accounts.

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.

Any further help you can provide in terms of links or advice is greatly
appreciated.

Many thanks, for your two posts which have been very informative.

 

Lab Technician

What you really need to do is make a few changes to your program so that it
will run under standard user privileges.
This is way that programs designed for compatibility with Vista are supposed
to be configured.

I'm not a developer, but there are free developer forums where the Microsoft
developers answer questions about any stage of software development for
Vista. It's likely that they can get you up to speed very quickly. Many
times configuring a legacy program to work with Vista can be as easy as
including a simple Manifest file with the installation .exe.

Windows Vista Developer Forums:
http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=24&SiteID=1

Also, here are some links that will give you more information:

The Windows Vista Developer Story: Windows Vista Application Development
Requirements for User Account Control (UAC):
http://msdn2.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic6

Download details: Windows Vista Application Development Requirements for
User Account Control Compatibility:
http://www.microsoft.com/downloads/...69-a648-49af-bc5e-a2eebb74c16b&DisplayLang=en

 

Hello Lab Technician,

I see this effect as well, and I think it illustrates a contradiction in the "virtual
store" (VS) concept. The VS is supposed to protect the \Program Files folder by
redirecting application data to another folder with less restrictive permissions. But
applications that try to write to \Program Files are older, non-Vista apps, the very
ones that often require admin privileges to run properly under Vista. Once given the
needed privileges, the apps can and do write to \Program Files again.

As a result, I see older applications that end up with *two* sets of data and config
files. On installation, the first set is created in the VS as expected. If I give
the .exe file admin privileges to correct problems that develop after installation,
the app then creates new data and config files in \Program Files.


Hello Ronnie,

That would be a disaster for users of older applications, and I will be surprised if
MS allows that to happen. Given my observations above, it appears that at least some
older apps will still run on Vista if granted the needed privileges after
installation. That is because once an app has the needed privileges, the "virtual
store" becomes irrelevant.

The other option that users will have will be to simply lower the permissions needed
on the entire \Program Files tree, thereby restoring the ability of installers and
applications to write config files there. I'm not recommending that, but with no VS
available, surely some people will do so if needed to get vital applications to run
on Vista.

Regards,

Doug M. in NJ

 

Hi Retroman

<inline response>

The testing I have performed on this with a few different applications shows
the same behavior. However, in each case the applications files seemed to be
mirrored in both locations. When one is changed, the other shows the same
change. This occurs with no privileges being changed.

This would be a likely result, however, it would also be just as likely that
this would completely trash the new security model for Vista. I see this
changeover to a more secure version of Windows as being a very long process
that will likely go on for years.

 

Interesting, I will look for mirroring. I haven't seen it so far, although I do see
a case where the file dates and sizes are different for an application that I did not
give "run as admin" privileges. Opera 9.2 has not updated the files in its Profile
folder in \Program Files since installation. Only the Virtual Store versions are
updated daily.

I did modify some permissions in my first few days with Vista, so that muddies the
waters a bit at my end. Foolishly, I did not keep a record of exactly what I changed.
It would be nice if there was a way to reset security settings on the entire \Program
Files folder to the supplied defaults. I might see different behavior from the VS
feature.

Anyway, Ronnie, thanks for your response. I think that this area has not been given
the attention that it deserves.

Regards,

Doug M. in NJ

 

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.

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!

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.

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.

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.

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.

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.

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.

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.

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) ;-)

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

 

Would this virtualisation have anything to do with the advice seen in some
places and ridiculed in others to run installers as Admin and to set Admin
privileges on the legacy app itself/run it first time as Admin?

I have a lot of trouble with legacy apps and UAC etc. and trying to work out
what I should be doing to minimise downstream irritation.

 

I am also having a problem accessing downloaded files, but I am unable to
find the "Show compatability files" button on the