Configure App to Run As Administrator without prompting fo..

Neufusion · External Since: Jun 13, 2007 Posts: 3

I installed Battlefield 2142 on my Windows Vista Ultimate PC. When I
run it, the UAC prompt pops up and says it needs administrator
priveldeges. I accept and it works.

When a normal (non-admin) user logs into my PC and tries to play, it
pops up and asks for *MY* password to authorize access. I type in MY
password, accept, and it works.

I just got a call on my cell phone - "Hey, I want to play BF2142, what
is your password?". I dont want to give away my password. I want
normal users to always be able to launch the application, even if I am
not there to put my password in.

How can this be done?

Neufusion · External Since: Jun 13, 2007 Posts: 3

On Jun 13, 3:26 pm, Jimmy Brush <j....TakeThisOut@mvps.org> wrote:
> Neufusion wrote:
> > I installed Battlefield 2142 on my Windows Vista Ultimate PC. When I
> > run it, the UAC prompt pops up and says it needs administrator
> > priveldeges. I accept and it works.
>
> > When a normal (non-admin) user logs into my PC and tries to play, it
> > pops up and asks for *MY* password to authorize access. I type in MY
> > password, accept, and it works.
>
> > I just got a call on my cell phone - "Hey, I want to play BF2142, what
> > is your password?". I dont want to give away my password. I want
> > normal users to always be able to launch the application, even if I am
> > not there to put my password in.
>
> > How can this be done?
>
> If the application requires that an administrator run the program, there
> is nothing you can do short of making the users needing to run the
> program an administrator.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>
> - Show quoted text -

So kids can't play current games unless they are a system
administrator? Nice.

Jimmy Brush · External Since: May 11, 2007 Posts: 352

Neufusion wrote:
> I installed Battlefield 2142 on my Windows Vista Ultimate PC. When I
> run it, the UAC prompt pops up and says it needs administrator
> priveldeges. I accept and it works.
>
> When a normal (non-admin) user logs into my PC and tries to play, it
> pops up and asks for *MY* password to authorize access. I type in MY
> password, accept, and it works.
>
> I just got a call on my cell phone - "Hey, I want to play BF2142, what
> is your password?". I dont want to give away my password. I want
> normal users to always be able to launch the application, even if I am
> not there to put my password in.
>
> How can this be done?
>

If the application requires that an administrator run the program, there
is nothing you can do short of making the users needing to run the
program an administrator.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Jimmy Brush · External Since: May 11, 2007 Posts: 352

Neufusion wrote:
> On Jun 13, 3:26 pm, Jimmy Brush <j....RemoveThis@mvps.org> wrote:
>> Neufusion wrote:
>>> I installed Battlefield 2142 on my Windows Vista Ultimate PC. When I
>>> run it, the UAC prompt pops up and says it needs administrator
>>> priveldeges. I accept and it works.
>>> When a normal (non-admin) user logs into my PC and tries to play, it
>>> pops up and asks for *MY* password to authorize access. I type in MY
>>> password, accept, and it works.
>>> I just got a call on my cell phone - "Hey, I want to play BF2142, what
>>> is your password?". I dont want to give away my password. I want
>>> normal users to always be able to launch the application, even if I am
>>> not there to put my password in.
>>> How can this be done?
>> If the application requires that an administrator run the program, there
>> is nothing you can do short of making the users needing to run the
>> program an administrator.
>>
>> --
>> -JB
>> Microsoft MVP - Windows Shell/User
>> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>>
>> - Show quoted text -
>
> So kids can't play current games unless they are a system
> administrator? Nice.
>

Unfortunately, Microsoft can't force application developers to write
software that doesn't require Administrator privileges.

I suggest writing the game developer to see if there are any plans to
release a patch to make it not require admin power.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Neufusion · External Since: Jun 13, 2007 Posts: 3

