Win7 VirtualStore Weirdness with Excel 2002 and earlier

[GS]

Greg Lovern expressed precisely :

The v2010 installer won't install both bitnesses in the same
installation of Windows. I keep the two bitnesses in separate
partitions, each with its own Windows installation.

BTW if you don't already have it, EasyBCD makes multibooting with
Vista and Win7 very easy. It even lets me have Windows XP and 2000
both on my main boot menu instead of the Vista/Win7 boot menu having
one entry that goes to the legacy NT/2000/XP boot.ini boot menu.

It would be interesting to hear of a hack (Danger, Will Robinson!) to
get both Office 2010 bitnesses to install and work correctly in a
single installation of Windows, but last time I searched I didn't find
one.


Greg

One would think that WOW would handle this. I don't have EasyBCD and so
what exactly is that?

 

[GS]

Googled EasyBCD and got lots back so don't spend time posting back on
it.

 

[Peter T]

This script by KeepItCool for

VB6 does just about everything but not the new permissions stuff.

https://groups.google.com/group/microsoft.public.excel.programming/ms...

Thanks, but that only checks for the following versions:

For Each vVers In Array("11.0", "10.0", "9.0", "8.0")

That was written back in 2004 but easy enough to add newer, say up to 16
(though you'd probably want to update with each new version). I'm pretty
sure as I was involved at the time it was the first routine posted to handle
installation of addins in multiple versions. Many have adapted it and I know
Jurgen wouldn't write it quite like that again. However it doesn't detract
from the fact it covers all the essential steps, that said there were one or
two things it overlooked but off the top of my head I don't recall exactly
what.

Referring to your OP the Addin manager works in exactly the same way in all
versions since xl97, with the exception of the different key name and the
additional default addins folder introduced with xl2000 (UserLibraryPath in
addition to LibraryPath).

Garry does not appear to understand the problem behavior as
explained in my first post.

I'm afraid I don't either, or rather I don't know why 2000/2 are loading the
wrong version as I don't fully know what you are doing (also apologies I've
only scan read). Why not do something like -

for each ad in addins
with ad
debug.? .installed .title, .name, .fullname

Note Title can be very significant in some scenarios

Regards,
Peter T

 

[Peter T]

Peter T formulated on Thursday :

I don't have an Inno nor a Wise script for this. I use a VB6.Exe that I
install temporarily to the install folder, run it, then delete the file.

You can read about and download sample VB code (Part1/Part2) at:

http://www.jsware.net/jsware/vbcode.php5#perms

Yikes, but thanks!

Regards,
Peter T

 

[Greg Lovern]

One would think that WOW would handle this.

WOW64 hosts the 32-bit version of Office 2010 on 64-bit Windows, no
problem there. I would guess that the reason the installer won't
install both isn't about WOW issues but is more likely about file
conflicts on the hard drive.

It might be worth trying to install 32-bit Office 2010 in Virtual XP
Mode in 64-bit Windows 7, though (and installing 64-bit Office in the
same Windows 7 installation), if you don't mind running xl2010-32 in
XP and want to avoid multi-booting. It would be interesting to hear
whether the Office 2010 installer allows that.


Greg

 

[GS]

Peter T explained on 5/26/2011 :

Yikes, but thanks!

Regards,
Peter T

You're welcome!
It takes a bit of time to execute so I display a progress dialog while
it's executing. Otherwise, you just need to break it down to the
essential permissions you want to set. (IRC, it demos more than
necessary for most our usage for addins) So far it has worked
flawlessly for me!

 

[Greg Lovern]

Why not do something like -

for each ad in addins
with ad
debug.? .installed .title, .name, .fullname

Note Title can be very significant in some scenarios

I walked through a repro and found that all four of those properties
were the same for both Excel 2002 (old add-in version) and 2003
(correct, new add-in version).

