Deleting files in virtual /Program Files directories during install

[NewsArchive]

Is there any way to set up an install to purge the virtual equivalents
of the directories in /Program files that are being installed to?

We have a situation where the user dropped files into the /Program Files
directory for our application on a Vista machine (as part of tweaking
Makeover settings). Vista, of course, virtualized these files. The
problem came when we issued a new installer for this application, with
replacements for the Makeover files. The installer properly installed
the updated files into our directory under /Program Files, but the files
in the virtual directory were still out there, and overrode the new
files. We had to remove the files from the virtual directory to get the
application to work correctly.

To avoid this situation, is there any way a SetupBuilder installer can
be set up to detect virtual directories equivalent to the directories
that are being installed to, and purge them?

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

Hi Ben,

> To avoid this situation, is there any way a SetupBuilder installer can
> be set up to detect virtual directories equivalent to the directories
> that are being installed to, and purge them?

Sure:) But if you install writeable data files into program files they WILL
be put into the virtual store unless the user disables UAC.

I have just gone through this and you can easily remove the files from the
virtual store. Just note that the virtual store path is different under
Vista32 and Vista64. On Vista32 they are in:

%CSIDL_LOCA:_APPDATA%\VirtualStore\Program Files\YourFolder

on Vista64 they are in:

%CSIDL_LOCA:_APPDATA%\VirtualStore\Program Files (x86)\YourFolder

But you may need to deal with a situation where users have been mucking with
UAC and turned it on and off. I dealt with that situation by checking the
file data/time on a file that is always touched when the program opens (tps
file opened on the appframe) and based on where the most recent file was I
grabbed the data from there and placed into a subfolder in
CSIDL_COMMON_DOCUMENTS

HTH:)

Best regards,


--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

In addition to Arnor's good advice, be aware that there will be a set of
virtual files for EACH USER who has logged onto that computer and used your
program.

And CSIDL_LOCAL_APPDATA will return the path for the currently logged-in
user. So you might have to do some detective work (running elevated, of
course) to find all of them.

Jane

[NewsArchive]

Hi Jane,

> And CSIDL_LOCAL_APPDATA will return the path for the currently logged-in
> user. So you might have to do some detective work (running elevated, of
> course) to find all of them.

This is a rather nightmarish mess to deal with! THIS is exactly why
developers SHOULD have made their installs XP and Vista compatible years ago
so they wouldn't have to deal with this. This mess is exactly what awaits
developers who have put it off!

I don't even know if I have covered all the bases in this:(

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

It's been a while (2 years plus) since I spent some hours playing with
virtualization and writing the clarionmag articles about it, so my memory is
a bit fuzzy.

But one possible silver lining (and I don't have time at the moment to play
with it to verify...)
I THINK that the phantom virtualized stuff in Program Files may cease being
a problem as soon as you manifest your app with something that indicates to
Vista that it knows the rules. The original post wasn't talking about
data, but about Vista reading old executables from the virtualized area
rather than the replacements in the actual Program Files folder. I'm
guessing that his app still doesn't have a Vista-aware manifest. If you
have time to do an experiment, Arnor, I'd be interested to hear what you
discover.

Jane

[NewsArchive]

Ben,

Perhaps I misinterpreted your post, but the main problem seems to be that
your application is *not* Vista-aware?

Virtualization kicks in if the application that tries to create/copy/write
the files to Program Files is a "legacy" (not Vista-aware) application. In
this scenario, the files are redirected to the users' folder:

c:\Users\{username}\AppData\Local\VirtualStore\Pro gram Files\

The above virtualized directory is a hidden folder.

But if your application is Vista-aware, it will never see or use files from
the virtualized directory. If your application "fails" because it has
access to the virtualized directory demonstrates (IMO) that it is not a true
Vista-aware application.

What do you think?

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Jane,

> I THINK that the phantom virtualized stuff in Program Files may cease being
> a problem as soon as you manifest your app with something that indicates to
> Vista that it knows the rules. The original post wasn't talking about
> data, but about Vista reading old executables from the virtualized area
> rather than the replacements in the actual Program Files folder. I'm
> guessing that his app still doesn't have a Vista-aware manifest. If you
> have time to do an experiment, Arnor, I'd be interested to hear what you
> discover.

Sorry, been out sick since Tuesday.

