Run VB exe's in Win 7
in [Visual Basic]
|
From: MikeD on 1 Mar 2010 17:18 "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 1 Mar 2010 18:18 > > > 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 2 Mar 2010 04:19
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 |