I have an 'auto-upgrade' mechanism that has been working for many years under Windows XP which fails under Windows 7 because the prompt to the User (which never existed under under Windows XP) to grant the program permission to run with administrator rights does not appear.
The win32 program (written in Borland Delphi) uses LogonUser() and ImpersonateLoggedOnUser() to impersonate a user (local account with administrator rights) so that it can replace selected files in the Program Files folder.
If I manually logon to Windows 7 using this user account and then attempt to delete a file in the Program Files folder Windows 7 prompts for my permission to allow the program to proceed - if I give it permission the file is deleted, if I deny permission 'access denied' is reported and the deletion is not allowed.
When attempting the same thing as described above 'access denied' is the result without any prompt to the user being given.
I see in a similar question herabouts (regarding the creation of temporary files (where the main thrust of the answers given is quite rightly 'don't do it') that such a prompt can be raised 'in code' but I cannot see where that method is actually explained.
You just need to mark your auto updater as requiring elevated privileges in your application manifest.
That said you might want to consider installing somewhere the user has write privileges.
You partly seem to be asking how to run code elevated. There are a couple of answers to the question below which provide links to the information you need to invoke functionality running elevated:
Delphi: Prompt for UAC elevation when needed
Well two years have passed, my clients are at last adopting Windows 7 and I have finally got round to circumventing the problem I was trying to solve (temporarily gaing sufficient rights to replace executables in Program Files under Windows 7) by replacing my own installer with an Inno Setup installer (incorporating additionl logic carried over from my installer using Pascal Scripting). Inno Set handles all the permissions issues - hurrah.
Related
I have installed Delphi 2010 and tried to create a new project clearly.
but when i compile my project, delphi does not generate any exe file.
also when i try to run application i get this error:
Could not find program, "C:\test\Project1.exe"
note: i haven't changed any configuration or settings of Delphi or project.
everything is as it's default
It was about getting absolute path because i'd changed ProgramFilesPath and ProgramFilesDir in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to D: without leading backslash.
I changed it to D:\ and the problem was solved now
thank you all
If you're on Vista or later, this could be because of UAC settings. Try setting the project output folder in Project->Options to something a limited account would have access to, such as somewhere under My Documents\RAD Studio\Projects.
I've had the same problem on Windows 7.
Installing it as administrator solved the problem IIRC.
If that doesn't work then make sure you run it as administrator.
You are running it on XP though, so unless you've installed it as a non-administrator, or run it as a non-administrator this shouldn't be happening.
Note that if you're in a domain, it's possible that you're not local admin on your XP machine.
Run Process Explorer, search for any open handles to C:\test\Project1.exe using Find, Find handle or dll.
That will tell you what is locking your .exe.
Edit 20221221 because of link rot:
[Wayback/Archive] Process Explorer redirects to [Wayback/Archive] Process Explorer - Sysinternals | Microsoft Learn
[Wayback/Archive] Know which process has locked a file has died and moved to[Wayback/Archive] How to Identify the Process that has Locked a File in Windows and added solutions based on resmon.exe (built-in), handle.exe (SysInternals), OpenFiles.exe (built-in, but requires a global flag to be enabled which for enabling requires a reboot).
[Wayback/Archive] Handle - Sysinternals | Microsoft Learn
I have installed Delphi 2010 and tried to create a new project clearly.
but when i compile my project, delphi does not generate any exe file.
also when i try to run application i get this error:
Could not find program, "C:\test\Project1.exe"
note: i haven't changed any configuration or settings of Delphi or project.
everything is as it's default
It was about getting absolute path because i'd changed ProgramFilesPath and ProgramFilesDir in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to D: without leading backslash.
I changed it to D:\ and the problem was solved now
thank you all
If you're on Vista or later, this could be because of UAC settings. Try setting the project output folder in Project->Options to something a limited account would have access to, such as somewhere under My Documents\RAD Studio\Projects.
I've had the same problem on Windows 7.
Installing it as administrator solved the problem IIRC.
If that doesn't work then make sure you run it as administrator.
You are running it on XP though, so unless you've installed it as a non-administrator, or run it as a non-administrator this shouldn't be happening.
Note that if you're in a domain, it's possible that you're not local admin on your XP machine.
Run Process Explorer, search for any open handles to C:\test\Project1.exe using Find, Find handle or dll.
That will tell you what is locking your .exe.
Edit 20221221 because of link rot:
[Wayback/Archive] Process Explorer redirects to [Wayback/Archive] Process Explorer - Sysinternals | Microsoft Learn
[Wayback/Archive] Know which process has locked a file has died and moved to[Wayback/Archive] How to Identify the Process that has Locked a File in Windows and added solutions based on resmon.exe (built-in), handle.exe (SysInternals), OpenFiles.exe (built-in, but requires a global flag to be enabled which for enabling requires a reboot).
[Wayback/Archive] Handle - Sysinternals | Microsoft Learn
I have a very old application written in delphi 5 running in some customers which uses the BDE. Now some users with Windows Vista and 7, had experimented some problems with the multiuser access. i' think which these problems are related to the location of the net.and .lck files. so the question is which is the proper way to confgure the BDE under Windows Vista and 7 to avoid permissions and UAC conflicts?
In addition to the above answer, you'll want to make sure that the .net and .lck files are located in a user-specific directory under Windows 7, specifically:
C:\Users\{User Name}\AppData\Local\{Your Company Name}\{Your Application Name}
Those are the only folders that the current user will always have complete control over.
You can get this folder by using this code:
CSIDL_LOCAL_APPDATA = $001C;
function GetAppDataDirectory: AnsiString;
var
TempBuffer: array[0..MAX_PATH] of AnsiChar;
ResultLength: Integer;
begin
FillChar(TempBuffer,((MAX_PATH+1)*SizeOf(AnsiChar)),0);
ShlObj.SHGetSpecialFolderPathA(0,#TempBuffer,CSIDL_LOCAL_APPDATA,False);
ResultLength:=StrLen(pAnsiChar(#TempBuffer));
SetLength(Result,ResultLength);
Move(TempBuffer[0],pAnsiChar(Result)^,(ResultLength*SizeOf(AnsiChar)));
end;
and then appending {Your Company Name} and {Your Application Name} to the value returned. You'll need to include the ShlObj unit.
One such thing I remember is to configure the Session to put that kind of files on folders where a normal user have write-privileges.
From what I remember, the properties
Session.PrivateDir
Session.NetFileDir
Are the relevant ones.
The correct location will depend on concurrent access, the database you're connecting to, data location –in case of paradox or dbf's– and if you use cached updates or not.
I maintain an application written originally in D4, now compiled with D2007 when rarely needed and it works well on vista+ using this with it's particular configuration and needs (no paradox/dbf's).
If you don't want to work around the security bugs in a default install of the BDE (as other answers mention - granting permissions that the BDE installer forgot to), you can just run your application as an administrator.
You have a few options:
Tell the user to right-click and select Run As Administrator every time.
Go to the program's Compatibility tab, and check Run this program as an administrator (which has the same effect as 1)
Go to the program's Compatibility tab, and Run this program in compatibility mode for Windows XP (which has the same effect as 2)
Create a manifest MyApp.exe.manifest and include the requestedExecutionLevel of requireAdministrator (which has the same effect as 3)
In other words: Your application, as it stands right now, requires administrative access to run - so just run it as an administrator.
On the other hand you can make a few simple changes and your application will no longer need to run as an administrator; you've made the world a better place for all humanity!
if you compile a program in D2010 a manifest .res file is automatically generated. is it included in your program by default? or you have to include it yourself?if yes what level of privilage is given to you? my program modifies a registery key would it be able to do so with out any modifications to .res file?if no what modifications i need to do?
a side question: is there a component/expert(prefably free) that can generate/include .res file in my delphi 7 and delphi 2007 projects automatically just like delphi 2010?
edit: forgot to mention i do not have win7 or vista nor have i ever used them
edit2:i have included a manifest file just in case following this tutorial but the tutorial only talks about windows vista and not 7 would the .xml(manifest) file in this tutorial make my app capable of dealing with win7 UAC too
edit3 if i include my own manifest file and delphi is including it by default as well that will make 2 manifest files(1 with admin previlages and 2nd without) would this cause any problems/unpredictable behaviour
The manifest generated by delphi gives your process the lowest privileges (that is the default by the way).
You have to modify the manifest file in order for it to ASK for permission to be run under administrative rights (Called elevation).
Your application with the standard privileges should read/write to HKEY_CURRENT_USER without elevation.
Accessing %programfiles% and HKEY_LOCAL_MACHINE requires elevation. (Not so sure about the other registry hives)
This is a PDF that will help you A LOT with what you're up to.
http://pascalfonteneau.developpez.com/articles/delphi/vista/uac/VistaUACandDelphi.pdf
I have a Delphi .CPL currently written with Delphi 7 which needs to update settings in HKLM (to be used by a service application) and which must support Vista, Win7 and Server 2008. Currently this can be done by adding a RUNASADMIN value to AppCompatFlags/Layers, using the CPL file as the value name. This causes Windows to ask for elevation for a 'legacy control panel applet'.
I need to find a way to build the CPL in Delphi 2010 without it appearing to be 'legacy' and, if possible, not to require the registry setting or elevation. Adding the usual manifest resource to the DLL/CPL referencing Common-Controls v6 and "requireAdministrator" does not fix the problem: no elevation is requested and HKLM access fails. Both the original and the Delphi 2010 .CPL can be made to run correctly (after elevation) by navigating to the file in SYSWOW64, right-clicking, and running 'as Administrator'.
Later: I have found a succint explanation of why you cannot elevate a DLL in this way in a forum posting here.
I believe you need to use COM elevation. There was a wonderful blog posting on this which appears to have been taken down, but the source code behind the posting is still available on the VCL components website (way back machine link).
Some additional information can be found in the question/answers for: Delphi: Prompt for UAC elevation when needed
I think I have found a better answer to my question. There is such an animal as a 'non-legacy' control panel applet, which is described in MSDN here. "Now, in Windows Vista, you can add your own applet to Control Panel by creating an executable for your applet and registering it, instead of going through the trouble of creating a .cpl file."