Installed returned True, Title returned the project name, and Name
returned the add-in filename. The Fullname property pointed to the
installed path for both, but Excel 2002 was clearly actually getting
it from the VirtualStore path (Excel 2003 was getting it from the
installed path).

Also BTW, for this repro I started by clearing out all references to
the add-in for all versions of Excel under HKCU\Software
\Microsoft\Office\.

Excel 97 and 2000 had the same problem as 2002. Excel 2007 and 2010
worked correctly, like 2003.


Greg

 

[GS]

So Greg, are you ever going to say which version of Win7 you're talking
about? (x32,x64)

 

[Greg Lovern]

So Greg, are you ever going to say which version of Win7 you're talking
about? (x32,x64)

In my first post, I said:

"BTW, this was all on 32-bit Windows 7. I haven't tested this on 64-
bit
Windows 7 yet."


Greg

 

[Greg Lovern]

* * * * * I have a new repro which does not involve my installer
code. * * * * *


First, I closed all versions of Excel and cleared out all references
to my add-in under HKCU\Software \Microsoft\Office\.

Then, I renamed HKCU\Software\Microsoft\Office\10\ to HKCU\Software
\Microsoft\Office\Version Ten\ so that my installer code would skip it
(and I verified later that it did in fact skip it).

Then, I ran uninstall for my add-in.

Then, I ran the setup for a different version of my add-in.

Then, I verified that Excel 2010, 2007, and 2003 were all loading the
version of the add-in that I had just installed.

Then, I verified that Excel 97 and 2000 were loading the wrong version
of the add-in -- the version that had been previously installed.

Then, I started Excel 2002. Since I had renamed HKCU\Software\Microsoft
\Office\10\, it created a new, default HKCU\Software\Microsoft\Office
\10\ when it started up, with no add-ins.

Then, I MANUALLY went to Tools | Add-Ins |Browse, and browsed to the
add-in in the INSTALLED PATH, and clicked OK.

Result: It loaded the WRONG version of the add-in -- it loaded the
version that had been previously installed -- the one in the
VirtualStore path, NOT the one in the installed path to which I had
browsed in the Add-Ins dialog. But thisworkbook.path,
<addin>.fullname, and the new registry entry all pointed to the
installed path, not to the VirtualStore path.


I think that shows that this problem has nothing to do with my
installer code.


Greg

 

[GS]

Greg Lovern has brought this to us :

* * * * * I have a new repro which does not involve my installer
code. * * * * *


First, I closed all versions of Excel and cleared out all references
to my add-in under HKCU\Software \Microsoft\Office\.

Then, I renamed HKCU\Software\Microsoft\Office\10\ to HKCU\Software
\Microsoft\Office\Version Ten\ so that my installer code would skip it
(and I verified later that it did in fact skip it).

Then, I ran uninstall for my add-in.

Then, I ran the setup for a different version of my add-in.

Then, I verified that Excel 2010, 2007, and 2003 were all loading the
version of the add-in that I had just installed.

Then, I verified that Excel 97 and 2000 were loading the wrong version
of the add-in -- the version that had been previously installed.

Then, I started Excel 2002. Since I had renamed HKCU\Software\Microsoft
\Office\10\, it created a new, default HKCU\Software\Microsoft\Office
\10\ when it started up, with no add-ins.

Then, I MANUALLY went to Tools | Add-Ins |Browse, and browsed to the
add-in in the INSTALLED PATH, and clicked OK.

Result: It loaded the WRONG version of the add-in -- it loaded the
version that had been previously installed -- the one in the
VirtualStore path, NOT the one in the installed path to which I had
browsed in the Add-Ins dialog. But thisworkbook.path,
<addin>.fullname, and the new registry entry all pointed to the
installed path, not to the VirtualStore path.


I think that shows that this problem has nothing to do with my
installer code.


Greg

Thanks for confirming, and I apologize for not catching that you said
it was x32.

