I'm having a problem with good ol' bdeadmin.exe in Vista. First, let's get the predictable responses out of the way:
"You should not require your application to be elevated."
This one does. C'est la vie.
"You need to embed a manifest file."
It is already compiled, it is many years old, the company that created it has no intention of doing it again, and it is installed from a Merge Module (MSM file).
"BDE is obsolete, you should be using dbExpress"
One and a half million lines of code. 'Nuff said.
"Drop a manifest file next to the EXE."
Tried that, did nothing. As a test, that same manifest file was able to make several other EXE files require elevation, just not the one I wanted. Something in there is preventing the external manifest from being read.
"Create a shortcut and set SLDF_RUNAS_USER."
Can't do that, it's a Control Panel applet.
The only thing that worked was setting "Run this program as an administrator" under the Compatibility tab of its Properties window. I shouldn't have to tell users to do this. Bad for business. I need to have the installer do this. The MSM file uses a static path.
You can programmatically set the "Run this program as an administrator" flag (the option you find in the Compatibility tab of an EXE's properties), by setting a simple registry key. You need to create a string value (REG_SZ) under one of these keys (if you want the setting to be per user or per machine, respectively):
HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers
or
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers
The name of the value needs to be the full path to your executable (if the path contains spaces, do not surround the path with quotes) and the data of the value must contain the string RUNASADMIN.
For sample:
reg.exe Add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Program Files\MyApp\Test.exe" /d "PUT__VALUE__HERE"
Compatibility Modes
WIN95 Windows 95
WIN98 Windows 98
WIN4SP5 Windows NT 4.0 SP5
WIN2000 Windows 2000
WINXPSP2 Windows XP SP2
WINXPSP3 Windows XP SP3
VISTARTM Vista
VISTASP1 Vista SP1
VISTASP2 Vista SP2
WIN7RTM Windows 7
WINSRV03SP1 Windows Server 2003 SP1
WINSRV08SP1 Windows Server 2008 SP1
Privilege Level
RUNASADMIN Run program as an administrator
REG ADD "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers" /v
"C:\temp\compatmodel\iconsext.exe" /t REG_SZ /d "WINXPSP3 RUNASADMIN"
/f
References:
http://www.verboon.info/2011/03/running-an-application-as-administrator-or-in-compatibility-mode/
This is a long shot, but if you have the word "setup" or "install" in the name of the EXE, Windows will prompt for elevation when running it. I don't know if that'll work with a control panel applet, though.
Use a wrap program which uses ShellExcute that uses "runas" as its "verb" to run the program you want.
I have found that the .manifest file method doesn't work if the .exe is under C:\Program files\... and the .exe has previously been run without the .manifest file. Windows remembers the .manifest from the first time the .exe is run. This means you can't just send the manifest when users complain that their installations don't run. The manifest file has to be placed before or during the same installation that places the .exe.
Windows rechecks the .manifest if the .exe changes (e.g. new release or different number of bytes)
Have you tried Microsoft's Application Compatibility Toolkit? It analyses your app and provides compatibility shims that might be able to help resolve your problem.
Pack your app into WinRar SFX with silent mode + admin request mode.
Much simpler than messing with .MSI variables.
I'd be surprised if this was possible. It would be an ideal way for malicious code to abuse the system. You're probably going to have tell the user the administrator must install or they must have admin rights (like all the other programs on windows do).
Related
I have looked every where for a download for the .exe, I have tried the fix.reg sloution, I have tried clicking run and expanding the ex_ file into the .exe, but anytime I click something I am met with this error "Windows cannot access the specified device, path, or file" It also says I may not have access to the item. I am the only user/admin and this is a fresh install of the Windows XP black edition.
I cant even use CMD. Surely there has to be a fairly simple solution? Right? I have the RunDll32.ex_ I just dont have permission to run anything like CMD to expand it. Can I simply use a .exe from another computer running same OS?
It seems you have a big problem on the registry or a broken file system.
As you said you could use a rundll32.exe from another computer with the same version of OS. Check the Service Pack installed in your Windows XP and the other computer.
You could try to copy the DLL to a pendrive from the other computer to yours.
If you cannot copy the new DLL you should need to start Windows in Safe Mode (Press F8 before Windows starts and select on the Black menu text window Boot in Safe Mode), because Windows protects all the files in c:\Windows\ and c:\windows\system32
If Safe Mode don't works, next try should be to use a Windows Live CD. Hiren's Boot has a mini Windows XP embedded.
http://www.hirensbootcd.org/
You need to download the ISO, burn It and boot the computer with it. Run the mini Windows XP and when you see the desktop run the Windows Explorer and copy the DLL from the pendrive to your fixed hard disk. Take care because your hard disk should not be the C: (that should be the mini Windows XP partition), look in other drive units for your data.
I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
I have an old game (Westwood Monopoly CD-ROM) that only has a 16-bit installer so it won't run on my Windows 7 x64. To get around this I decided to use Inno Setup to make a new installer. The game itself is 32-bit but not LFN aware and will run on Vista/7, however the game will crash if the installer I built with Inno Setup is not run with Windows 95 compatibility checked.
There are no file or attribute differences between the folder generated by having compatibility mode on and the folder generated with no compatibility settings checked. However, the game will only run in the folder installed with compatibility mode, the game exe (Monopoly.exe) itself cannot have any compatibility mode option enabled or the game terminates whenever you try to save, load, or choose one of the computer ai player files. If compatibility mode for 95 is turned on for Monopoly.exe in the folder created without compatibility mode set for the installer, the game will load but will be unplayable for the above reasons.
My guess is that the Windows 95 setting forces short filenames to be created, while without it the game cannot find it's files because the short filename information isn't there. Having compatibility mode set for the installer is not the ideal solution since I need to be able to copy a different exe based on the version of Windows detected (Aero causes part of the screen to be cut off so I use a hex edited exe with a bigger default size).
So my question is this: Is there a way to force Inno setup to create the short filename information as it copies, or is there a way to add that with a command after it is finished (ie. repair the broken folder so the game can find its files)?
As far as I am aware, the problem is that the newer version of Windows Installer and Windows itself no longer support the use of short names. That property has been phased out of use and as of (AFIK) Vista it is flat out not used. Most modern installer technologies will give you an error if you try to include them. Have you tried looking at DosBox? That might also allow you to run it without the need for a special installer.
I'm marking this as a community wiki because I'm not really looking for one complete answer. So if you feel like posting one or two things that will activate the UAC prompt instead of a comprehensive list then go ahead.
What actions in Windows will activate UAC? I'd like to avoid it as much as possible because my application doesn't need admin privileges. And I'm sure many other people want to avoid it.
Specifically, I would like to know if reading from the registry would activate it. Or writing to it?
You don't need to address the above question, just anything that will activate it is fair game.
It's really hard to Google anything about UAC because you get bombarded with articles about how to disable it. And I'd rather not have my application make the assumption UAC is disabled.
Nothing "activates" UAC.
If your application would fail to run as a standard user under Windows XP it will fail to run under Windows Vista or Windows 7 as a standard user.
What you are really asking is: what actions can a standard user not perform under Windows?
The things a standard user cannot do are pretty well known (they've been the same since Windows 2000). The main ones are:
modify anything in HKEY_LOCAL_MACHINE
modify anything in the Windows directory
modify anything in the Program Files folder
If you try to do any of those they will fail on:
Windows 2000
Windows XP
Windows Vista
Windows 7
Nobody should have been running as an administrator for day-to-day computer use. If your application did any of those bad things in Windows XP it would fail. The user would have to:
logon (or fast user switch) to an administrator
perform the administrative task
switch back to their real account
UAC is a convience mechanism, allowing you to easily temporarily switch to an administrator. Nothing you do will "trigger" it; you have to make it happen.
If you know your code needs to modify a file in C:\Program Files\My App\Data, then you should add a button on your form that will trigger the elevation.
You then need to launch an (elevated) copy of your program, do the thing, and close.
I created a launch4j installer (an exe-wrapper for java programs) and named it "MyApp.exe". It doesn't need any admin authentication. It just runs fine without any UAC prompt.
BUT: If I rename this installer to "install.exe" or "setup.exe", the UAC icon appears and I get a UAC promp when starting the installer.
Seems as if there are some "reserved words" in filenames that cause windows to start a program with elevated rights (UAC).
I read in this article:
http://technet.microsoft.com/en-us/library/cc709628.aspx
That Windows detects Installers through file names, following this tip, Is it better to include setup in the file name for the installer
I mean ProductSetup.msi is better than Product.msi???
It's hard to think that Windows does this kind of detection :-)
This only applies to EXE files. If you've got an MSI file, it's up to the MSI file to specify which parts of the MSI require elevation or not.
That's news to me, but it does seem like Windows Vista treats files differently when they have "setup" in their name. It will probably just prompt you for administrative rights up front if it detects that it's an installer, which is what you'd want.
Also worth reading is How User Account Control Affects Your Application, to ensure that your setup runs as administrator embed the correct manifest into the setup EXE. This way it doesn't matter (to Vista) what your installation is called.
That said however, if you expect the application to be installed on a terminal server then if your installer is called something like SETUP.EXE or INSTALL.EXE Terminal Server will automatically kick into "install mode". Should save you some headaches from those customers who don't know they should be in install mode first, or choose not to install via Add/Remove Programs (which also kicks install mode in automatically)