On Jun 14, 8:28 am, Jimmy Brush <j....RemoveThis@mvps.org> wrote:
> Neufusion wrote:
> > On Jun 13, 3:26 pm, Jimmy Brush <j....RemoveThis@mvps.org> wrote:
> >> Neufusion wrote:
> >>> I installed Battlefield 2142 on my Windows Vista Ultimate PC. When I
> >>>runit, the UAC prompt pops up and says it needsadministrator
> >>> priveldeges. I accept and it works.
> >>> When a normal (non-admin) user logs into my PC and tries to play, it
> >>> pops up and asks for *MY*passwordto authorize access. I type in MY
> >>>password, accept, and it works.
> >>> I just got a call on my cell phone - "Hey, I want to play BF2142, what
> >>> is yourpassword?". I dont want to give away mypassword. I want
> >>> normal users to always be able to launch the application, even if I am
> >>> not there to put mypasswordin.
> >>> How can this be done?
> >> If the application requires that anadministratorrunthe program, there
> >> is nothing you can do short of making the users needing torunthe
> >> program anadministrator.
>
> >> --
> >> -JB
> >> Microsoft MVP - Windows Shell/User
> >> Windows Vista Support FAQ -http://www.jimmah.com/vista/-Hide quoted text -
>
> >> - Show quoted text -
>
> > So kids can't play current games unless they are a system
> >administrator? Nice.
>
> Unfortunately, Microsoft can't force application developers to write
> software that doesn't requireAdministratorprivileges.
>
> I suggest writing the game developer to see if there are any plans to
> release a patch to make it not require admin power.
>
> --
> -JB
> Microsoft MVP - Windows Shell/User
> Windows Vista Support FAQ -http://www.jimmah.com/vista/- Hide quoted text -
>
> - Show quoted text -

They were able to play as Standard Users in XP. No admin rights.

Jimmy Brush · External Since: May 11, 2007 Posts: 352

>
> They were able to play as Standard Users in XP. No admin rights.
>

Then they should be able to play on Vista without admin rights.

If it is asking for your admin password when it starts, this is because
the game itself is telling Windows that it needs admin rights.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb RemoveThis @mvps.org> wrote in message
news:%23fbX6Y1rHHA.4888@TK2MSFTNGP03.phx.gbl...
>>
>> They were able to play as Standard Users in XP. No admin rights.
>>
>
> Then they should be able to play on Vista without admin rights.
>

That's just not true. Vista has changed enough directory and registry
permissions to require administrator priviliges that didn't require them
before that many applications that could run under standard accouns can
no longer do so.

> If it is asking for your admin password when it starts, this is
> because the game itself is telling Windows that it needs admin rights.

Not necessarily. It could also be attempting file and/or registry
access in areas that now require administrator priviliges. It could
also be launching unfortunately named executables that Vista flags as
"installers", so now require administrator permissions ro run.

Bottom line, Vista changed the Windows security landscape sufficiently
that your statements, although probably true in previous Windows upgrade
situations, are no longer valid.

Regards,

Dave

Jimmy Brush · External Since: May 11, 2007 Posts: 352

Dave R. wrote:
> "Jimmy Brush" <jb.TakeThisOut@mvps.org> wrote in message
> news:%23fbX6Y1rHHA.4888@TK2MSFTNGP03.phx.gbl...
>>> They were able to play as Standard Users in XP. No admin rights.
>>>
>> Then they should be able to play on Vista without admin rights.
>>
>
> That's just not true. Vista has changed enough directory and registry
> permissions to require administrator priviliges that didn't require them
> before that many applications that could run under standard accouns can
> no longer do so.
>

I am aware of only minor changes in this regard, that would be protected
by virtualization for non-compliant apps anyway. I would love to be
proved wrong, however.

>> If it is asking for your admin password when it starts, this is
>> because the game itself is telling Windows that it needs admin rights.
>
> Not necessarily. It could also be attempting file and/or registry
> access in areas that now require administrator priviliges. It could
> also be launching unfortunately named executables that Vista flags as
> "installers", so now require administrator permissions ro run.