I have no doubts about your installer after all the dialog we've
exchanged here. Like I said already, it looks like you've got a good
handle on the installer requirements. I would like to see if I can
repro the problem, though, because it doesn't appear under x64/MSOx32
in WOW. I'll check this again to be sure after I test x32. It may be
awhile because I have to first find a Win7x32 machine OR upgrade one of
my XP machines. Geez.., maybe I'll get lucky and find someone who wants
to dump a Vista machine!<bg>

 

[Greg Lovern]

I found this interesting thread about VirtualStore:

http://answers.microsoft.com/en-us/...7/55dce284-0dcd-46af-892e-d2b9cf5bcff6?page=1


According to various posters in that thread:
-- The reason for VirtualStore is something about preventing
malicious software from controlling applications to make them modify
their own executable code. So after the initial install, programs are
not allowed to write to their own Program Files folder; instead they
are silently redirected to VirtualStore.
-- Although Vista had VirtualStore, it didn't enforce it, so it
wasn't an issue until Windows 7.
-- It has been such a problem with Access databases that Microsoft
has patched Windows 7 to not enforce it with Access databases. People
thought they were writing to their databases in one folder, and used a
backup program to back up that database file. But when their drive
crashed and they needed that backup, surprise, the backup had no new
data since the upgrade to Windows 7, because since then Windows 7 had
been silently redirecting their database writes to a file in
VirtualStore intead.
-- The reason the problem only affects Excel 2002 and earlier may be
something to do with those versions assuming the user is running with
full administrative privileges, where xl2003 and later do a runas to
elevate permissions when doing the file write. Or something.


But although that thread sheds some light on this issue in general, I
don't think it fully explains the issue I'm seeing -- if I understand
the thread correctly, Excel should be able to write to my add-in's
Program Files folder. And, after I uninstall the add-in and clear out
all references to it in Excel's registry entries, and install a new
version of the add-in, I don't understand why those versions of Excel
are using the old version of the add-in in VirtualStore. I'd like to
have more clarity and a good solution. Maybe killing the file in
VirtualStore during setup is a good way to go after all; as one poster
in that thread is doing.


Greg

 

[Greg Lovern]

I've done some more reading and learned that Windows 7 doesn't allow
programs to write to ANYTHING under Program Files (it's all redirected
to VirtualStore), except for setup programs.

As far as why the problem affects Excel 2002 and earlier, I recall
being told sometime when Excel 95 or 97 was current, and I was in
Excel product support at Microsoft, that Excel does a small file write
on every file that it opens. I was working a customer issue regarding
opening files across networks, in which Excel choked when opening
files from certain networks. It was explained to me that the problem
was that those networks did not allow the file writes that Excel was
trying to do on every file it opened. So...

If Excel 2002 was the last version that did that, and starting with
Excel 2003 it no longer did that small file write on all files it
opened, that would explain why Windows 7 does the redirect when Excel
2002 and earlier open my add-in from my add-in folder under Program
Files -- Excel 2002 is trying to do the small write to the file, so
Windows 7 silently redirects it to VirtualStore, because that is a
designated "safe" place to write, and anything under Program Files is
not (except for setup programs).

That would sort of work if it was a data spreadsheet that needed to be
written to, and no other program (or person, using Windows Explorer)
tried to read or write to the file in its real location under Program
Files. But the actual result is that when my setup program updates the
add-in, Excel 2002 and earlier don't know anything about that update
because what they think is my add-in file under Program Files is
really the silently redirected copy under VirtualStore.

I'm leaning toward deleting the file in VirtualStore in my setup
program as the best solution. VirtualStore isn't some special,
dangerous place we shouldn't touch; to the contrary, it's reason for
being is to be a safe place to do whatever we need to do. Such as
delete the redirected copy of the old version my add-in file, so that
Excel 2002 and earlier get a fresh copy of the version just installed
by my setup program. That fresh copy will probably be redirected too,
but that doesn't matter because once it's installed by the setup
program, there no need to modify it. So it's fine if Excel 2002 and
earlier are using redirected copies of the *correct* version of the
file.


