When my application is installed in "C:\Program Files..." in Win7 when I launch it, it can't have access to another executable file in the same directory. Other applications work well with this version of Windows except my app :((
I'm using Delphi 7
There is a really good article here on developing apps for Windows 7 that addresses UAC issues specifically.
The upshot is, Program Files is regarded as a directory that should not be messed with lightly, Windows 7 wants elevated privileges to access resources from there.
Craig Stuntz typed here very good like that :
For Vista/Win7, your app can't put the files in a subfolder of Program Files / Programs unless UAC is turned off or the app is running as elevated. Note that "elevated" does not necessarily mean "logged in as Administrator." Non-administrator users can elevate, and Administrator isn't necessarily elevated.
Related
This is a weird one. I've now installed Delphi 5, updated to service pack 1, on my brand new Windows 7 64-bit machine. It seems to function well enough, but when I start it up an error message comes up telling me that the system cannot rename Delphi32.$$$ to Delphi32.dro. I thought "Okay" and went in to rename it manually, only to find that there was no Delphi32.$$$ but there, large as life, was a Delphi32.dro ...
I'm logged on to an administrator-level account, so I figure it isn't a permissions issue.
I'm willing to live with this slight annoyance, but I am worried that it is symptomatic of some deeper problem.
Has anyone else encountered this?
This is a user permissions issue.
Even running as an administrative user, Windows 7 puts some limits on where applications can write. C:\Program Files, (AKA %PROGRAMFILES%) is off-limits except to applications explicitly started using "Run as Administrator", even if you're running under an account with Admin privileges.
More recent versions of Delphi properly handle running from the restricted folders, but D5 was outdated long before Win7 was released and therefore does all sorts of things that aren't proper now. It writes to its own Bin and Lib folders, for instance, and stores the default Projects folder for your own projects there as well.
The easiest solution is to uninstall Delphi 5, and reinstall in a location outside the %PROGRAMFILES% directory structure, such as C:\Delphi5 or C:\Borland\Delphi5. Installing in a different root level folder resolves these issues.
Actually, the easiest solution is to upgrade to a more recent Delphi version, but I'll presume that isn't an option. :-)
This might also help with Delphi 5:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
Ken White's Answer sums it up nicely.
Installing Delphi in a folder other than "Program Files" can threaten and infect Delphi files, and malware can easily infect your Delphi files
(this is a serious threat).
My suggestion is to install a sandbox (or a program virtualization) such as Sandboxie-Plus and Run Delphi from it, you can force Delphi to always run from the sandbox, just be careful your project files are stored inside the sandbox, so you have to manually move them out of the sandbox (for when you want to publish it)
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".
I'm using D2010 under Windows 7 to write an app that seems to require admin rights (I think because it uses COM to communicate with a third party .exe, which also requires admin rights).
I've added the manifest resource as required, but when I try to debug the app from the IDE, it reports
"Unable to create process. The
requested operation requires
elevation"
...and it won't run. If I run Delphi as administrator, then my app runs correctly, but this feels like a dangerous brute force approach, especially as most of the apps I develop don't need admin privileges.
Is there any way of getting Delphi to prompt for elevation just when I run my app, rather than having the whole IDE run elevated?
UAC also catches any application that has the words "setup", "update" or "install" in their name or in many of the Version Resource fields. (Company name, App Name, Description etc.
It considers any such application to be a potential "installer" application and therefore must be run with Admin privileges.
Sounds crazy, but it's true. See the "Installer Detection" section in this document.
You can get around this by including a manifest that says that it doesn't need admin privileges.
There is none, it also doesn't work for VS:
https://stackoverflow.com/questions/3265787/how-do-i-debug-an-process-as-elevated-with-visual-studio-2008-sp1-on-windows-7
I guess you could run the remote debugger elevated and attach the IDE using remote debugging though.
It doesn't work, because the process is running as another user (or using another user token).
The IDE is trying to run the debugging process using CreateProcess and that fails when the application requires elavation, more details can be found in this article:
http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx
RAD Studio could run the application using ShellExecute with the "runas" verb, but this still doesn't solve the "debugging process under other user context" issue.
In other words: An elevated process can only be debugged by an elavated debugger.
Edit:
The Delphi XE2 IDE is 32-Bit and can debug 64-Bit applications only through the remote debugger (which is cleverly hidden from the user).
I guess Embarcadero could make it possible to debug elevated applications in a similar fashion.
The only way I know to debug such an app is to run the IDE as administrator. I wouldn't recommend doing this routinely, just for debugging sessions.
Actually it may be possible to debug a process with "higher level access" from a process with "normal level access".
At least until Windows XP it is sufficient to add your user account to the Debugger Users group to debug processes running e.g. with Administrator privileges.
That doesn't solve Delphi 2010s problem to run the process at all, but may be useful if you try to attach the debugger to a already running process.
I don't think this works on UAC enabled Vista+, but I thought I'd mention it anyway. :)
To be exact the UAC split token concept disables the SeDebugPrivilege:
http://blogs.msdn.com/b/greggm/archive/2006/03/30/565303.aspx
http://blogs.msdn.com/b/mithuns/archive/2006/04/04/568291.aspx
Run Delphi (any version) as Administrator.
You can change Delphi shortcut properties also (to run it always as administrator).
I was built an application on Delphi 7 + Windows XP Pro Sp3 platform, the application run correctly, than i sent this application to my friend that have a Windows 7 OS, my application cannot write the initialization data to the registry with an error "Failed to set data ...", i was suggesst my friend to right clik and choose "Run as Administrator...". How can i build my application on Delphi 7 that can run and write a registry on Windows 7?
Please help, because i could not find the right solution on google right now...
Thanks in advance...
Regards
Chrisna Obaja
Modern versions of Windows have their users running without admin rights by default. This is controlled by UAC.
The solution is usually not to attempt to gain admin rights. Instead you should stop attempting things that need admin rights unless you really do need to. Typically only install programs need admin rights.
You don't say why you are writing to a restricted area of the registry but you should be able to find an alternative to doing so.
You can only write without restriction in HKEY_CURRENT_USER section only - and that will almost be suficient.
To write other parts of registry make an installer.
Otherwise you need Administrator Rights or manifest file.
After many months of postponing it, this week, I finally started using a new Windows 7 Professional PC for actual development (which is 90% still done in Delphi 7 with some of these programs still using the Borland IDAPI to access Paradox files). The previous development pc was still an XP-one.
Every thing works except for one thing: somehow the settings of the IDAPI and BdeAdmin configuration files are messed up or they are read/written in different locations. To be more precise, it looks like two configuration files are active.
It must have something to do with rights or settings being read/written in the wrong folder or registry setting, but after searching for it for a couple of hours, I give up.
Anyone had any problems with this, before ? And if so, hopefully, has any one solved this problem ?
Thx for any thoughts/solutions ...
My guess is it has something to do with the fact that Vista and Windows 7 don't allow programs to change files under the C:\Program Files folder. They create a copy of those changed files in a virtual store, the process is known as virtualization. The copies end up in the hidden appdata folder of the user account and can be found in the Local\VirtualStore\Program Files folder. The structure in that folder reflects the one in the actual Program Files folder.
Programs that access their files in the Program Files folder using a "hardcoded" path, will always get the original - unchanged - file contents.
Solution: running the apps in a virtual XP system or upgrading the apps is probably your best bet.
You could try to run the apps elevated. That is: right click them and choose Run as Administrator. Please note that it isn't enough to be logged in as an administrator. Even administrators run all processes unelevated by default. Instead of right-clicking, you can also create a shortcut and set the Run as administrator for the shortcut - the checkbox for this is on the compatibility tab of the properties dialog. No guarantees though that this will alleviate the problem.
Since IIRC D7 setup allows you to configure paths in multiple ways, maybe simply do a reinstall outside "program files"?
Afaik this solves several vista/w7 problems.