I tested this pretty thoroughly for a client project and I never got
anything but the data files - i.e. files that were WRITTEN to into the
virtual store folders. I never saw non-writable files being virtualized and
I don't think that should happen in normal operation unless there is
something that writes to the executables. This exe did not have XP or Vista
manifest linked in, compiled in C5.5 with installs in SB4.

After re-reading Ben's post I don't see that he was referring to
executables, he talks about MakeOver files, which I presume are datafiles
that the application reads and writes to. If they are TPS files, then they
are opened read-write by default so they always get virtualized.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

No, they won't "always get virtualized" if the app trying to write to them
has a Vista-aware manifest. The app should give a file access error.

Jane

[NewsArchive]

Hi Jane,

> No, they won't "always get virtualized" if the app trying to write to them
> has a Vista-aware manifest. The app should give a file access error.

Correct. However if a developer adds a vista manifest to the exe I presume
the developer has a clue what he is doing and will finish the job - or at
least test the app on the target OS' <g>

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Agreed.

I'm brain-fried, Arnor... was out running around for 6 hours earlier today
shooting a match... so I may not be expressing clearly or understanding what
(if anything) our differences are...

What I was trying to say is that if an app has a manifest, Vista knows not
to virtualize. That may mean that Makeover doesn't work (I'm not using the
product and don't know how it deals with Vista.)

If you use an old (say, SB4) installer that itself doesn't have a manifest,
I'm pretty sure Vista will virtualize the exe and DLL and other files within
the individual user's profile because a non-aware executable (the SB4
installer) is trying to write to a protected area.

As I read the original question, it involved how to get rid of files in
virtual folders... and I pointed out that each user profile that has written
to them will have its own virtual copy. But if he upgrades his app to
include a manifest, Vista will expect the app "knows the rules" and will not
virtualize but will refuse to write to protected file or registry areas
unless it is running elevated.

Are we saying the same thing?

Jane

[NewsArchive]

Hi Jane,

> If you use an old (say, SB4) installer that itself doesn't have a manifest,
> I'm pretty sure Vista will virtualize the exe and DLL and other files within
> the individual user's profile because a non-aware executable (the SB4
> installer) is trying to write to a protected area.

No, the _executable_ files go into Program Files and are NOT put into the
virtual store. This is exactly the scenario that I have been dealing with
for my client lately:) I installed this program probably about 100 times on
XP, Vista32 and Vista64 in the past two months. So I'm pretty sure the
executable are never virtualized. Of course there can be exceptions to this
that I'm not aware of (sigh;)

> virtual folders... and I pointed out that each user profile that has written
> to them will have its own virtual copy. But if he upgrades his app to
> include a manifest, Vista will expect the app "knows the rules" and will not
> virtualize but will refuse to write to protected file or registry areas
> unless it is running elevated.

Correct. I had never tried that (just add the vista manifest) so I didn't
know that but I tested it out and you are, of course, absolutely correct:)

My original comment was in exasperation over this situation as I have had to
deal with this and it is not much fun<g> The fact that we still have
developers who are NOT ready to even consider designing fully windows
compatible installs is IMO appalling.

I see no reason any more to call them "Vista compatible" since this is not
something that came with vista and will go away with vista. UAC is here to
stay, I understand it's changed somewhat in Win7, but it's not going
anywhere.

As far as I know user access control has been in effect in one way or the
other since Windows NT was introduced. I certainly remember a colleague of
mine who got a Windows NT WS back in '97/'98 and he had to set up user
accounts on it and log on every time he started it. Vista and WS2008 have
introduced stricter rules, but that's all.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

I don't have anything older than SB6 on a current machine, and it's a
theoretical issue for me at this point... But I don't see how, as you say, a
non-manifested installer can install to Program Files on Vista unless it's
running as administrator somehow.

Playing for a couple of minutes... you're right - they don't get
virtualized. They just don't get installed.

If I try from a command prompt
copy c:\windows\notepad.exe "c:\program files (x86)"
I get an "Access is denied" message. So I don't see how a non-manifested,
non-elevated installer could write there.

Try the attached, which also won't put a file into Program Files.

Jane

[NewsArchive]

Hi Jane,

> Playing for a couple of minutes... you're right - they don't get
> virtualized. They just don't get installed.