Any thoughts? Better solutions?


Thanks,

Greg

 

[Greg Lovern]

I'm leaning toward deleting the file in VirtualStore in my setup
program as the best solution.

One potential problem with that solution -- it will only fix the user
account that is logged in when the setup program runs. If there are
other user accounts, it won't fix them, because they each have their
own VirtualStore, and the logged in user does not have permission to
write to the others. Or maybe that can be fixed by elevating
permissions.


Greg

 

[GS]

One potential problem with that solution -- it will only fix the user
account that is logged in when the setup program runs. If there are
other user accounts, it won't fix them, because they each have their
own VirtualStore, and the logged in user does not have permission to
write to the others. Or maybe that can be fixed by elevating
permissions.


Greg

Well that's a great deal of really good material and info. Thanks so
much for your efforts, and for posting your results.

Now I understand your problem completely! It explains why I don't have
this issue with my installs, and raises an issue Peter will face if he
tries to use the NTFS permissions project in his installer on 'Program
Files'.

Here's the solution I found to fix all these issues and prevent UAC
from interfering with my apps and their ability to write to their
folders/subfolders.

***DON'T INSTALL UNDER 'Program Files'***

Instead, install under 'C:\YourOwnFolder\', placing project files in
their own subfolders.

Example

C:\MyApps\ 'main folder for all your apps
C:\MyApps\App1\ '..files and any subfolders required
C:\MyApps\App2\ '..files and any subfolders required
...and so on

 

[Greg Lovern]

Here's the solution I found to fix all these issues and prevent UAC
from interfering with my apps and their ability to write to their
folders/subfolders.

     ***DON'T INSTALL UNDER 'Program Files'***

Instead, install under 'C:\YourOwnFolder\', placing project files in
their own subfolders.

Yes, thanks, that's really the best solution.

I guess this issue has been the punishment I get for following
Microsoft's convention and recommendation of putting programs (and I
think add-ins qualify as programs in that context; mine certainly
aren't data files; they are never modifed after being deployed) under
Program Files. So now it's off to something like C:\MyApps\MyApp1\ for
them.


Greg

 

[Peter T]

Now I understand your problem completely! It explains why I don't have
this issue with my installs, and raises an issue Peter will face if he
tries to use the NTFS permissions project in his installer on 'Program
Files'.

Here's the solution I found to fix all these issues and prevent UAC from
interfering with my apps and their ability to write to their
folders/subfolders.

***DON'T INSTALL UNDER 'Program Files'***

My knowledge of all the new permissions is woefully lacking but AFAIK
nothing should be writing to Program Files except setup Apps. Instead
should use local or maybe global AppData which typically should not have any
problem with permissions. Paths can be returned with SHGetSpecialFolderPath
and a couple more.

Instead, install under 'C:\YourOwnFolder\', placing project files in their
own subfolders.

Example

C:\MyApps\ 'main folder for all your apps
C:\MyApps\App1\ '..files and any subfolders required
C:\MyApps\App2\ '..files and any subfolders required
...and so on

Hmm, are you sure, maybe as an Administrator can write to the root in W7 but
otherwise isn't that restricted.

Regards,
Peter T

 

[Peter T]

I've done some more reading and learned that Windows 7 doesn't allow
programs to write to ANYTHING under Program Files (it's all redirected
to VirtualStore), except for setup programs.

As far as why the problem affects Excel 2002 and earlier, I recall
being told sometime when Excel 95 or 97 was current, and I was in
Excel product support at Microsoft, that Excel does a small file write
on every file that it opens. I was working a customer issue regarding
opening files across networks, in which Excel choked when opening
files from certain networks. It was explained to me that the problem
was that those networks did not allow the file writes that Excel was
trying to do on every file it opened. So...

Excel writes a whole bunch of temporary files in the temp directory, I can't
think of anything else.