An application only asks for admin power when either the system has
detected it is an installer, the game is programmed to ask for admin
power, or it has a compatibility issue that has been flagged by
Microsoft and requires an update.

I doubt the game itself is named setup.exe.

So that means it's totally in the application developer's court to fix
the issue.

If the game was in fact running an installer on startup, a standard user
could click cancel on the UAC prompt to stop the updater from running,
and then continue with the game. If the game had a dependency on that
installer, it would fail in both XP and Vista.

As for virtualization and permissions issues in general, the game
actually has a much greater chance of successfully running on Vista
without admin power than it would have in XP.

Virtualization works by allowing stubborn programs to work by letting
them think they are writing to protected locations when in fact they are
not.

XP has no such mechanism.

> Bottom line, Vista changed the Windows security landscape sufficiently
> that your statements, although probably true in previous Windows upgrade
> situations, are no longer valid.

Many, many more programs work in Vista as a standard user than what
worked in XP as a standard user.

The security landscape has certainly changed, but MS has done a lot to
make sure programs work in the new landscape, much more than they EVER
did to make sure programs work as a standard user in XP.

> Regards,
>
> Dave
>
>

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
news:O4IiwM2rHHA.404@TK2MSFTNGP06.phx.gbl...
> Dave R. wrote:
>> "Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
>> news:%23fbX6Y1rHHA.4888@TK2MSFTNGP03.phx.gbl...
>>>> They were able to play as Standard Users in XP. No admin rights.
>>>>
>>> Then they should be able to play on Vista without admin rights.
>>>
>>
>> That's just not true. Vista has changed enough directory and
>> registry permissions to require administrator priviliges that didn't
>> require them before that many applications that could run under
>> standard accouns can no longer do so.
>>
>
> I am aware of only minor changes in this regard, that would be
> protected by virtualization for non-compliant apps anyway. I would
> love to be proved wrong, however.

It may very well be that Vista's virtualization handles most attempts to
do this. However, given how imperfectly we humans write software, it
wouldn't surprise me at all that there are flaws in Vista's technique
that allow some things to fall through the cracks. I have not
personally experienced anything where I can point to a failure in
virtualization as the cause, I'm just putting it out as a possibility.
Who knows if any of the myriad of postings about this type of problem
are due to such a flaw?

>>> If it is asking for your admin password when it starts, this is
>>> because the game itself is telling Windows that it needs admin
>>> rights.
>>
>> Not necessarily. It could also be attempting file and/or registry
>> access in areas that now require administrator priviliges. It could
>> also be launching unfortunately named executables that Vista flags as
>> "installers", so now require administrator permissions ro run.
>
> An application only asks for admin power when either the system has
> detected it is an installer, the game is programmed to ask for admin
> power, or it has a compatibility issue that has been flagged by
> Microsoft and requires an update.
>
> I doubt the game itself is named setup.exe.
>

It doesn't have to be called setup.exe. The file name just has to
contain the word "setup", or "install", or any number of other text
strings (and BTW, I'd love to see an official MS publication that lists
them all, if you can point me to one), or be "detected" as an installer
through other means that I'm not clear on. I do know from personal
experience that simply changing the name of an executable is somethimes
all that is needed to fix a Vista compatibility problem. And I do mean
that was all that is needed. No other code changes, just a name change.

> So that means it's totally in the application developer's court to fix
> the issue.

Although true to some extent, you have to admit that that doesn't tell
the complete story. MS deserves, and has to accept, some of the heat
for this. After all, the application didn't change, MS changed the
rules. If MS hadn't changed the rules, the application wouldn't need to
change.

>
> If the game was in fact running an installer on startup,

But again, it doesn't have to be an installer, it just has to be
"detected" as one by Vista.

> a standard user could click cancel on the UAC prompt to stop the
> updater from running, and then continue with the game.

