How do I get rid of a UAC warning?

[NewsArchive]

I have a Clarion application that is called using run() from another Clarion
application. In Win7 This causes a UAC warning because the publisher is unknow.
How do I get rid of this?

Thanks and God bless you,
Brock

[NewsArchive]

Codesign your EXE.

Mike Hanson [BoxSoft]

[NewsArchive]

> Codesign your EXE.

removing the manifest on the exe used not trigger the warning. dunno if
that is still valid or not

pratik

[NewsArchive]

I thought Friedrich mentioned somewhere that once your computer
think's it should be elevated, then it changes something on the
machine so that it always thinks that, even if manifest is changed.

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve

[NewsArchive]

i wish MS would get a clue on how to protect exe & dll and be done with
it. UAC has got to be THE hands down stupidest thing they've ever done.

it only prevents devs and admins from doing their jobs properly. the
malware still knows how to propagate under the radar.

pratik

[NewsArchive]

Exactly

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

It also makes us have to study up, which we've been pretty lucky about
up to Vista<g>.

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve

[NewsArchive]

In what way? It requires the user to be prompted for applications that
perform administrative tasks. Linux does the same thing, so does Mac OS. UAC
only enforces the specifications that MS published over a decade ago. UAC
has improved system security, in the same way that the new driver
architecture broke old badly written drivers, but was a major step in the
right direction. Creating UAC compliant applications is not hard, it just
creates a bit of a learning curve. The rules are simple, and the machine
that one's software is installed onto generally doesn't belong to one, and
treating it like one's own personal playground is a bad idea. UAC stops
that, and quite rightly so.

Without UAC there is no way to stop anything from running with elevated
privileges. With UAC you introduce a useful tool that allows the user some
control. You still need to educate users, but at least now a user with basic
knowledge is a great deal safer. I disliked UAC when it was first
introduced, but as it stands it is a perfectly reasonable system, and
doesn't stop either developers or admins from doing their job, unless they
are doing something that they shouldn't be doing.

--
Regards,

Sean Cameron
CapeSoft
www.capesoft.com

Work Smarter, Not Harder!

[NewsArchive]

UAC
useless asinine code

Jim Breisch

[NewsArchive]

What's the most affordable way to code sign the .exe?

Brock

[NewsArchive]

http://www.lindersoftware.com/products_security_services.htm

That is probably the most affordable.

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve

[NewsArchive]

Lindersoft with a Comodo certificate is easily a LOT less than
anything else. It's a cost of doing business with the big kids.

---------------------------------------
Paul Blais - Hayes, Virginia

[NewsArchive]

I'm using Comodo myself, purchased through Lindersoft. It's only
$200, or thereabouts, and lasts for a few years.

Mike Hanson
www.boxsoft.net

[NewsArchive]

Get the cheapest for the most amount of time. These ones that last a year
are a waste of time...

Each time you renew it's pretty much like applying for a new one. We've got
a 3 yr comodo one IIRC.

Geoff

[NewsArchive]

like Mike said and you can create your own certificate if needed,
providing you customer accept that you install it on their machines

If they do, create on, install it through SB and you are done

Didier Le Duc
Francened

[NewsArchive]

Brock,

> I have a Clarion application that is called using run() from another
> Clarion application. In Win7 This causes a UAC warning because the
> publisher is unknow. How do I get rid of this?

First of all, never even (NEVER EVER <g>) ask your users to turn-off UAC.
In the real world, you do not have any control over the status of your
customers UAC. UAC is your friend, and not your enemy <g>

The solution is very simple and already provided in this thread. You only
have to make your application UAC- and Win7-aware to "avoid" the UAC-prompt.

The following is a very brief description of how to make an application
"UAC-aware" and Win7-compliant:

-- Standard Application:

1. Embed an UAC manifest into your main application (.EXE). A manifest
basically tells Windows how aware the program is about the recent Windows
versions (and disables "Virtualization" and unwanted legacy Installer
Detection Technology). You should include a manifest for Windows 7 because
it's fully backward compatible with all previous Windows versions.

