On 10 Sep, 15:56, "Alf P. Steinbach" <
[email protected]> wrote:
[...]
But I want to know how to do this in C++.
And the answer is: it depends on your platform, but for any
given platform, it will be the same as in C, or Ada, or any
other language.
Of course, if you knew that to begin with, you probably wouldn't
have had to ask the question (here or elsewhere)
. IMHO, the
question is OK, but the only "acceptable" answer is that you
need something platform specific, and will have to ask in a
corresponding group.
I, and many others, won't hesitate in posting an answer for the
platform we know best as well, when we point this out, more or
less as an example of the sort of thing you might be looking
for. And providing the answer is very short and simple, and
unlikely to spawn a long, off topic thread.
[...]
Perhaps I am being stupid, but I am looking for the code to do
this in C++ :?
Without using some system specific API, I think you're out of
luck. The usual solution I've seen for this sort of thing is to
use some sort of scripting language (Bourne shell under Unix):
the script verifies any number of preconditions (software fully
installed, etc., starts the actual binary, waits for it to
finish, and then performs whatever additional actions are
necessary, depending on the return code of the binary. (In many
of my applications, the execution of the binary is in a loop; if
the program stops, for whatever reason, it is immediately
restarted.)
[...]
I.E. Do i need to kick off another thread / process to do this?
It depends on the system, although I don't know of a system
where threads will help. Unix has a system function which will
change the image of the running process, but this is far from
universal, and the way it works is not necessarily what you want
anyway.
Will such a thread process die with the exe that creates them
if so can i make them persist?
By definition, a thread cannot outlive the process which
contains it.
Or is there a library / include that contains a method to do
what I want (i.e.
std::fstream::replaceRunningEXE(<exename>,<newexe>) ).
Certainly not. It wouldn't be implementable on most systems.
My C++ is limited in that i generally just hack other peoples
code to make it do what i want it to. Other than that I dont
really know what I am doing (i've only been coding
(reasonably) heavily in C++ for the last 5 months, and only
used it briefly before that).
Which shouldn't be a problem here, since the solution is not
C++.
[...]
1. Start a new process, stop the old, delete old exe, rename new exe
and start exe.
2. Create batch file (with a sleep command in it), call batch file,
kill current process (batch file does blah blah blah, start new exe)
3. call a second exe whose job is to kill the updater, delete
updater.exe, rename updater.new to updater.exe, start updater.exe,
terminate.
1. Prefered solution: Surely when I kill my exe all process that it
instagated will die to.
I think you're confusing two very distinct things. An "exe" (a
binary executable) is a file format. You don't kill an exe, you
delete it. You kill a process (forget about threads for the
moment). Processes are related to exe files in that 1) the exe
file provides the initial binary "image" for the process, and 2)
under some OS's (Windows, most modern Unix), the exe file
continues to provide the virtual image on disk for the
non-modifiable part of the process' image (the text segment, in
Unix speak). How 2 is handled depends very much on the OS, but
it may mean that overwriting the exe file will cause the running
process to crash (Solaris---but because of particularities in
the Unix file system, you can delete the exe file without
disturbing the running process), or that the OS won't even allow
you to overwrite it as long as the process is running (Windows,
I think).
Note that because of the way the Unix file system works (entries
in the directory are not files, but pointers to files, and you
don't actually delete files, but entries in the directory---the
file will only be deleted when there are no more pointers to it
in the directory, AND no more users of it), you could implement
something very much along these lines under Unix. From what
little I know of Windows, however, it isn't possible there, and
there are numerous reasons why it is not the preferred solution
under Unix.
2. Very messy not a prefered solution unless unavoidable.
It seems to be the preferred solution in practice, even under
Unix, where your solution 1 is possible.
3. I have a 2nd exe for the sake of it, requires extra code
and I have to be able to update it as well in case bugs are
found in it.
What I am looking for is the most efficient method of the above to
use.
Solution 1 is the one I would like to go with but I dont know
a) if it will work
b) how to go about implementing it ( I need help with the thread/
process code as i have never done a multi-threaded app or a multi-
process app before).
Some things are easier and better done in other languages than
C++. This is one; the basic command interpreter of your OS is
probably more appropriate than C++ for this particular job.