Dave R.

"Jimmy Brush" <jb@mvps.org> wrote in message
news:O4IiwM2rHHA.404@TK2MSFTNGP06.phx.gbl...
> Dave R. wrote:
>> "Jimmy Brush" <jb@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