2. Request "asInvoker" execution level privileges through the manifest for
your application.

3. Code-sign all your application files (e.g. .EXE, .DLL). Use a
certificate signed by a CA, e.g. Comodo, VeriSign, etc.

4. Your application should not depend on any administrative APIs.

5. Do not write per-user information or user-writable information to the
Program Files folder tree.

6. Do not write to any other protected Windows area (e.g. the OS drive root
folder, the "Windows" folder tree, etc.).

7. Do not write to the HKEY_LOCAL_MACHINE or any other protected registry
key.


-- Standard Installation:

1. Use an UAC-aware installation system. By default, installations run
elevated.

2. Install applications per-machine (all users) and store per-user data in
different locations.

3. Do not install Quick Launch shortcuts.

4. Never write to per-user locations from the elevated running installer.
That means, never write to the HKEY_CURRENT_USER registry key or to per-user
file locations.

5. Launch applications non-elevated at the end of the installation process.

6. Code-sign the installer. Use a certificate signed by a CA, e.g. Comodo,
VeriSign, etc.

Note: if you have to install "per-user" data, install it to a common
location and as a "first run" action of your main application, copy the data
from the common location into a per-user location.

Respect the recommended (default) locations for applications and data files,
but provide users with an option to select another installation location for
both. A true "Mixed User Application" should work elevated and
non-elevated.

That's it :-)

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Amen Friedrich. As an application developer I am there to make things
easier, better, and safer. You play by the rules to swim in the
Microsoft pool. It's what I get paid for. We are all in the change
business. Sometimes you need to take the medicine just like a user.
You run anti spyware, anti malware, and anti virus protection too. The
forces of evil work 24 x 7. It's the new price of doing business with
insurance based on assurance..

---------------------------------------
Paul Blais - Hayes, Virginia

[NewsArchive]

Hi Friedrich

If you should not write to HKEY_LOCAL_MACHINE in the registry, where do you
write application specific information like program registration detail ?

Regards

Helgard Scholtz

[NewsArchive]

Hi Helgard,

> If you should not write to HKEY_LOCAL_MACHINE in the registry, where do
> you write application specific information like program registration
> detail ?

The above statement is from the "-- Standard Application" section. You can
write to HKEY_LOCAL_MACHINE from the installer. But never write to it from
your own application because this will fail. However, you can read
HKEY_LOCAL_MACHINE from your application.

The installer has administrator execution level privileges, but your
application should run non-elevated and as a result, can't write to any
"protected" Windows area.

Does this help?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Google is your friend. <g>

http://windows.microsoft.com/en-US/windows-vista/Turn-User-Account-Control-on-or-off

http://www.petri.co.il/disable-uac-in-windows-7.htm

http://www.petri.co.il/disable_uac_in_windows_vista.htm

http://www.petri.co.il/bypass-uac-using-desktop-shortcut.htm

---
Best Regards,
Earl R Coker
www.kwiksystems.net

[NewsArchive]

Naughty naughty.

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve

[NewsArchive]

Hello EARL,
I love the one where you create the scheduled task and then run it from
a shortcut.

All,
Thanks for the ideas. I will move the code into the main application
instead of calling it with a run command. This is a 40 seat in-house program
and they don't like to spend much on extra's. The main app is only started
once a day and they don't complain about the UAC warning for it.

Brock

[NewsArchive]

Hi Friedrich

If you should not write to HKEY_LOCAL_MACHINE in the registry, where do you
write application specific information like program registration detail ?

Regards

Helgard Scholtz

[NewsArchive]

Hi Helgard,

> If you should not write to HKEY_LOCAL_MACHINE in the registry, where do
> you write application specific information like program registration
> detail ?

The above statement is from the "-- Standard Application" section. You can
write to HKEY_LOCAL_MACHINE from the installer. But never write to it from
your own application because this will fail. However, you can read
HKEY_LOCAL_MACHINE from your application.

The installer has administrator execution level privileges, but your
application should run non-elevated and as a result, can't write to any
"protected" Windows area.

