I need the following information
How to get "C:\Document and settings\Network service" folder of XP OS
programmatically from Delphi2010?
What is the equivalent of above folder in Vista and Win7 OS ?
I need to set the Network Service"
account full rights for the above folder thru Delphi 2010
Any help on the above is highly appreciated!!
Thanks in adv
Ven
Here you go:
1) For WinXP: Use SHGetFolderPath API with CSIDL CSIDL_PROFILE to get the folder of your own profile (e.g. "C:\Documents and Settings\Steve"), remove your own name (the Steve part) and add NetworkService (giving you "C:\Documents and Settings\NetworkService"). There seems to be no direct way to get the Documents and Settings folder.
(Example for SHGetFolderPath usage: http://delphi.about.com/od/kbwinshell/a/SHGetFolderPath.htm)
2) For Win7 the location changed to "%windir%\ServiceProfiles\NetworkService", this is commonly "C:\Windows\ServiceProfiles\NetworkService". Don't know for Vista, might be the same.
3) The easiest way seems to be the approach described here: Create folder/file and set permissions
You can start the CACLS programm via ShellExecute API. See example of usage here: http://delphi.about.com/od/windowsshellapi/a/executeprogram.htm
Related
One exe file is system file, such as net.exe or sc.exe; one is downloaded like PsService.exe.
I found that One(net.exe or sc.exe) I can use it in a service via ShellExecute(); another cannot be used. what is different between them? any one knows?
simon
net.exe and sc.exe are system administration commands, and fire UAC if the current user session doesn't have administrative privileges. If you are trying to make changes to the system's configuration, please learn about WMI or the specific API for the sub-system (e.g. the Windows Network Functions) (as well as about administrative priviliges and how to obtain them).
I created customized brush using gimp.While I tried to save it in gimp directory, following error is obtained."'C:\Program Files\GIMP 2\share\gimp\2.0\brushes\mybrush.gbr' for writing: Permission denied". Please help me how can I get access permissions.
I assume you're on Windows 7. Whenever you got errors that you do not have the correct rights while saving items/files you need to get administrator/root access on GIMP.
In windows you can do this by rightclicking the .exe/icon and look for the option "Open/Run with Administrative rights".
Not sure how one would do it in Linux but I assume you'll have to run your program with sudo and/or root access by -su.
When you have administrative rights you should be fine saving everything on the desired location
By default, in Operating Systems where normal users can't create files anywhere on the disk (like any age Linux, or Windows 7), GIMP's default resource folders are installed with the program, and are system wide. These folders are not writable by users without administrative rights.
Running GIMP with administrative rights could, of course, override this problem, but this is not "the right thing to do". What you have to do is go to edit->preferences and on the appropriate Folder resource, create a new folder, this time as a normal user, where those resources will be kept.
From them on, write operations will happen on the newly created folder.
Right-click on .exe (.exe-icon) ---> Properties ---> Compatibility ---> Input Setting = Uncheck "Turn off advanced text services for this program"
- Hope that Help !
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.
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.