Win7 VirtualStore Weirdness with Excel 2002 and earlier

[Greg Lovern]

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.

Do you mean opening the copy of the add-in in VirtualStore instead of
the one in the installed path? Excel doesn't know it's doing that.
Excel thinks it has it opened from the installed path, and it opens it
from there because there is an OPENx line for it in the registry.

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 2002in
W7.

Sorry, I don't know. Probably not many. But some people do run old
versions of Excel on new operating systems; I recently had a client
using Mac Excel v. X (from 2001) on a recent Mac with a recent Mac
OS.

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.

The setup program starts with an uninstall of the old, then installs
the new to the same path and filenames.


Greg

 

[Peter T]

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.

Pretty sure by default standard users don't have permission to Write to C:\
but I'll stand corrected. Might be worth checking though for other users.

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.

You mean from C:\, but there'd be no problem Read'ing from C for any user
unless unusually restricted

Regards,
Peter T

 

[Greg Lovern]

You mean from C:\, but there'd be no problem Read'ing from C for any user
unless unusually restricted

I mean from C:\<My Folder>\<My App Folder>\<My Add-in File>. My point
was that when Excel 2002 loaded that add-in, it was not redirected to
VirtualStore, as it is when Excel 2002 loads the same add-in from C:
\Program Files\<My App Folder>\<My Add-in File>.


I've now modified PDW setup to swap in the windows drive letter in
case it's not C, so it's now installing to:

<Windows Drive>:\<My Folder>\<My App Folder>\<My Add-in File>.

Of course, that's just the default path offered to the user; the user
can then customize the path as desired.


Greg

 

[Peter T]

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.

Do you mean opening the copy of the add-in in VirtualStore instead of

the one in the installed path?

Yes

Excel doesn't know it's doing that.

Excel thinks it has it opened from the installed path, and it opens it
from there because there is an OPENx line for it in the registry.

I can't recreate but I'm intrigued as to why Excel would read from
VirtualStore rather than the OPENx path, notwithstanding what you've already
reported about that.

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.

The setup program starts with an uninstall of the old, then installs

the new to the same path and filenames.

To clarify,
- the addin is uninstalled, is that myAddin.Installed=false or with Excel
closed via the registry

- the old file is moved from the OPENx path to VirtualStore,

- the new file with same name is then copied to the original OPENx path

- An identical OPENx is recreated, though maybe the 'x' is a tad different

- Excel opens the old file that's been moved to VirtualStore, remind me
again what's the addins("myAddin").fullname and when open
Thisworkbook.Fullname

Regards,
Peter T

 

[Peter T]

Peter T brought next idea :

The coercion implemented by M$ is just that! Not a rule nor wrtitten law!

"Coercion", not sure I follow the term with respect to permissions

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.

For typical addins installed by the User there's nothing wrong at all with
putting them in the default addins folder, quite the contrary. It means
they'll immediately appear in the addins list, and when finished with easily
removed and no left over entries in the registry to manually remove.

Yeah not supposed to use Program FIles for anything other than Programs!

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.

Any reason why not ?

Regards,
Peter T

 

[Peter T]

You mean from C:\, but there'd be no problem Read'ing from C for any user
unless unusually restricted

I mean from C:\<My Folder>\<My App Folder>\<My Add-in File>. My point
was that when Excel 2002 loaded that add-in, it was not redirected to
VirtualStore, as it is when Excel 2002 loads the same add-in from C:
\Program Files\<My App Folder>\<My Add-in File>.


FYI, I logged in as a standard user in W7, opened Explorer and tried to
create a new folder in C:\ After several seconds I got the UAC dialog asking
for an administrator password to give permission to make the change.

Regards,
Peter T

 

[Greg Lovern]

I can't recreate but I'm intrigued as to why Excel would read fromVirtualStorerather than the OPENx path, notwithstanding what you've already
reported about that.

It might help if you scan through the thread on VirtualStore I linked
to in one of my posts in this thread.

Excel does not know that it's reading the file from VirtualStore.
Excel does not know anything about VirtualStore. Excel thinks it's
reading the file from the OPENx path. Windows 7 silently redirects it
to the VirtualStore path, without Excel knowing about the redirect
(referring to Excel 2002 and earlier, with an add-in installed under
Program Files).

To clarify,
- the addin is uninstalled, is that myAddin.Installed=false or with Excel
closed via the registry

No, I mean uninstalled from Windows; same as going to the Programs
control panel and uninstalling it. The installer code does not
automate each installed version of Excel to uninstall the add-in
through Excel's object model.

- the old file is moved from the OPENx path toVirtualStore,

No, nothing happens to VirtualStore during setup or uninstall.

The file is moved to VirtualStore when Excel opens it, and no file of
the same name and path already exists in VirtualStore.

- the new file with same name is then copied to the original OPENx path
Yes.


- An identical OPENx is recreated, though maybe the 'x' is a tad different

The installer code makes sure there is one and only one OPENx line
pointing to the add-in being installed.

- Excel opens the old file that's been moved toVirtualStore,

Excel opens the file at the OPENx line, but Windows 7 silently
redirects it to VirtualStore. If there was already a file by that name
and path in VirtualStore, that's the one that Windows gives Excel. If
there was not already a file by that name and path there, then Windows
7 copies the file in the OPENx path to VirtualStore, and gives that
one to Excel.

remind me
again what's the addins("myAddin").fullname and when open
Thisworkbook.Fullname

addins("myAddin").fullname and Thisworkbook.Fullname both point to the
OPENx path.

Nothing in Excel points to the VirtualStore path. One way you can tell
that is has been redirected to the VirtualStore path is that if you
edit the add-in and save the change, the file in the OPENx path is not
updated, but the file in the VirtualStore path is updated. Again this
is in reference to Excel 2002 and earlier, and add-ins installed under
Program Files.


Greg

 

[Greg Lovern]

FYI, I logged in as a standard user in W7, opened Explorer and tried to
create a new folder in C:\ After several seconds I got the UAC dialog asking
for an administrator password to give permission to make the change.

I could be confused; wouldn't be the first time. If it doesn't work
with standard users, I guess I'll just delete it from the logged in
user's VirtualStore. There shouldn't be a permissions problem with
deleting a file from the logged in user's VirtualStore.

That won't fix other users, so maybe I'll just add an entry to my faq
about deleting the file from VirtualStore when upgrading, not that
anyone will read that, but when and if questions come in about not
seeing the new version of the add-in after upgrading, I can point them
to the faq entry. Probably very few if any users would be affected; it
would be users of Excel 2002 and earlier on Windows 7, who were not
the logged in user at the time the add-in was upgraded.

If there is a better solution, I'm all ears!


Greg

 

[GS]

Peter T presented the following explanation :

"Coercion", not sure I follow the term with respect to permissions


For typical addins installed by the User there's nothing wrong at all with
putting them in the default addins folder, quite the contrary. It means
they'll immediately appear in the addins list, and when finished with easily
removed and no left over entries in the registry to manually remove.

Yeah not supposed to use Program FIles for anything other than Programs!


Any reason why not ?

Regards,
Peter T

Coercion: referring to the implied suggestion to put our app files in
various places to appease M$'s UAC policies. I just feel we should be
able to put our apps wherever we please (within reason, of course)
without anyone raising a rucuss over it.<g>

The default 'Addins' folder is fine for XLA only projects, but not for
multi-file apps. If apps need permission to write files in their
folders then those apps don't qualify as XLA only projects, and so IMO
shouldn't be put in the default 'Addins' folder.

 

[GS]

The NTFS permissions EXE sets up your C:\Folder so that it can be used
with full access by all users (if you choose to go that route).

 

[Peter T]

Peter T presented the following explanation :

Coercion: referring to the implied suggestion to put our app files in
various places to appease M$'s UAC policies. I just feel we should be able
to put our apps wherever we please (within reason, of course) without
anyone raising a rucuss over it.<g>

OK I get your drift, but I'd regard that more as enforcement than coercion.
As for being able to put our apps whereever, on one level I agree,
understanding yet alone catering for the rules is a real pain. However I
accept there are valid reasons for enforcing the policies. But the whole UAC
thing is horrible!