Does this help?

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich

Thanks, but does that mean one can no longer write safely anywhere in the
registry from a normal application ?

In my case the installer creates an entry under
HKEY_LOCAL_MACHINE/Software/xxx and later the client receives the serial
number and that plus some controll stuff is wittten there by my program.
That was to prevent copying the program without legal registration. Should
one rather use a local file than the registry.

Regards

Helgard Scholtz

[NewsArchive]

Hi Helgard,

> Thanks, but does that mean one can no longer write safely anywhere in the
> registry from a normal application ?

Well, that's correct. But this is not "new" <g>.

15+ years ago, Windows introduced the "locked down" environment (NT,
Win2000, XP). For example, under a Windows XP "Limited User" account, users
do not have write access to the Program Files folder tree, to the Windows
folder tree, to HKEY_LOCAL_MACHINE registry, and so on. In other words, you
can't write to any protected area if you do not have sufficient rights to
perform this operation.

In the past, most users "lived" in administrator mode on XP (this changed
during the last 2-3 years) and so this was not a big problem. But today,
the "standard" for Windows XP machines in a corporate environment is to let
users operate as a "Limited User". And this might result in a support
nightmare if the developer did not follow the Windows development guidlines
("the rules").

In fact, there is nearly zero difference between a "Limited User" account on
XP and a "Standard User" account on Windows 7. What's new in Windows Vista,
2008, Windows 7 and 2008 R2 is the VERY COOL "User Account Control" (UAC).
Yes, it is cool. And why is it so cool? Because it provides
"over-the-shoulder" elevation to allow the execution of "admin" programs
from a "Standard User" account. This was impossible in XP and is a
fundamental change in the modern Windows operating systems.

> In my case the installer creates an entry under
> HKEY_LOCAL_MACHINE/Software/xxx and later the client receives the serial
> number and that plus some controll stuff is wittten there by my program.
> That was to prevent copying the program without legal registration. Should
> one rather use a local file than the registry.

Did you ever try this from a "Limited User" account on XP? It will fail if
your program writes to HKEY_LOCAL_MACHINE or to "Program Files" <g>.

In fact, the new "UAC" feature is your friend, not your foe. If an
application does not work with UAC enabled then it does also not work in a
"locked-down" environment (e.g. XP or 2000 Limited User).

There is only one way for the a software developer to survive on the long
run. You have to make the application UAC-aware (and Win7-compliant) so it
can operate on modern Windows operating systems and in locked-down
environments on XP/2000/etc.

My $.02 <g>

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Another quick note: if an application is *not* UAC-aware (aka "legacy
application") and writes to protected areas, then it will fail on "Limited
User" accounts under XP/2000. But it will succeed on Vista+ with UAC
enabled. Why? Because the "not-so-cool" UAC virtualization feature kicks
in and redirects your "internally failed" write operation to the virtual
store. And then the hell breaks loose because the data is not where you
expect it to be <g>.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Thanks Friedrich

I think I got away with it since most of my users are individuals using the
only user account set up on the machine.

I appreciate the time you took giving me this detailed explanation.

Regards

Helgard Scholtz

[NewsArchive]

> I think I got away with it since most of my users are individuals using
> the only user account set up on the machine.
>
> I appreciate the time you took giving me this detailed explanation.

You are welcome, Helgard :)

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Yes. You might try adding entries during install that are of course
static. After that I prefer appdata folder either all users or for
each user. Appdata is limited protected from users browsing since it
is a hidden folder (they can unhide them), but it is not a place that
might be accidentally deleted. If it is then you are forced to reset
back to defaults and put it back. I don't install data there but make
it on the fly then let users change what they feel they need to
change.

You should be able to set everything to run in default mode without a
registry setting after install. I've also quit using INI files and use
XML for settings. It's easier and supports more data and types of
data.

>Thanks, but does that mean one can no longer write safely anywhere in the
>registry from a normal application ?
---------------------------------------
Paul Blais - Hayes, Virginia