DonationCoder.com Software > Finished Programs

SOLVED: Save Session for Windows (processes, open files, window positions)

(1/5) > >>

tmpusr:
As seen in Windows 8 (I hope):

Less opening apps and files by keeping a list of running processes (excluding system and user-excluded), open files, window positions, sizes, order, and restoring them after a restart or crash.

-Save and restore different sessions.
-Feature: close every process, including system processes like services (e.g. for gaming).

Combined with CryoPID-like app https://www.donationcoder.com/forum/index.php?topic=23613.0 persistence would be quite perfect. Until that day, I'll just keep saving and resuming virtual machines.

It would ideally be able to handle virtual screens, at least a good one, Dexpot - know any better?

See also: Restoring text file positions
https://www.donationcoder.com/forum/index.php?topic=23902.msg216975#msg216975

f0dder:
Until that day, I'll just keep saving and resuming virtual machines.-tmpusr (September 05, 2010, 12:10 AM)
--- End quote ---
That's the only viable solution, really. Saving process state is hard, actually pretty much impossible if you want to cover all possible cases. And to get something even semi-working, you'd need kernel cooperation...

tmpusr:
But it apparently can be done on Linux. Except for that this shouldn't be hard since you only need to store the process names, window parameters, and open files, right?

f0dder:
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".

tmpusr:
Complications abound. It may be something only Microsoft can properly implement. Any thoughts on the topic's idea?

Navigation

[0] Message Index

[#] Next page