Not if the application relies on a valid response from the utility (I'm
calling it a "utility" for lack of a better generic term, since it
doesn't have to be an updater or installer). Imagine a utility called
"UpdateRegistration.exe" that sends back to the main application a
status of DoItNow or DoItLater. The application can run if either
response is received, but if Vista/UAC prevents it from running then
neither response is sent and the main application believes it is being
tampered with and fails.

> If the game had a dependency on that installer, it would fail in both
> XP and Vista.

Not in my above example. And all that would be required to fix the
above would be a name change from "UpdateRegistration.exe" to
"FinishRegistration.exe" or something similar. Of course, that does
depend on the application being in current development, which certainly
isn't the case for all applications that are being moved to the Vista
environment.

> As for virtualization and permissions issues in general, the game
> actually has a much greater chance of successfully running on Vista
> without admin power than it would have in XP.

I'll take this at face value since I don't know if they have a "much
greater chance" under Vista as a non-admin or not. I'd like to believe
that is the case, and I do believe that MS has tried its best to
minimize the impact of the changes, but I also know from personal
experience that their efforts aren't perfect.

> Virtualization works by allowing stubborn programs to work by letting
> them think they are writing to protected locations when in fact they
> are not.

I'm not sure why you call these programs "stubborn". They were written
to a different set of rules. MS has changed the rules.

> XP has no such mechanism.

True. But some of the currently protected locations were not protected
under XP or previous versions of Windows, allowing developers to make
use of them for many, many years without problem. Now that this has
changed, this new mechanism is required to keep from breaking an
unacceptable number of older applications.

>> Bottom line, Vista changed the Windows security landscape
>> sufficiently that your statements, although probably true in previous
>> Windows upgrade situations, are no longer valid.
>
> Many, many more programs work in Vista as a standard user than what
> worked in XP as a standard user.

As above, I'll have to take that at face value. But that doesn't help
those who are encountering those situations that aren't covered.

>
> The security landscape has certainly changed, but MS has done a lot to
> make sure programs work in the new landscape, much more than they EVER
> did to make sure programs work as a standard user in XP.
>

I never said they didn't. But you were arguing that the OP couldn't
possibly be seeing what he was experiencing, when I know from personal
experience that it *is* possible.

Regards,

Dave

Jimmy Brush · External Since: May 11, 2007 Posts: 352

<snip>
> I never said they didn't. But you were arguing that the OP couldn't
> possibly be seeing what he was experiencing, when I know from personal
> experience that it *is* possible.
>
> Regards,
>
> Dave
>
>

I am not arguing over what the OP is seeing.

I am just saying that the problem he is experiencing can only be
resolved by the authors of the program, and is most likely caused by the
program itself asking for admin power, although it could be a
setup-detection issue like you said.

I hadn't thought about the scenario you described, either... that would
cause problems Smile

.

In any case, the issue here is not that the program is failing to run as
a standard user, it is that it is demanding to be ran by only an
administrator.

However, continuing on our side-conversation about application
compatibility with standard users in Vista...

AFAIK, the file/registry security settings really haven't changed all
that much from XP.

Things like you can't write to program files or modify keys in
HKEY_LOCAL_MACHINE - these are the big ones - have always been that way
in XP as a standard user.

That is why I called the apps stubborn, because it has never been
acceptable to do those things in a non-admin app, even though a lot of
developers did them anyway because they didn't know better or could get
away with it Smile

I find it highly unlikely that a program that would run as a standard
user in XP would not in Vista, although I am certainly not saying it is
impossible, and would be interested in learning about specific instances
of this happening.

As far as the rules on automatic setup recognition, you can find a
summary of what is looked for here:

http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-42...b70e-b1

I am not aware of any exhaustive list that details exactly what is done.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
news:ekevh13rHHA.4764@TK2MSFTNGP06.phx.gbl...
> <snip>
>> I never said they didn't. But you were arguing that the OP couldn't
>> possibly be seeing what he was experiencing, when I know from
>> personal experience that it *is* possible.
>
> I am not arguing over what the OP is seeing.

But you did:

Jimmy Brush wrote
> Neufusion wrote
>> They were able to play as Standard Users in XP. No admin rights.
>>
> Then they should be able to play on Vista without admin rights.
>

>
> I am just saying that the problem he is experiencing can only be
> resolved by the authors of the program,

Agreed, given that MS isn't likely to change Vista to accommodate it
(and I'm not arguing that they should, unless this really is a flaw /
bug. I think UAC and related security changes in Vista are steps in the
right direction, but I also think some aspects of the implementation
need some additional work).

> and is most likely caused by the program itself asking for admin
> power,

But from what the OP said, it really couldn't have been asking for admin
power or it would have been failing under an XP standard user account.
So unless the OP was mistaken (certainly a possibility) it has to be
some other scenario.

> although it could be a setup-detection issue like you said.
>
> I hadn't thought about the scenario you described, either... that
> would cause problems Smile

.

Tell me about it. It took me far too long to figure out why our app was
failing under a Vista standard user account but would work fine under an
XP standard user account. We didn't even have the clue of a UAC prompt
since the part of our app that was failing is a shell replacement, and
UAC is aparently a function of the Explorer shell... Sigh.

>
> In any case, the issue here is not that the program is failing to run
> as a standard user, it is that it is demanding to be ran by only an
> administrator.

Not sure I agree that the distinction applies in this case.

>
> However, continuing on our side-conversation about application
> compatibility with standard users in Vista...
>
> AFAIK, the file/registry security settings really haven't changed all
> that much from XP.
>
> Things like you can't write to program files or modify keys in
> HKEY_LOCAL_MACHINE - these are the big ones - have always been that
> way in XP as a standard user.
>
> That is why I called the apps stubborn, because it has never been
> acceptable to do those things in a non-admin app, even though a lot of
> developers did them anyway because they didn't know better or could
> get away with it Smile

>
> I find it highly unlikely that a program that would run as a standard
> user in XP would not in Vista, although I am certainly not saying it
> is impossible, and would be interested in learning about specific
> instances of this happening.

Well, according to the OP, Battlefield 2142 is an example. I can't
confirm this, as I don't have that game. The only other example I know
of is the one I experienced with our application, in a scenario similar
to what I described in my previous post. Not a main-stream situation by
any means (our app is targeted at specific businesses), but I could see
variations on that theme cropping up in consumerland.

>
> As far as the rules on automatic setup recognition, you can find a
> summary of what is looked for here:
>
> http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-42...b70e-b1
>

I had seen that resource before, and it is what pointed me to the
solution to our app failing. Unfortunately, it isn't as definitive as
it really needs to be for developers since it doesn't fully define terms
"... keywords like "install," "setup," "update," etc. ..." - OK, that's
great, but "keywords like ... etc." implies there are others. What are
the other keywords? Given that those keywords are aparently checked in
a dozen or more places, it becomes critical to know what they are.

> I am not aware of any exhaustive list that details exactly what is
> done.

I would be happy with a comprehensive list of keywords to tell our
developers to avoid. "Update" was the one that caught us, fortunately
it was in that list. I shudder to think what would have happened if the
one we stumbled over hadn't been in that list. I might still be looking
for the problem.

Regards,

Dave

Jimmy Brush · External Since: May 11, 2007 Posts: 352

Dave R. wrote:
> "Jimmy Brush" <jb.DeleteThis@mvps.org> wrote in message
> news:ekevh13rHHA.4764@TK2MSFTNGP06.phx.gbl...
>> <snip>
>>> I never said they didn't. But you were arguing that the OP couldn't
>>> possibly be seeing what he was experiencing, when I know from
>>> personal experience that it *is* possible.
>> I am not arguing over what the OP is seeing.
>
> But you did:
>
> Jimmy Brush wrote
>> Neufusion wrote
>>> They were able to play as Standard Users in XP. No admin rights.
>>>
>> Then they should be able to play on Vista without admin rights.
>>
>

I guess I didn't make myself clear there. What I meant was, if the
program did not ask for admin power and just ran as a standard user,
then it should work.

<snip>

>> and is most likely caused by the program itself asking for admin
>> power,
>
> But from what the OP said, it really couldn't have been asking for admin
> power or it would have been failing under an XP standard user account.
> So unless the OP was mistaken (certainly a possibility) it has to be
> some other scenario.

A program that "asks for admin power" on Windows Vista using a manifest
would run just fine on XP without admin power.

<snip>
> Tell me about it. It took me far too long to figure out why our app was
> failing under a Vista standard user account but would work fine under an
> XP standard user account. We didn't even have the clue of a UAC prompt
> since the part of our app that was failing is a shell replacement, and
> UAC is aparently a function of the Explorer shell... Sigh.

In order to launch an application that requires elevation you have to
launch it via ShellExecute.

So, if you were trying to start a program that UAC identified as a setup
program using CreateProcess, it would fail with ERROR_ELEVATION_REQUIRED.

The setup detection application compatibility hack certainly does carry
along with it some collateral damage.

>> In any case, the issue here is not that the program is failing to run
>> as a standard user, it is that it is demanding to be ran by only an
>> administrator.
>
> Not sure I agree that the distinction applies in this case.

You may be correct.

<snip>
> I would be happy with a comprehensive list of keywords to tell our
> developers to avoid. "Update" was the one that caught us, fortunately
> it was in that list. I shudder to think what would have happened if the
> one we stumbled over hadn't been in that list. I might still be looking
> for the problem.

I will see if I can dig into this a little more and come up with a
better list Smile

.

> Regards,
>
> Dave
>
>

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Jimmy Brush · External Since: May 11, 2007 Posts: 352

> I will see if I can dig into this a little more and come up with a
> better list Smile

.
>

I dug into the Windows application compatibility database, which is
tasked with identifying "general" installer-type programs, and this is
the best list I could come up with:

Matches based on file names

*patch* (EXCEPT adpatch.exe, dispatch.exe, dispatcher.exe, and
WIDispatcher.exe)
*uninst*
*update*
*instal*
*setup*
UNWISE.exe
UNWISE32.EXE
artpschd.exe

Matches based on version information

COMPANY_NAME="*Update*"
COMPANY_NAME="*Instal*"
COMPANY_NAME="*Setup*"
PRODUCT_NAME="*Update*"
PRODUCT_NAME="WinSFX32* for Win32"
PRODUCT_NAME="*Instal*"
PRODUCT_NAME="*Setup*"
INTERNAL_NAME="TSULoader"
INTERNAL_NAME="*Update*"
INTERNAL_NAME="*Instal*"
INTERNAL_NAME="*Setup*"
16BIT_DESCRIPTION="STUB.exe" and 16BIT_MODULE_NAME="GLBSSTUB"
FILE_DESCRIPTION="RTPatch Executable"
FILE_DESCRIPTION="*uninst*"
FILE_DESCRIPTION="*update*"
FILE_DESCRIPTION="*Instal*"
FILE_DESCRIPTION="*Setup*"
ORIGINAL_FILENAME="stub32i.exe" (excluding some specific installshield
exe's)
ORIGINAL_FILENAME="*Update*"
ORIGINAL_FILENAME="*Instal*"
ORIGINAL_FILENAME="*Setup*"

Plus some translations into japanese that I can't type.

There are a boat-load of "exceptions" and specific installer-detection
rules in addition to these general rules that I didn't mention, because
they target a specific file from a specific vendor and you shouldn't be
able to hit those.

You can download the application compatibility toolkit and play with the
complete database yourself:

http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581...b0-b45e

There is also a separate installer detection routine that lives inside
of Windows that detects specific installers that the application
compatibility shim engine can't handle detection for, but again these
are for specific installers so you shouldn't hit them.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb.TakeThisOut@mvps.org> wrote in message
news:umo2MM6rHHA.4180@TK2MSFTNGP04.phx.gbl...
>> I will see if I can dig into this a little more and come up with a
>> better list Smile

.
>>
>
> I dug into the Windows application compatibility database, which is
> tasked with identifying "general" installer-type programs, and this is
> the best list I could come up with:
>
> Matches based on file names
>
> *patch* (EXCEPT adpatch.exe, dispatch.exe, dispatcher.exe, and
> WIDispatcher.exe)
> *uninst*
> *update*
> *instal*
> *setup*
> UNWISE.exe
> UNWISE32.EXE
> artpschd.exe
>
> Matches based on version information
>
> COMPANY_NAME="*Update*"
> COMPANY_NAME="*Instal*"
> COMPANY_NAME="*Setup*"
> PRODUCT_NAME="*Update*"
> PRODUCT_NAME="WinSFX32* for Win32"
> PRODUCT_NAME="*Instal*"
> PRODUCT_NAME="*Setup*"
> INTERNAL_NAME="TSULoader"
> INTERNAL_NAME="*Update*"
> INTERNAL_NAME="*Instal*"
> INTERNAL_NAME="*Setup*"
> 16BIT_DESCRIPTION="STUB.exe" and 16BIT_MODULE_NAME="GLBSSTUB"
> FILE_DESCRIPTION="RTPatch Executable"
> FILE_DESCRIPTION="*uninst*"
> FILE_DESCRIPTION="*update*"
> FILE_DESCRIPTION="*Instal*"
> FILE_DESCRIPTION="*Setup*"
> ORIGINAL_FILENAME="stub32i.exe" (excluding some specific installshield
> exe's)
> ORIGINAL_FILENAME="*Update*"
> ORIGINAL_FILENAME="*Instal*"
> ORIGINAL_FILENAME="*Setup*"
>
> Plus some translations into japanese that I can't type.
>
> There are a boat-load of "exceptions" and specific installer-detection
> rules in addition to these general rules that I didn't mention,
> because they target a specific file from a specific vendor and you
> shouldn't be able to hit those.
>
> You can download the application compatibility toolkit and play with
> the complete database yourself:
>
> http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581...b0-b45e
>
> There is also a separate installer detection routine that lives inside
> of Windows that detects specific installers that the application
> compatibility shim engine can't handle detection for, but again these
> are for specific installers so you shouldn't hit them.
>
>

Thanks much for the research and the link, this looks like it will help
make our efforts in Vista less painful. I'll pass the info along to our
development group.

Regards,

Dave

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
news:e5bof34rHHA.1172@TK2MSFTNGP03.phx.gbl...
> Dave R. wrote:
>> "Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
>> news:ekevh13rHHA.4764@TK2MSFTNGP06.phx.gbl...

<snip>

>
> A program that "asks for admin power" on Windows Vista using a
> manifest would run just fine on XP without admin power.

Did you mean "A program *that doesn't actually need admin power* that
"asks for admin power" on Windows Vista using a manifest would run just
fine on XP without admin power." ? If not, I guess I don't understand
how that could be.

>
> <snip>
>> Tell me about it. It took me far too long to figure out why our app
>> was failing under a Vista standard user account but would work fine
>> under an XP standard user account. We didn't even have the clue of a
>> UAC prompt since the part of our app that was failing is a shell
>> replacement, and UAC is aparently a function of the Explorer shell...
>> Sigh.
>
> In order to launch an application that requires elevation you have to
> launch it via ShellExecute.
>
> So, if you were trying to start a program that UAC identified as a
> setup program using CreateProcess, it would fail with
> ERROR_ELEVATION_REQUIRED.
>
> The setup detection application compatibility hack certainly does
> carry along with it some collateral damage.
>

Thanks for the explanation - and for agreeing that the setup detection
is at best a hack Smile

<snip>

>> I would be happy with a comprehensive list of keywords to tell our
>> developers to avoid. "Update" was the one that caught us,
>> fortunately it was in that list. I shudder to think what would have
>> happened if the one we stumbled over hadn't been in that list. I
>> might still be looking for the problem.
>
> I will see if I can dig into this a little more and come up with a
> better list Smile

.
>

Thank you for that, and I see that you have posted the results of your
research in another post.

Regards,

Dave

Jimmy Brush · External Since: May 11, 2007 Posts: 352

Dave R. wrote:
> "Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
> news:e5bof34rHHA.1172@TK2MSFTNGP03.phx.gbl...
>> Dave R. wrote:
>>> "Jimmy Brush" <jb.RemoveThis@mvps.org> wrote in message
>>> news:ekevh13rHHA.4764@TK2MSFTNGP06.phx.gbl...
>
> <snip>
>
>> A program that "asks for admin power" on Windows Vista using a
>> manifest would run just fine on XP without admin power.
>
> Did you mean "A program *that doesn't actually need admin power* that
> "asks for admin power" on Windows Vista using a manifest would run just
> fine on XP without admin power." ? If not, I guess I don't understand
> how that could be.

Yes, that is what I mean. I know it sounds crazy, but I still think it
is the most likely scenario.

<snip>

>
> Thank you for that, and I see that you have posted the results of your
> research in another post.
>
> Regards,
>
> Dave
>
>

You're welcome Smile

.

--
-JB
Microsoft MVP - Windows Shell/User
Windows Vista Support FAQ - http://www.jimmah.com/vista/

Dave R. · External Since: Jan 02, 2007 Posts: 128

"Jimmy Brush" <jb RemoveThis @mvps.org> wrote in message
news:Opft%235nsHHA.208@TK2MSFTNGP06.phx.gbl...
> Dave R. wrote:
>> "Jimmy Brush" <jb RemoveThis @mvps.org> wrote in message
>> news:e5bof34rHHA.1172@TK2MSFTNGP03.phx.gbl...
>>> Dave R. wrote:
>>>> "Jimmy Brush" <jb RemoveThis @mvps.org> wrote in message
>>>> news:ekevh13rHHA.4764@TK2MSFTNGP06.phx.gbl...
>>
>> <snip>
>>
>>> A program that "asks for admin power" on Windows Vista using a
>>> manifest would run just fine on XP without admin power.
>>
>> Did you mean "A program *that doesn't actually need admin power* that
>> "asks for admin power" on Windows Vista using a manifest would run
>> just fine on XP without admin power." ? If not, I guess I don't
>> understand how that could be.
>
> Yes, that is what I mean. I know it sounds crazy, but I still think it
> is the most likely scenario.
>

I agree it sounds crazy, but possible. Without further information from
the OP we may never know.

Regards,

Dave

junkgito6 · External Since: Aug 05, 2007 Posts: 1

>>
>> > When a normal (non-admin) user logs into my PC and tries to play, it
>> > pops up and asks for *MY* password to authorize access. I type in MY
>> > password, accept, and it works.
>>
>> > I just got a call on my cell phone - "Hey, I want to play BF2142, what
>> > is your password?". I dont want to give away my password. I want
>> > normal users to always be able to launch the application, even if I am
>> > not there to put my password in.
>>
>> > How can this be done?
>>
>> If the application requires that an administrator run the program, there
>> is nothing you can do short of making the users needing to run the
>> program an administrator.
>>
>
> So kids can't play current games unless they are a system
> administrator? Nice.
>
You can try the solution on www.robotronic.de/runasspcen.html
With that tool you can run an application in another user context.
The account information to run the application are reading from an encrypt
file.