Following is a list of files installed with an install that I built back in
2003 (the version on the install says 4.0.3.0) I just installed this on a
Vista machine (Vista Home Premium):

Volume in drive C is SQ004409V05
Volume Serial Number is 1A3E-303C

Directory of C:\Program Files\Icetips Calendar

03/14/2009 22:09 PM <DIR> .
03/14/2009 22:09 PM <DIR> ..
03/14/2009 22:09 PM 1,818 Icetips Calendar.log
10/25/2002 09:24 AM 2,326,528 itcalendar.exe
09/24/2002 15:32 PM 1,500,431 ITCALENDAR.HLP
09/24/2002 15:42 PM 6,056 ITCalLicence.rtf
03/14/2009 22:09 PM 1,536 ITCalnotes.tps
03/04/2002 14:03 PM 25,600 UNINSTX.EXE
01/27/2003 13:43 PM 1,443 Versions.txt
10/04/2002 15:38 PM 4,063 Welcome.rtf
8 File(s) 3,867,475 bytes
2 Dir(s) 96,399,568,896 bytes free


As you can see the folder is created correctly and the files are put there
correctly. Here is a dir listing of my virtual store folder:

Volume in drive C is SQ004409V05
Volume Serial Number is 1A3E-303C

Directory of C:\Users\Arnor\AppData\Local\VirtualStore\Program Files

07/30/2008 18:49 PM <DIR> .
07/30/2008 18:49 PM <DIR> ..
11/08/2007 10:46 AM <DIR> Adobe
02/01/2008 09:51 AM <DIR> Agenda At Once
11/04/2007 12:21 PM <DIR> ColorVision
11/06/2007 07:02 AM <DIR> Common Files
03/30/2008 16:45 PM <DIR> Jasc Software Inc
07/30/2008 18:52 PM <DIR> SoftwarePassport
06/20/2008 13:41 PM <DIR> TechSmith
08/03/2007 23:00 PM <DIR> Toshiba Registration
08/04/2007 13:58 PM <DIR> Ulead Systems
07/30/2008 18:43 PM <DIR> Yahoo!
0 File(s) 0 bytes
12 Dir(s) 96,399,560,704 bytes free

No "Icetips Calendar" folder there which means that the install was
definitely NOT virtualized.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

> c:\Users\{username}\AppData\Local\VirtualStore\Pro gram Files\

Or:

c:\Users\{username}\AppData\Local\VirtualStore (x86)\Program Files\

in Vista64:)

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

friedrich linder wrote:
> Perhaps I misinterpreted your post, but the main problem seems to be that
> your application is *not* Vista-aware?

I guess that's part of it. We've done some Vista-aware coding (e.g.
moving tables that are being written to to COMMON_APPDATA), but don't
have the app manifested for Vista.

One thing to note is that in normal operation, this app does *not* write
to anything in Program Files. The app is, however, written with
Capesoft's Makeover. The primary user was fiddling with Makeover style
files and icons, and *those* got virtualized. Then, when the next
install was sent, the app was using the virtualized Makeover files, not
the ones newly installed. The 'clear out the virtualized files upon
installation' idea seemed like one way to deal with this. If the app
was Vista-manifested, though, we would have the situation where the user
would modify the Makeover style file (outside of the app), their
modifications would be virtualized (unless we could coax them into
making the changes in administrator mode (somewhat dangerous, not to
mention getting users to understand this can sometimes be iffy), and
then the app would ignore the modifications. For now, we're having this
user copy the program to a non-Program Files directory when they want to
fiddle with Makeover settings.

Last time I played with the Vista manifest in C6, it seemed the app
wouldn't run on XP. Did I do something wrong, or am I going to have to
generate two version of the app, one manifested for XP, and one
manifested for Vista, and then have SetupBuilder install the appropriate
..exe?

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

> Last time I played with the Vista manifest in C6, it seemed the app
> wouldn't run on XP. Did I do something wrong, or am I going to have to
> generate two version of the app, one manifested for XP, and one
> manifested for Vista, and then have SetupBuilder install the appropriate
> ..exe?

Ben,

We just use SetupBuilder to apply the manifest during the installer build
and it ALWAYS works (XP or Vista).

During development we use an external manifest file in the app folder to
see what it looks like after a compile. But we never use the Clarion
stuff.

Why work hard when Friedrich will do it for you<g>?


Charles



--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------