Does UAC features an exception list?

  • Thread starter Thread starter Serge Wautier
  • Start date Start date
S

Serge Wautier

Hi All,

I'm using a 3rd-party SDK to develop some embedded apps. It's based on
cygwin and the make process repeatedly calls a programm called...
install.exe. Which of course pops up UAC several times each time I compile!
Let me tell you: It drives UAC crazy. Actually, it drives _ME_ crazy.

Hence I had to turn off UAC. The 3rd party support tells me "We recommend
you don't develop on Vista". Thanks very much guys. Very useful. :-(

Which leads to the question: Is there a list of exceptions for UAC
heuristics checks where I could had this program's full path?

TIA,

Serge.
http://www.apptranslator.com
 
This question has been answered at least 20 times before: no. To have such an
exception list would defeat the entire purpose of UAC.

You can disable the automatic installer detection. However, if you do and
then redistribute your app you are likely to really screw up your end users
since installers would no longer be automatically detected as needing
elevation.

Why does your executable have to be named "install.exe?"
 
Just remembered, there is one more thing you may be able to do: create a
manifest for the file and configure it to run as the invoker. I'm not sure if
that supersedes the installer detection goop, but it would be worth a shot.
 
Hi Jesper,

Thanks for your reply. Sorry to re-ask a FAQ.
Please note that this is not _my_ app and I don't want to distribute it.
This install.exe is part of cygwin, which is used by the make process of
Wavecom embedded wireless modems applications (together with the GCC
compiler). The app I'm writing is not Windows-based. It's compiled on my
Windows machine using and intended to run inside a Wavecom GSM chip, which
uses their own proprietary OS. The app is sent to the modem using X-Modem.

I certainly don't want to distribute an app that would turn off UAC! I may
be stupid but not that much ;-)

All I want is to tell MY computer that C:\OpenAT\....\install.exe is safe
and should not pop up a UAC check. I'm not sure why being able to do that
would defeat UAC as long as there is no public API to access this exception
list. ok, ok, even if it's not public, one can imagine that it wouldn't be
long before some smarty finds out and throws the info out in the wild.

And why something which is not an installer is called install.exe is beyond
my understanding. Damn, I don't even know what it does.
I just don't have any control over that.

I'll investigate the manifest route but I confess I'm not very confident: If
I can simply write a manifest to say "hey, UAC, don't be scared", this is
soon going to be a feature of all InstallShield, Wise, InnoSetup et al. Or
did I miss a boat?

Regards,

Serge.
 
I'll investigate the manifest route but I confess I'm not very confident:
If I can simply write a manifest to say "hey, UAC, don't be scared", this
is soon going to be a feature of all InstallShield, Wise, InnoSetup et al.
Or did I miss a boat?
Click to expand...

Well, OK, I guess part of the boat is that even if the user is not prompted,
the program still doesn't have Admin rights hence can't go very far if it's
an installer.
 
It works!
I created a side-by-side manifest file (install.exe.manifest) as follows and
I'm no longer annoyed.

Thanks very much.

Serge.
http://www.apptranslator.com

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="cygwin install whatever"
type="win32"
/>
<description>Description of Application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
 
Cool! That's really good to know actually. I wasn't sure if the manifest took
precedence over the installer detection. Now we know.

This is an odd design, but then again, it is cygwin. :-)

Have you tried building this with the gcc compiler that comes with the
subsystem for Unix and utilities? I wonder if that would behave differently.

Oh, and I didn't mean to imply you were stupid. It's just that if you hang
out on the newsgroups for a while you'll find that someone posts the "I want
this app to always be elevated and never ask for permission" question about
once a week. Your question was more interesting than that and I didn't quite
do it justice at first.
 
Hi Jesper,

Thanks for your reply. Sorry to re-ask a FAQ.
Please note that this is not _my_ app and I don't want to distribute it.
This install.exe is part of cygwin, which is used by the make process of
Wavecom embedded wireless modems applications (together with the GCC
compiler). The app I'm writing is not Windows-based. It's compiled on my
Windows machine using and intended to run inside a Wavecom GSM chip, which
uses their own proprietary OS. The app is sent to the modem using X-Modem.

I certainly don't want to distribute an app that would turn off UAC! I may
be stupid but not that much ;-)

All I want is to tell MY computer that C:\OpenAT\....\install.exe is safe
and should not pop up a UAC check. I'm not sure why being able to do that
would defeat UAC as long as there is no public API to access this exception
list. ok, ok, even if it's not public, one can imagine that it wouldn't be
long before some smarty finds out and throws the info out in the wild.

And why something which is not an installer is called install.exe is beyond
my understanding. Damn, I don't even know what it does.
I just don't have any control over that.

I'll investigate the manifest route but I confess I'm not very confident: If
I can simply write a manifest to say "hey, UAC, don't be scared", this is
soon going to be a feature of all InstallShield, Wise, InnoSetup et al. Or
did I miss a boat?

Regards,

Serge.
Click to expand...

A comment, Serge: (sorry to butt in)
If the filename "install.exe" is hard-wired into the code of the
installer itself somehow, and the installer won't install without the
installer having the hard-wired file name (as was the case many years
ago), the installer must be named on disk what the internal name is."
But this is an old, old method, and is rarely used today.

Otherwise, it is just a "convention" to name the installer
"install.exe", because it is more descriptive of its function. But
it's really not necessary.

I know that in Windows (or OS X), the installer name can be changed
with no hit to the installation process, as long as the file type is
correct (an executable), making it unnecessary to name the installer
"install.exe". It could be named "my blue ribbon is nifty.exe", and
it would still work normally to install the program it was designed
for..

Using the name "install.exe" was an old DOS "convention", not a hard
and fast rule.

Windows programmers "usually" use the filename "setup.exe" for the
name of a program's installer, but again, it is a"convention", rather
than a hard and fast rule.

This is possible because every executable file compiled for Windows
has a special header which tells the OS that the file is an
executable, rather than a data file, along with other necessary
information, such a pointer to the location of the first byte, and the
length of the program, making it unnecessary to hardwire the program's
name in its own code in order to be reentrant.
 
Back
Top