The default 'Addins' folder is fine for XLA only projects, but not for
multi-file apps. If apps need permission to write files in their folders
then those apps don't qualify as XLA only projects, and so IMO shouldn't
be put in the default 'Addins' folder.

You said "I'm surprised to discover that people are still putting Addins in
the Addins folder" which I read as XLAs. But of course there are other types
of addins perhaps with ancillary files which don't belong there. For sure
applications as such shouldn't go there.

Regards,
Peter T

 

[Greg Lovern]

Here are repro steps that don't use any setup program:


(These steps use standard Excel workbooks for simplicity, but the same
result happens with add-ins.)


-- Open a Windows Explorer window, go to one of these folders, and
leave the window open for monitoring:
On 32-bit Windows 7:
\Users\<logged in user>\AppData\Local\VirtualStore\Program Files
(x86)
On 64-bit Windows 7:
\Users\<logged in user>\AppData\Local\VirtualStore\Program Files

-- Open another Windows Explorer window, and go to a location that is
safe from having files be being redirected, such as the logged in
user's Documents or My Documents folder:
\Users\<logged in user>\Documents
-- In that folder, make a new test folder:
\Users\<logged in user>\Documents\Test\
-- In the test folder, make two folders, named "Version 1" and
"Version 2". Leave the window open for monitoring.

-- Open a 3rd Windows Explorer window. On 32-bit Windows 7, go to
\Program Files. On 64-bit Windows 7, go to Program Files (x86). It's
essential that this step be under \Program Files or \Program Files
(x86) depending on Windows 7 bitness. The behavior won't repro if this
folder is just anywhere.
-- Make a new folder under it named Test:
\Program Files\Test
\Program Files (x86)\Test
-- Go into the Test folder, and leave the window open for monitoring.

-- Start Excel 2002 or earlier.
-- In a new workbook, enter "Version 1" in cell A1.
-- save the file to \Users\<logged in user>\Documents\Test\Version 1\,
and name it "Test.xls":
\Users\<logged in user>\Documents\Test\Version 1\Test.xls
-- Change cell A1 to the text "Version 2". Do not save the file yet.
-- Do a File | Save As, and save the file to the "Version 2" folder:
\Users\<logged in user>\Documents\Test\Version 2\Test.xls
-- Exit Excel. You now have two files both named Test.xls which each
have different text in cell A1 and are each in a different folder.

