Ultra slow recognition by Vista UAC

[NewsArchive]

I've raised this before, but I still have no solution and I'm wondering if
anyone has a successful strategy for managing it.

We have a setup file which is currently over 500MB (mainly data). With
Vista's User Access Controls on, my own laptop takes 15 minutes before Vista
asks me if I want to give permission to the program to run. One of our
clients has told me that it took 40 minutes on his PC! Our installation set
is only going to increase in size over time and I believe these wait times
will become even worse.

With UAC off, the time to initiate setup on my laptop is about 20 seconds.

Our Vista-based customers are contacting us to say that the setup disk is
faulty.

Is there some way to circumvent this idiotic delay?

Regards and thanks in anticipation,
Warren Marshall
A-TEK Systems
Sydney, Australia

[NewsArchive]

Warren,

Hum... A few things come to mind, maybe not so practical. These
both assume that, once the program has established it's access rights to
the data, the UAC will be happy. If you are distributing over the web,
maybe have the program access it and build it as via download. The
second idea is like it. Have the program access the data in a separate
file (not the install file). Once it's "established," have the program
build the data from the secondary file. Yeah, I know. Pain in the butt,
but, hey, it's progress... right? {'-)

Regards,

kurtt

Kurt Pawlikowski
The Pinrod Corporation
http://pinrod.com

[NewsArchive]

Unless I use Microsoft's brain-dead cab format, I don't know how to package
up the application files in one exe and draw on the data files in another
file.

Warren Marshall

[NewsArchive]

Hi Warren

Perhaps try this strategy...

Build two sb installers A and B

"A" is a small program just to trigger the UAC prompt, and then have it
execute "B" which is the large one with the enclosed data.

Once you have got administrator rights for "A" and it is running elevated, it may be
able to call "B" and UAC test is already satisfied.

Might work.

John Griffiths

[NewsArchive]

Hi Warren,

> I've raised this before, but I still have no solution and I'm wondering if
> anyone has a successful strategy for managing it.
>
> We have a setup file which is currently over 500MB (mainly data). With
> Vista's User Access Controls on, my own laptop takes 15 minutes before
> Vista asks me if I want to give permission to the program to run. One of
> our clients has told me that it took 40 minutes on his PC! Our
> installation set is only going to increase in size over time and I believe
> these wait times will become even worse.
>
> With UAC off, the time to initiate setup on my laptop is about 20 seconds.
>
> Our Vista-based customers are contacting us to say that the setup disk is
> faulty.
>
> Is there some way to circumvent this idiotic delay?

I think I already sent you (or your colleague) most of the following
information some months ago.

In fact, this long loading process is *NOT* caused by your setup file
itself. XP SP2, Vista and 2008 (and even Windows Seven) scan through the
hole application file and this takes some time (especially when you run from
CD/DVD and UAC is enabled on Vista/2008). It's the nature of Vista/2008.

All this happens before the application executes.

You may have noticed that the UAC dialog contains the publisher. This
information is extracted from the digital signature of the executable. That
means that before the UAC dialog can be shown, the digital signature needs
to be verified, which takes a long time on large files because it's at the
end of the .exe. Even with UAC off, Windows scans through the whole file to
find the manifest, application icon in the resource, to do code-sign
verification, etc.

On XP SP2, you'll have a similar problem. XP does not have UAC, but the
Authenticode technology that is verifying the digital signature.

In other words, this isn't just a UAC problem, but a Windows problem in
general. All large executables/MSIs are a huge problem in XPSP2, Vista,
2008+.

And on top of this, the virus-protection software products also do a
complete scan! A lot of antivirus tools have setting like "Do not scan (use
quick scan) files larger than...".

So what can you do? You can "split" your setup into multiple volumes, but
then you can't code-sign any longer (multiple-volumes cannot be
code-signed).

And what John said is great. What we do in all Setup Consulting projects
that result in large setup.exe files is the following: we create a small
code-signed "loader" application with SetupBuilder (which requests
administrator execution level privileges) and then run the (large) main
installation from that "loader". In this case, Vista/2008 checks the loader
only (execution privilege and code-sign status scan).

