Re: Manifest File - Installs in Vista

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi David

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns9C08C2F9D24FEf99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxx
"Graham Mandeno" <Graham.Mandeno@xxxxxxxxxxxxx> wrote in
news:8D9E8EFB-19DE-4DAB-A1B7-4999D1442AB8@xxxxxxxxxxxxx:

Yes, I remember when life was good :-)

You mean back when everyone ran as administrator, instead of
correctly running in a user-level logon?

Yes, I do. It was a joke - hence the smiley :-)

Thank you for explaining the reasons for virtualisation in much greater
detail than I bothered to. The fact remains that its introduction caused
confusion and caused certain things to break for some people.

Because an Access file (even an MDE) gets "modified" whenever you
open it, the front-end got copied into some black hole accessible
only to the current user. Imagine my surprise when a new version
was installed "as Administrator" and the old version was still the
one that opened!

I don't know when you first discovered this in Vista, but you should
have been doing things properly as long ago as 1999, when Windows
2000 came out.

Well, perhaps you're right, but I beg to differ. My understanding of
C:\Program Files was that it was the correct place for admins to install
programs. An Access front-end is arguably a program. It contains no data
and it is used to access and manipulate data. It used to work perfectly
well for an admin to install a front-end in Program Files and a back-end in
a "shared" area where all users of the app (admins or not) had write
access - the obvious candidate on a standalone machine being the
Common_Appdata folder.

This worked well - lowly users and admins alike could open the front-end and
use it, modifying the data in the back-end. The only difference was that
lowly users did not cause the modification date on the front-end to change,
while admins did.

With Vista however, when an admin opened and closed the frontend he created
for himself a new virtualised copy. When he installed an updated version,
he found himself still using the old version.

As for Common_AppData, surely its purpose is for data which is to be shared.
It is up to the owner of that data whether or not users may modify it.
However, with Vista, a user who has legitimate write access to a file in
that location creates a virtualised copy, and the changes cannot be seen by
other users.

Does this seem right? I think not.

So now, I have reverted to good old DOS days and I install
everything in a folder that Windows knows nothing about and
therefore cannot tamper with.

Anything that used to go in Program Files\... goes in
C:\Applications\...

This is the wrong place, even though it doesn't cause virtualization
problems. It's wrong because you either have to run as an admin to
have write access to this location, or you have to manually assign
write permission for user-level logons.

I disagree. If a proper installation program (I use Inno Setup) creates
this folder and grants the required read and/or write permissions to the
appropriate user groups, how is this wrong?

I infer that you would have front-ends installed in each user's AppData
folder? For me, this has two problems: (a) it offers no protection to
read-only components that ought not to be tampered with by non-admin users
and (b) it creates a maintenance nightmare - for example, if you have five
different users who regularly use the same workstation, you need to maintaib
five concurrent copies of the same application (front-end and associated
files) on the one computer.

That's my 2c worth.

--
Cheers :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand


.

Relevant Pages

  • Re: Should programs install to All Users, Default User, or Me?
    ... What admins do is write logon scripts to make changes for all users. ... >>> "David Candy" wrote in message ... They install software on the machine. ... >>> let's say a Folder View setting change or any change whatever - I would ...
    (microsoft.public.windowsxp.general)
  • Re: MS04-015 patch
    ... as you state they are admins is something to figure. ... If you have a server with IIS, install Sus and point ... Microsoft MVP (Windows Server System: ... > install the patch for MS04-015? ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Creating an app that runs as admin
    ... to be corporate workstation installs. ... by corporate employees, which is good for the admins, ... While on a SOHo system an all-user install ...
    (microsoft.public.vb.general.discussion)
  • restricting acces to certain admins
    ... a certain group of admins should be able to install and administer ... the network components incl. ... Admins is too much, Power Users doesn't help and I couldn't find Group ... The only setup that I have found so far is creating an admin-group ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Login as local admin
    ... As i am trying to install SBS SP1, an error is displayed indicating that the ... current user must be a member of the Schema Admins and Enterprise Admins ... concern and questions about enabling the local administrator login. ...
    (microsoft.public.windows.server.sbs)