Is it possible to pause a process, save the memory contents to a file, and then later reload the file so you can continue the program?
Edit I've been reading about this:
http://en.wikipedia.org/wiki/Setcontext
Is it possible to dump the contents of the struct, and somehow force malloc to allocate the same memory regions?
Technically it is possible, but it would require saving all the system-allocated resources state too - like file desciptors for example and then restoring them. So it's a challenging task.
The easiest way to achieve what you want is to use a virtual machine like VMWare. When you pause it you actually save the whole machine state together with all programs running.
Workflow Foundation in .NET 3.0 and higher allows for workflows to be stopped and restarted.
Well java has serialization and it comes somewhere near to it. Though you can't do it to the lowest level like CPU registers memory address etc since this will require os to be in same state that was when you 'paused' the process.
This can be a good project as a linux kernel module :-)
It's messy to the point of being impossible when dealing with native code, as sharptooth mentions.
However, some programs (iirc emacs, for instance) have used "dump my own memory" tricks to preserve configuration, instead of dealing with config files. This doesn't work on Windows, though, since executables are run in deny-write share mode. But it's a cute (albeit dangerous) trick on linux or DOS :)
This is usually called a persistent continuation (http://en.wikipedia.org/wiki/Continuation). Some languages like SmallTalk and SBCL have first class support for persistent continuations. Most languages don't.
You get a similar effect in UNIX when you SIGSTOP (CTRL-Z, although this depends on your stty settings) a process. I believe it stops the process from executing totally and the address space, while not swapped to disk en masse, can be paged out (or discarded if it's reloadable from the executable) due to non-use.
SIGCONT will restart the process.
One possible solution is something we implemented in UNIX a while back. Make the program responsible for its own start and stop, by passing a command-line parameter to it. Secondary copies of the program would not do any real work, they'd only communicate to the primary copy.
So there were four possibilities:
We used shared memory for communicating with the primary since there were many other things a secondary could pass to the primary. But if all you want is stop and start instructions, I'd go for storing the PID in a known file and checking to make sure the process name is valid.
This gives you a nice idiom for a program that can pause and restart just by seemingly running it again with different parameters.
Depending on your requirements and OS you could try forcing a core dump
I have never tried actually loading a core dumped program back up other than in gdb. It seems like any files you have open or any other state that is not in your programs memory would be lost as sharptooth pointed out.
Another approach would be simply serializing the state you need to disk in your program. It sucks but it is probably the most reliable way unless you are content with suspending execution of the program. That could be done with your operating system's thread library. Or as one poster pointed out with your shell.
Raymond Chen explains why it's impossible. Obviously, not all Microsoft engineers read this, because the Visual Studio compiler does this when precompiling headers. Its dumps its own state after compiling the headers for the first time, and restores itself to continue.