-- Using Windows Explorer, copy \Documents\Version 1\Test.xls to:
32-bit Windows 7:
\Program Files\Test\Test.xls
64-bit Windows 7:
\Program Files (86)\Test\Test.xls
-- Start Excel 2002, do a File | Open, and open:
32-bit Windows 7:.
\Program Files\Test\Test.xls
64-bit Windows 7:
\Program Files (x86)\Test\Test.xls
-- Note that cell A1 has "version 1". Do not make any changes to the
file, and do not save the file.
-- Go to the window that is monitoring \VirtualStore\Program Files (or
Program Files (x86). Note that a new folder named "Test" has been
created. Open that folder and note that it has a copy of the file
Test.xls in it. Leave the window open there for monitoring. Note that
all you did was open the file; you did not do anything else to the
file.
-- Close Text.xls. Do not save the file.
-- Exit Excel 2002. Do not skip this step; it is essential to repro.
-- In Windows Explorer, copy \Documents\Version 2\Test.xls to the
appropriate folder below, replacing the file that was there. So the
file under Program Files is now the "Version 2" version of Test.xls:
32-bit Windows 7:
\Program Files\Test\Test.xls
64-bit Windows 7:
\Program Files (86)\Test\Test.xls

-- In Excel 2002, open that Test.xls that you just copied over.
-- Result: Cell A1 has the text "Version 1", not "Version 2" as
expected.
-- Open the VB Editor (Alt+F11), and display the Immediate pane if it
isn't already displayed (View | Immediate Window).
-- In the Immediate pane, enter this command, and press enter:
?workbooks("Test.xls").FullName, Len(workbooks("Test.xls").FullName)
-- Result -- it points to Program Files, and shows the number of
characters in the full path:
\Program Files\Test\Test.xls 30
\Program Files (x86)\Test\Test.xls 36
-- Start Excel 2003 or later, and open the same file from the same
Program Files path.
-- Result: Cell A1 has the expected text "Version 2", not "Version 1"
as shown in Excel 2002.
-- Exit Excel 2003. Do not save the file. The only instance of Excel
now running is Excel 2002, showing "Version 1".
-- Go to the Windows Explorer window where you are monitoring the
VirtualStore path. Try to delete Text.xls there.
-- Result: You get a message that the file can't be deleted because
it's open in Excel.
-- Exit Excel 2002. Do not save the file.
-- In the Windows Explorer where you are monitoring the VirtualStore
path, try again to delete Text.xls. This time the file is deleted.
-- Start Excel 2002, and open the same file again from the same path.
-- Result: This time cell A1 says "Version 2", not "Version 1" as it
did before deleting the file under VirtualStore.
-- Note that you never made any change from Excel to any file under
Program Files or Program Files (x86).
-- Note that although these steps used standard Excel workbooks for
simplicity, the same result happens with add-ins that are never
modified once deployed and that consist only of VBA code that never
saves itself or any other file.


Greg

 

[Greg Lovern]

Yeah not supposed to use Program FIles for anything other than Programs!

My add-in's folder under Program Files also gets my add-in's DLL and
its .chm helpfile.

The add-in itself is mostly just stubs that call the DLL. It is never
modified once deployed. It is not a data file.

My understanding is that Program Files is exactly where Microsoft
wants those kinds of files deployed.

Putting a file that consist only of program code, and which is never
modified once deployed, into a path reserved for data files that are
routinely modified by user actions, especially when the DLL and CHM
that the file works with are going in Program Files because that's
clearly the appropriate place for them, seems inconsistent and
pointless.


Greg

 

[Peter T]

It might help if you scan through the thread on VirtualStore I linked
to in one of my posts in this thread.

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

Okay, belatedly I've read it, educational!

Not sure though if your issues emminate from Excel 2000/2 not having the any
yet alone the correct manifest (maybe copy the excel 2003 manifest
"excel.exe.anifest" but that's a wild guess), or due to your installation of
your files in restricted folders (I'm surprised you've been able to install
in program files in a Standard User's account without problem).

Also, have your 2000/2 been installed in compatibility mode in W7 (I
mentioned before 2000 was not officially supported in Vista and as I
suspected 2002 is not in W7)
http://answers.microsoft.com/en-us/...indows-7/b1eb50a7-5d27-4d6c-af20-0f534766bcde

Regards,
Peter T

 

[Peter T]

Yeah not supposed to use Program FIles for anything other than Programs!

My add-in's folder under Program Files also gets my add-in's DLL and
its .chm helpfile.

The add-in itself is mostly just stubs that call the DLL. It is never
modified once deployed. It is not a data file.

My understanding is that Program Files is exactly where Microsoft
wants those kinds of files deployed.

Putting a file that consist only of program code, and which is never
modified once deployed, into a path reserved for data files that are
routinely modified by user actions, especially when the DLL and CHM
that the file works with are going in Program Files because that's
clearly the appropriate place for them, seems inconsistent and
pointless.
===========================================

Greg,
I take your point but it seems MS/W7 don't, at least not unless other stuff
is in place to handle it (see my post about 30 min ago).

That being the case it seems the pragmatic solution is to go with the flow,
and install in your own sub-folder in user's or common AppData, one of these
CSIDL_LOCAL_APPDATA
CSIDL_APPDATA
CSIDL_COMMON_APPDATA
or maybe somewhere even more appropriate
http://msdn.microsoft.com/en-us/library/bb762494(v=vs.85).aspx
(don't hard code, path can be returned with a combo of APIs)

Alternatively, I really don't see any harm in installing in own sub folder
in Excel's addins folder (not that I've tested for your scenario)
Application.UserLibraryPath (but not .LibraryPath)

Not sure if/how you are handling multiple users. I haven't yet worked out
how to register a dll for all users other than manually. ComAddins can be
registered as installed for all users (though they won't appear in the
addins list) but there's no global way to install an XLA into each user's
addin manager (need to do each individually).

Regards,
Peter T

 

[Peter T]

Here are repro steps that don't use any setup program:

-- Start Excel 2002 or earlier.

I can't repro as I don't have 2000/2 installed in W7. But thanks for the
detailed steps which I'll keep for future reference.

Regards,
Peter T

 

[Greg Lovern]

Not sure though if your issues emminate from Excel 2000/2 not having the any
yet alone the correct manifest (maybe copy the excel 2003 manifest
"excel.exe.anifest" but that's a wild guess), or due to your installationof
your files in restricted folders (I'm surprised you've been able to install
in program files in a Standard User's account without problem).

This is the first I've heard of the "manifest". Is there a good link
for getting a quick overview of what that's all about? A quick google
didn't turn up such a link.

Also, have your 2000/2 been installed in compatibility mode in W7 (I
mentioned before 2000 was not officially supported in Vista and as I
suspected 2002 is not in W7)http://answers.microsoft.com/en-us/office/forum/officeversion_other-o...

I did not install Excel 97, 2000, or 2002 in compatibility mode, and
other than this issue haven't had a problem with any of those Excel
versions in Vista or Windows 7.

However, I tested setting Excel 2002 to run in XP SP2 compatibility
mode on its properties page. That did resolve the problem. Thanks for
that idea, it's good to know, for those users who can handle making
that change.

I haven't tested whether it resolves the problem once it happens; what
I tested is that the problem doesn't happen in the first place if it
is running in XP compatibility mode.


Greg

 

[Greg Lovern]

I haven't tested whether it resolves the problem once it happens; what
I tested is that the problem doesn't happen in the first place if it
is running in XP compatibility mode.

I've now tested for whether it resolves the problem once it happens --
and it does. So if a customer contacts me with that problem, I can
start by just asking them to try XP compatibility mode.

Greg

 

[Peter T]

I haven't tested whether it resolves the problem once it happens; what
I tested is that the problem doesn't happen in the first place if it
is running in XP compatibility mode.

I've now tested for whether it resolves the problem once it happens --
and it does. So if a customer contacts me with that problem, I can
start by just asking them to try XP compatibility mode.

Greg

===========================================

Good to know. Sounds like the solution, particularly as it seems unlikely
many will have XL2000/2 in W7. But note XP Compatibility is n/a in "Home
Premium".

FWIW though personally I still think better to install in appData

Re manifest (your previous post), on reflection I doubt it will help, but
would be interesting to find out. Try searching your drive for
"excel.exe.manifest" where you have 2003 or 2007/10 installed. I've adapted
mine to help VBA forms will display XP style controls. Afraid though my
knowledge as to how the manifest may or not help for your scenario is
effectively zero!

Regards,
Peter T

 

[Greg Lovern]

Good to know. Sounds like the solution, particularly as it seems unlikely
many will have XL2000/2 in W7. But note XP Compatibility is n/a in "Home
Premium".

I have a computer running Windows 7 Home Premium (came with it). XP
Compatibility is available.

I think you mean "Windows XP Mode", which is completely different than
Windows XP Compatibility Mode. It's an unfortunate similarity of
terms.

"Windows XP Mode" means running Windows XP in emulation mode in
Windows 7, using Windows Virtual PC. It's a free download from MS but
does not work in Windows 7 Home Premium.

"Windows XP Compatibility Mode" just refers to right-clicking an
application's exe, going to the Compatibility tab, checking "Run this
program in compatibility mode for", and then choosing one of the
Windows XP choices in the dropdown. That *is* available on Windows 7
Home Premium.


I have Windows XP Mode running on one of my computers in Windows 7,
and I would not dream of asking even a savvy customer to set that up
just to run my program. Windows XP Mode is mainly for running 16-bit
programs, and 32-bit programs with 16-bit setup programs.

But Windowx XP Compatibility Mode is a fairly simple step that even
very nontechnical users can probably do given detailed instructions.

FWIW though personally I still think better to install in appData

Since it works in Program Files for Excel 2003 and later without
issues, and since that is the obvious place for programming code files
that do not get modified once deployed, I plan to continue with that.

If I started using appData for my DLL, the next version of Windows
would probably disallow running programming code from there!


Greg