On linux, you've got the advantage that the kernel is opensource, and thus it's possible to add the necessary support code - you can't really do that on Windows. Sure, you can write Windows drivers, but the functionality required to do a process state save/restore requires some pretty deep system hooks which I doubt are available to 3rd-party driver developers. Also, the CryoPID "Things that do/don't work" list does show that it's not exactly perfect
And it's a lot more complicated than you might think
- capturing "just" the raw process state (memory map, thread contexts, ...) isn't too bad. The problem is all the "external" resources a process contains (files, sockets, graphics resources, etc). Some of the state
can't be reliably restored (like socket connections), other is
hard (like DirectX structures... what happens if you resume an app after changing your graphics card? Or even something less radical like resuming an app while another graphics app is started). Files aren't simple to handle either, they might have been deleted or changed while the app was suspended, or their access rights could have changed. And what if the app was suspended while it had pending file modifications? Also, this is just the
conceptual problems you have to deal with, there's also implementation "details".
