i can use the copyfile(); function to copy a file to c:/windows/system32 on windows xp but then i use the function on windows 7 i cant copy it:o the file wont come there....
i had the same problem with writing and reading registery but fixed it by declaring a WOW key $0100 ...
i think the problem is uac but not sure.. could somebody explain me that:D?
That is indeed because of UAC. It is called File/Folder or Registry Virtualization. It is done for legacy applications who don't yet respect the new UAC rules (e.g. not writing in system folders unless you are an administrator).
By creating a manifest file you switch off this virtualization. See here. This can be a seperate file or be embedded into the exe. Newer Delphi versions already generate executables containing such a manifest and have requestedExecutionLevel set to asInvoker. This normally does not allow writing in those locations, unless users specifically run your program as an administrator. Setting it to requireAdministrator does allow writing in those locations, but also means users have to confirm they want to run your program as an administrator.
It's indeed UAC that's preventing you from copying files to the system32 folder. You have to ask yourself why you want to copy files there. A normal application should never copy files to the system32 folder.
Sometimes during install you might want to copy dll's there, but even that is legacy behaviour. Should you really want to copy files there, you should request Elevation at the start of the application.
Why are you copying files there? It should be treatead as the OS private directory. Unless you're installing a driver or the like, you should never write there. In XP you can only because you're running with Administrator privileges, try to use a plain user and you can't as well (since at least 2000, if not in NT already), but it will give you an error because it won't redirect the write. Unless you have a truly good reason to write there, I'd suggest to redesign your application to write in the proper place, instead of trying to find a way to write there. Anyway, it will fail anytime the user don't have the privileges and can't perform an elevation.
Related
So in my TFS build, after the compile, I'm trying to copy some dlls over to the server. If they're currently in use, the build will fail.
Is there a way to force the overwrite, even if the file is open?
Thanks!
It's either a service or a desktop application accessing the dll file. You can find out what has access to the file using handle.exe from SysInternals.
Once you know what is accessing the dll file you can stop/kill it.
Moreover, there are also many other ways which can bypass the system prompts. However, it seems no one fit your situation. More ways to achieve force copy for you reference: How to copy "in use" files through batch file in Windows 7
I use opendialog to load file to application path . is there any way to load the file to %userprofile% > AppData > Local > VirtualStore > Program Files > MyApplication Folder, it is because users should not see the the loaded file
Windows will automatically show applications the "VirtualStore" files for old applications. This is done to try and make sure that old applications build before UAC continue to run correctly. To turn off this behavior you need to add a application manifest to your program. This will make windows turn off the VirtualStore behavior both for files and registry entries.
Here is a good page that describes what is happening in detail:
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware
The manifest is an XML resource file that can be embedded into the application. In terms of UAC, this serves 2 purposes. Firstly it tells the operating system that the application has been designed with UAC in mind, and that it therefore should not attempt to virtualize any folders or registry settings. If the application still attempts to access protected resources after making its declaration, then these requests will simply fail rather than virtualize. The other thing it does is allow the application to state the privilege level at which it needs to run, and whether it requires elevation.
There are several questions already on StackOverflow that deal with creating and adding an application manifest to Delphi 7 projects. Here is one link to get you started:
Delphi 7 vista / windows 7 manifest
Once you tell windows that you know about the new version of Windows via the manifest you will need to make sure that you are playing by the new rules and don't write data back to any of the protected locations.
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".
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
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.