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).
Related
I have a single executable which, via InnoSetup, installs into Program Files\FolderName by default. The exe has a 3rd party component which goes online to check for new versions and downloads them, then does a bit of fiddling to replace the exe - simple stuff. The problem is, it can't do this in Program Files because of the necessary security there. I was reading Windows 7 - Can't update my program's files in C:\Program Files in which David Hefferman gives a solution but then seems to say it's a bad idea - but I don't know whether the bad idea bit refers to his solution or to the OP's comments!
So what is the preferred method by which a program can update itself? One that will work on XPSP3 to Win8. I can't seem to find the right phrase to enter into Google that gives me relevant results. Ignore digital signatures and suchlike for now, for simplicity.
(Please note, it may look like I worded that as an opinion question but it's not - there must be some MS-endorsed way of doing it that I can't find. FWIW this is a Delphi program but any Win32 notes will do)
That 3rd party update utility needs to be run with administrative privileges, you can achieve that programmatically.
There is nothing wrong with installing your application in Program Files, that is the designated purpose of this folder. However, user data that is used by the application should be stored in a different location.
However you run that 3rd party Utility, you should first check the Windows OS version to see if fiddling with UAC is really necessary(Vista+...) and then run the utility in the elevated state.
He says its "extremely bad practice" to fiddle with your system so that normal users can write in "Program Files".
If your program is in "Program Files" it's installed with System Admin rights. So updates need also be installed with System Admin rights.
You can configure InnoSetup to request admin-rights so you can write to "Program Files" but if the 3rd party component does not do this its best to install everything in an other directory.
i.e. C:\Your_Program
That way your 3rd party component can write there.
There are several options here:
The easiest: make updater as a separate program with manifest, which requires admin privileges. Also you can ask for admin privileges when you start your updater. Or you can move your updater into out-of-process COM object instead of separate exe.
You can create hidden user with admin rigths during installation of your program. Then you will run your updater with credentials of this user.
You can install system service during installation of your program and this service will run from system account. So your updater will be implemented as a service.
I have an EXE running with normal privileges, but there are cases (for example using VSS / volume shadow copy) where I need admin privileges (if I'm not mistaken)
The idea is to put the code that needs extra privileges in a separate EXE and launch it as needed.
It's something that I'll rarely need, but I still need to have it as a last resort option (this is to say that I'll rarely need to call it, maybe once/twice a day on average)
My question is: How can I call an admin-elevated process from a normal EXE?
On Vista and later with UAC enabled, the best option is to provide the second EXE with a UAC manifest (preferrably embedded as a resource, but can also be done with an external .manifest file) that sets the requestedExecutionLevel value to requireAdministrator. Then you can just CreateProcess() the EXE file normally. If providing a manifest is not an option, or if you need to support XP and/or non-UAC setups, then you can use ShellExecute/Ex() specifying the "runas" verb instead. Under any of these setups, the OS will prompt the user for permission and account credentials, and then apply the appropriate security rights to the new process as needed.
Another option is the third-party CreateProcess...Elevated() (and ShellExecute...Elevated()) implementations provided in this article:
Vista UAC: The Definitive Guide
tldr; at bottom.
Ok, so once again an interesting problem and I'm looking for a fun and interesting solution.
My current project involves being very modular, meaning the program functionality will be easily changed based on different modules and the program would adapt.
So I started out with the typical route, which is using DLL plugins. Now this is just way to normal, I want to think outside the box a bit.
The modules included in my program are long running campaigns that may take weeks to finish, and there will be many running at a time. So stability is a big issue, so I thought about what Google Chrome does. Processes, not DLLs or threads.
So I have a framework going and I need a way to get some information about each module (which are now EXEs). Now for my DLL framework I was exporting a "Register" function that would fill in some information.
So I thought to myself, hey EXEs can export functions, let's see if that actually works...It doesn't. I did some research into how Windows handles theses things and I don't feel like hacking the PE headers on the fly (but it's the out of the box kind of thinking I'm going for).
I'm planning on using named pipes and CLI parameters to transfer data between the main program and the module exe's. I could use that in a register fashion, but I want to here other peoples thoughts.
tldr: I'm using EXE's instead of DLL's for plugins. Looking for a way to easily export one time information like a exported "Register" function would on a DLL. Thoughts?
You might still consider having the modules written as DLLs with defined entrypoints (e.g., the Register function). Then you write the executable that loads the specified DLL. Your main application would fire off the driver executable and give it a name of a plugin DLL.
That way it is still easy to define and export the set of APIs that must be provided yet still run it as a separate process. The one executable that you write can load the specified DLL and then handle the necessary IPC with the main app.
You could define a protocol via the stdin/stdout, named pipes, sockets, etc.
I have successfully used 'plain' COM for several projects, and objects inheriting from TAutoObject. The bonusses here are IDL; the interopability with .Net, VBA and other non-Delphi things; and the fact that implementors still can choose wether to supply a DLL, an exe, an NT-service, and optionally run hosted over the network (COM+/DCOM). There may be several considerations you should handle about multi-threading and locking, but I found all that I needed to know online.
You can, of course, not use symbols exported by a (running) exe since it is running in another boundary. But, you can load an exe as an image (as you would do with a library) using LoadLibrary(Ex) and then, use the functions exported by the exe. I have tested (just for fun) when debugging PeStudio. See the snapshot below of chrome.exe loaded in the process space of PeStudio.exe using LoadLibrary.
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.
We have a suite of programs that check for new versions at startup, and then download new versions to run if required. This is obviously a problem in Windows 7, when it is locked down as a 'standard user', as they can't write to the c:\program files directory and below. Anyone seen a example of an application that gets around with issue ?
Our applications are written in Delphi, but an example in any language would be useful.
Thanks in advance
Update:
We already have a system for determing whether a new version exists, the only problem is the download and install (if required), as this requires elevation. I can't think of a way that doesn't require an elevation prompt, or our users to reduce their security settings.
Update 2 :
I've asked a subsequent question, rather than adding a new one here
There are two options for application installation:
Application is available for all users: installation or update requires elevation for Windows Vista and up
The application is available for one user: install or update the application in the user profile in %LOCALAPPDATA%, no elevation is required
Ad 2: Google Chrome does this. It installs the .exe here:
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe
--jeroen
Typically what you will see an application do if it needs to escalate permissions is something like this.
Application determines if upgrade is needed
Application launches an "updater" service that requires "Administrator" permissions
Application updates itself with this updated
Application re-starts
This is a pretty common scenario, especially since to update your own DLL you need to go to a secondary process anyway.
Here are some tips for you to get around updating challenges:
If your file is names 'update.exe' or 'install.exe' then it will automatically force a UAC elevation prompt. This is an easy way to make existing software bypass Windows Vista/7 permissions.
It is not a good idea to have the update checking and update process managed from within your application. The problem is that your app is likely to lock files and need updating itself. An external app should manage your updates.
The simplest update solution is to make an HTTP call that checks for the current product version number, and then download the installer binary if necessary. This won't give you any flexibility in updates, but it is a quick and easy solution.
Our company sells software that specifically helps with automatic updates on Windows 7 UAC (you can visit AutoUpdate+ by clicking here: link text). The best reasons for using a third party solution - any solution - are that you will have more flexibility with your updates and also avoid the finicky challenges of supporting different Windows releases.
Or you can have it so that the user runs a launcher app.
The application uses the LOCALAPPPATH\ folder to store a cache of the main application.
Launcher checks to see if the internet has newer version of file(s) than the cached file.
Launcher launches the cached application in LOCALAPPPATH
Your app can check if a new version is available on the remote server. If it does, then it can download update files in one of user-specific folders, like user's temp folder. You can get address of such special folders using SHGetSpecialFolder API function.
Once the download is done, you can pop up a dialog box telling user that you are ready for update. If user agrees with update, then you can run the updater process with elevated privileges (as administrator), and updater process can replace existing files in your installation path with the ones already downloaded in user Temp folder. To run your updater as administrator, you can use ShellExecute:
ShellExecute(0,'runas','notepad.exe',nil,nil,SW_SHOWNORMAL);
When updating is done, your updater process can restart your app.
You need to have a separate executable to the updating work. The updater needs to have a manifest that marks it as requiring elevation.
See: http://msdn.microsoft.com/en-us/library/bb756929.aspx
If your application uses MSI (Windows Installer) for its installer, then User Account Control Patching, if properly configured, can let you install updates without elevation.
If your installer wasn't run under admin - you don't need any additional rights to install update.
If your installer was run under admin - then it can create a task in Task Sheduler. Say, run this task once a week, under this account (admin) and with highest privs. Task will be your updater. Simple.