If Excel 2002 was the last version that did that, and starting with
Excel 2003 it no longer did that small file write on all files it
opened, that would explain why Windows 7 does the redirect when Excel
2002 and earlier open my add-in from my add-in folder under Program
Files -- Excel 2002 is trying to do the small write to the file, so
Windows 7 silently redirects it to VirtualStore, because that is a
designated "safe" place to write, and anything under Program Files is
not (except for setup programs).

That would sort of work if it was a data spreadsheet that needed to be
written to, and no other program (or person, using Windows Explorer)
tried to read or write to the file in its real location under Program
Files. But the actual result is that when my setup program updates the
add-in, Excel 2002 and earlier don't know anything about that update
because what they think is my add-in file under Program Files is
really the silently redirected copy under VirtualStore.

I'm leaning toward deleting the file in VirtualStore in my setup
program as the best solution. VirtualStore isn't some special,
dangerous place we shouldn't touch; to the contrary, it's reason for
being is to be a safe place to do whatever we need to do. Such as
delete the redirected copy of the old version my add-in file, so that
Excel 2002 and earlier get a fresh copy of the version just installed
by my setup program. That fresh copy will probably be redirected too,
but that doesn't matter because once it's installed by the setup
program, there no need to modify it. So it's fine if Excel 2002 and
earlier are using redirected copies of the *correct* version of the
file.


Any thoughts? Better solutions?

Good sleuthing but I must admit I don't follow. I just tried 2000 opening a
file in a read only folder on a network (but not W7), pretty sure it didn't
try to write any new files there (other than temp in own drive). Still can't
think why Excel would be opening an addin that's not the addins collection
and installed to open when Excel starts, doesn't make sense. However I can't
test as in W7 I've only got 2003, 7 & 10.

Curiosity, do many of your users have 2000/2 in W7. I recall it was strongly
recommended not to install 2000 in Vista (I did!) but not sure about 2002 in
W7.

One more thing, are you deleting old addins after updating with new,
renaming the old or does the new have a new name, is the new going in same
folder as the old.

Regards,
Peter T

 

[Greg Lovern]

Hmm, are you sure, maybe as an Administrator can write to the root in W7 but
otherwise isn't that restricted.

It worked fine for me in Windows 7, logged in as a standard user.

VB6 Package and Deploy doesn't provide an automated way of doing that,
but I edited Setup.LST and it accepted it and installed it there. That
was just hardcoding C:\<MyFolder>; to get the system drive letter I'd
have to find it in frmSetup1.Load and swap it in to gstrDestDir, in
VB6 PDW's Setup project.

Excel 2002 was able to use the add-in there, with no redirecting to
VirtualStore.


Greg

 

[GS]

Peter T brought next idea :

My knowledge of all the new permissions is woefully lacking but AFAIK nothing
should be writing to Program Files except setup Apps. Instead should use
local or maybe global AppData which typically should not have any problem
with permissions. Paths can be returned with SHGetSpecialFolderPath and a
couple more.


Hmm, are you sure, maybe as an Administrator can write to the root in W7 but
otherwise isn't that restricted.

Regards,
Peter T

The coercion implemented by M$ is just that! Not a rule nor wrtitten
law! I'm surprised to discover that people are still putting Addins in
the Addins folder, but more so that people are still using Program
Files as of Vista.

Greg, the AppPath is hard-coded in my installer. Peter, the NTFS
permissions EXE is installed to there temporarily to set up access
permissions for that folder and all its subfolders, for all users.

I'm sure there's a "more appropriate" place to install apps and their
files but it seems program core files are being coerced in 'Program
Files' while we are also being coerced into using 'ProgramData' for any
files our apps modify. That's fine if you don't mind breaking your apps
up like that, but I won't cater to this type of coercion for any reason
whatsoever.

Keep in mind that our setup.EXEs must be 'Run as Administrator' for the
NTFS permissions EXE to work as expected.