Like many program's updater I'm trying to make my own updater which will not allow users to run it by double click.
It can only be started from my main application by ShellExecute.
What should be the ideal approach for this ?
Printable View
Like many program's updater I'm trying to make my own updater which will not allow users to run it by double click.
It can only be started from my main application by ShellExecute.
What should be the ideal approach for this ?
Why on earth do you want people not to run a program??
Anyways, perhaps the updates that are running may not be launched by an exe, ever thought of that? :)
Because I don't wanna run the updater from user end at least on the Earth.. :PQuote:
Originally Posted by HanneSThEGreaT
The updater will launch from my main application and kill application if it needs to be updated.
One thing you can do is add the updater.exe file to your main application resource as a bin resource when you will want to use it simply extract it to disc as exe, and launch it.Quote:
Originally Posted by hypheni
When it launched it will close your main application and will do whatever it takes for the update.
But keep in mind that each time you run the main application, make sure you delete the updater.exe so it won’t remain on the disc.
This thread might help. (it deals with bmp file but its the same thing for any type of file)
Cheers
Thats not my goal. Binding exe as resource with application - I did a lot earlier. You can find my old posts about this which helped other so this is not the way.
Im talking about the actual procedure which many software's updater uses. For example Garena (a virtual gaming client) updater uses the same mechanism. You cant run the updater by double clicking. It will show you error that "You can't run updater in this way."
Hmmm... Just a quick shot - there may be a far more elegant solution...
Why not simply define an undocumented command line option for the updater and pass that when invoking the updater from your main app? If the option is not present the updater refuses to run.
Yes thats a good idea. I will give a try and post here..
BTW. "hmm" is used in Germany too ?. I thought its only Indian shortcut to say "Yes" online.
Usually it's used to indicate somebody is thinking.Quote:
Originally Posted by hypheni
hmm.. Okay
hmm, Sorry, my original post was not very helpful. I understood your question wrong. :blush:
Another option might be to have your installer check to see if your main app is already running. If not, issue an error, and close.
Viggy
Another (but similar) idea is to modify the environment variables passed to the child process when using CreateProcess to start your updater, to include a custom variable that your updater checks for.Quote:
Originally Posted by Eri523
This is one of the Microsoft-recommended ways to pass information from a parent process to a child process.
For an example, see "Changing Environment Variables" at http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx . Look at Example 2, which sends the child process an environment variable named "MyVariable".
Mike
So it would be logical to check in updater on its start what process ran it (by parent process id). And quit if it was not your main app. This is going to prevent from env variable frauds. :)Quote:
It can only be started from my main application by ShellExecute.
Nice idea Igor. But checking command line argument is much easier way. But of-course your procedure is more robust.
Anyways I stick to command line argument checking. A simple strcmp() can do it.
Why not just build your updater code as a DLL instead of an exe? That way, your main app would be able to run the updater but ordinary users wouldn't.