Does this help?

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

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I think that will work. How do I run the second setup (say setup2.exe) from
within the first (say setup1.exe)

Regards
Warren

[NewsArchive]

Hi Warren,

> I think that will work. How do I run the second setup (say setup2.exe)
> from within the first (say setup1.exe)

I'll develop and upload a source code demo...

Friedrich

[NewsArchive]

You're a champion

Regards
Warren

[NewsArchive]

Warren,

Have your install builder "call" the program with a parameter that
tells it where the source file is. Write a routine that will read the
source and build the "permanent" file. Aside from that, you can have the
program use FILEDIALOG to hunt for the source file. Maybe give it some
unique extension?

I see that Friedrich has a more elegant solution! And a lot simpler
to code!

Regards,

kurtt

Kurt Pawlikowski
The Pinrod Corporation
http://pinrod.com

[NewsArchive]

Kurt,

> Have your install builder "call" the program with a parameter that
> tells it where the source file is. Write a routine that will read the
> source and build the "permanent" file. Aside from that, you can have the
> program use FILEDIALOG to hunt for the source file. Maybe give it some
> unique extension?
>
> I see that Friedrich has a more elegant solution! And a lot simpler to
> code!

And we are already experimenting with a new installer type option for
SetupBuilder 7. Because UAC and Authenticode and virus-protection scans,
etc. are here to stay for the foreseeable future, we plan to add a
"two-part" installer type for large (>300 MB) setups.

The compiler will then automatically generate a "small" setup.exe (includes
the installer logic, can be code-signed, is Vista manifested) and a "large"
setup.bin which includes all the installation binaries. Only the setup.exe
is "scanned", so start time should be ultra fast for large setups even on
UAC protected systems.

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

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

>
> You're a champion
>

;-)

I have attached a simple SetupBuilder project (.sb6) and a source code
screenshot.

This "loader" does the following:

Line 27: retrieves the full pathname, excluding the file name, of the
setup.exe currently executing.

Line 29: execute the "real" installer (in this case setup1.exe). You can
change this name to whatever you want.

Does this help?

Friedrich

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

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

In fact, you SHOULD change the other file name to something different.

Vista has some fuzzy stuff that tries to be "helpful" and detect
installation programs.
Guess what? Programs whose names contain the word "setup" or "install"
trigger Vista's request for elevation even if their manifests don't
requireAdministrator.
(Try it. Copy any of your Clarion-produced EXEs to a new file whose name
contains Setup or Install. Run it. Watch the "wants access to your
computer" window appear. Rename it back. Watch the warning not appear.)

I realize that invoking your second install from the first means it will
inherit the elevation your user has already approved. But I personally
wouldn't opt to have Vista scanning my folder and deciding that the second
program is an installer.

Not to mention that a user might see that file and try to run it directly.

Jane

> You can
> change this name to whatever you want.
>
> Does this help?
>
> Friedrich
>

[NewsArchive]

Hi Jane,

You are so *completely* right!!! setup1.exe is a very very very bad name
and should not be used here!

In my example, only setup.exe (the loader) gives an elevation prompt. It
executes setup1.exe (no 2nd elevation prompt).

But who knows what Vista does in the background when the setup1.exe
application is recognized heuristically as one that requires an elevated
context. I think it will do the full scan. Argh!

So we really SHOULD change the "other" name. And it SHOULD NOT contain the
words "setup", "install", "update", "patch", etc.

Thanks so much, Jane!

Friedrich

[NewsArchive]

Speaking of this topic, one of the Windows Updates for my laptop is VS 2005
SP1, for which MS' notes say:

Installation Time:
Due to the setup requirements of large service packs such as Visual Studio®
2005 SP1, installation will take a significant amount of time. How much time
depends upon your computer's capabilities and the number of Visual Studio®
2005 products being updated.
When installing on Windows VistaT with User Account Control (UAC) active,
there can be a substantial delay before the initial setup dialog is
displayed. During this time, a UAC function is verifying digital signatures
within the installation package. This service pack carries a large number of
files causing the process to take up to one hour in some cases.

Jane Fleming