From: MikeD on


"Webbiz" <nospam(a)noway.com> wrote in message
news:0o9oo5tfg7mhcdj4fhjj724d8rfrj3e944(a)4ax.com...
> On Fri, 26 Feb 2010 17:29:29 -0500, "MikeD" <nobody(a)nowhere.edu>
> wrote:
>
>
>>While I don't mean to discourage this as a sure-fire way to run the setup
>>with admin rights, it's not necessary if the file is named Setup.exe
>>(variations are also supported, but I don't know right off-hand exactly
>>what
>>those variations are). Windows will automatically elevate to admin IF the
>>logged on user is a member of the Administrators group. I'm also pretty
>>sure
>>any Windows Installer package, regardless of file name, will get elevated
>>since it can only be an installation (or patch/update).
>
>
> This brings up a subject that I've been meaning to address.
>
> While many call their setup programs "Setup.exe", I like to them named
> after the application itself because I have to deal with so many setup
> files for various apps, placing them in their proper website
> directories, etc. Just like them independently named.
>
> So what I was wondering I think you addressed. What do we do to make
> installation packages that will fully install the .exe and supporting
> files by simply running the installer without the need to "Run as
> Administrator"?
>
> I've been using InnoSetup to create my setup packages. Perhaps I
> should be learning how to create .MSI package? Thoughts?

Here's a link to some information.

http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx
(scroll down to Installer Detection Technology)

An excerpt:
-----
Installer Detection only applies to:

1. 32 bit executables

2. Applications without a requestedExecutionLevel

3. Interactive processes running as a Standard User with LUA enabled

Before a 32 bit process is created, the following attributes are checked to
determine whether it is an installer:

Filename includes keywords like "install," "setup," "update," etc.

Keywords in the following Versioning Resource fields: Vendor, Company Name,
Product Name, File Description, Original Filename, Internal Name, and Export
Name.

Keywords in the side-by-side manifest embedded in the executable.

Keywords in specific StringTable entries linked in the executable.

Key attributes in the RC data linked in the executable.

Targeted sequences of bytes within the executable.
-----

Much of that is pretty vague. For example, what specific StringTable
entries? It also mentions that "Windows Vista heuristically detects
installation programs" and "Windows Vista also heuristically detects updater
and uninstallation programs".

I found that documentation with only a couple minutes of searching. If you
want more information, I suggest you do a few searches of your own. You can
search for the information just as well as I or anyone else can. <g>

As far as MSI packages go, I've got nothing against them. Other than Visual
Studio Installer (the one downloaded from MS for VB6) I don't know of any
free ones. And I don't like VSI because it has too many shortcomings as far
as I'm concerned. In fairness, some of those shortcomings can be addressed
using Orca, a tool from MS for editing MSI files. But it's still a pain to
use because you need to "fix" those things after each time you make an MSI
file. That becomes a PITA real quick. If you want to spend the money on Wise
or InstallShield (or whatever other utility), then by all means go right
ahead.

Also remember that this automatic elevation doesn't mean the user won't be
prompted by UAC. Unless UAC is off (for Vista) or set to a low enough level
(for Win7), an admin user will still need to confirm, and a non-admin user
will always be prompted for admin credentials.

--
Mike




From: mayayana on
>
>
> This brings up a subject that I've been meaning to address.
>
> While many call their setup programs "Setup.exe", I like to them named
> after the application itself because I have to deal with so many setup
> files for various apps, placing them in their proper website
> directories, etc. Just like them independently named.
>
> So what I was wondering I think you addressed. What do we do to make
> installation packages that will fully install the .exe and supporting
> files by simply running the installer without the need to "Run as
> Administrator"?
>

In case MikeD's note wasn't clear, you just need
"setup" in the filename to get elevated. I use something
like "w5setup.exe" for a program with first letter w,
version 5. I like to follow the 8/3 rule just to be on the
safe side. But most software uses long names. Example:
"Firefox Setup 3.0.5.exe"

> I've been using InnoSetup to create my setup packages. Perhaps I
> should be learning how to create .MSI package? Thoughts?
>

Microsoft recommends MSIs but a lot of software,
including some of Microsoft's own, doesn't come that
way. (Recently I came across a new Microsoft
aberration, wherein they package everything into
an SFX CAB with an MSI inside. It's sort of an inside-
out MSI installer.)

The only reason to use an MSI is if you have corporate
customers who *really* want it. Sometimes system
admins like MSIs because they provide standardized
ways to apply patches, list installed software, etc.

The reason not to use MSI is because it's extremely
complex and convoluted. And there are no really good
tools. You can create an MSI installer with nothing
but Notepad and VBScript. But the system is such a
mess that people pay big money for commercial
products that wrap the Windows Installer API into
an easy IDE.

An MSI file as an installer is an SQL database of
about 80 tables, heavily cross-referenced, usually
with your program files packed into an embedded
CAB. You enter file data and settings data into
the correct tables. You also enter values to designate
how setup runs, etc. But Microsoft has made the
process extremely complex. Imagine the job described here,
then multiply that by maybe 30 to get an idea of how
many inter-related SQL table entries you'll need to
enter just to get a basic installer. Wise and InstallShield
actually pack in their own DLLs so that they can
further customize an installation. And if you want to
control the window layout, button captions, etc., you
can do all of that, but it's all done, again, by inputting
SQL table values.

I wrote a COM DLL recently that wraps the Windows
Installer API, providing simple, API-style functions in
place of awkward, long, SQL strings. But it's intended
more for editing or unpacking MSIs, rather than building
installers. Without some kind of RAD IDE there's no way
to make MSI creation into a reasonable task. (Personally
I use my own version of the PDW. I love it. Very customizable
and easy to create a new version for new software.)

The DLL - see jsMSI.dll on this page:

http://www.jsware.net/jsware/msicode.php5


From: Dee Earley on
On 01/03/2010 20:48, Webbiz wrote:
> While many call their setup programs "Setup.exe", I like to them named
> after the application itself because I have to deal with so many setup
> files for various apps, placing them in their proper website
> directories, etc. Just like them independently named.
>
> So what I was wondering I think you addressed. What do we do to make
> installation packages that will fully install the .exe and supporting
> files by simply running the installer without the need to "Run as
> Administrator"?

Add the Vista aware manifest to request elevation and turn off
virtualisation.

> I've been using InnoSetup to create my setup packages. Perhaps I
> should be learning how to create .MSI package? Thoughts?

Inno 5.2+ (I think) does this anyway.

The "Setup", "installer", etc heuristics are only put in to detect older
non vista aware versions and are turned off if the manifest exists.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems