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

[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 http://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
http://www.donationcoder.com/forum/index.php?topic=23902.msg216975#msg216975

[f0dder]

Until that day, I'll just keep saving and resuming virtual machines.

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?

[f0dder]

On Windows, it's definitely something I wouldn't feel comfortable using if it wasn't developed by Microsoft - or at least hadn't had a lot of MS cooperation while developing.

Even if a 100% reliable solution was implemented, it would be at the functional level of VM suspend/resume or hibernate... which is good enough for most stuff, but definitely isn't perfect (network connections that have timed out etc). Given the complexity level of implementing, I'm not sure it's worth it. What's the purpose, anyway? Saving a bit of RAM by terminating processes, but being able to resume them fast? For that usecase, I'd really just stuff more RAM in the system. Can't really think of usecases where I can't think of a better solution, but you might have some better ideas

[tmpusr]

The CryoPID idea is hereby dead and buried or at least delegated to MS and VM save state works well enough for me anyway.

Anything on the topic of simply restarting the processes and opening the files that were running when shutdown/restart/log off was issued or a crash occurred? Do you see any complications there? I don't.

[f0dder]

Well, don't rule it out entirely - I'm just saying it's a complex undertaking, and I think it's outside the scope of most members here at DoCo to undertake such a project . But perhaps it would be somewhat feasible to handle for an application virtualizer like SandboxIE? Still, not trivial.

I think you should detail your usecase(s) a bit.

For handling a crash - how should the application be restarted? You'd need some kind of snapshot of program state before the program crash. The OS has no way to know when a program is stable, so you definitely need application-level support for that. Restart/logoff is easier to handle, since the program can just be assumed to be in a valid state.

To restart or resume an app, you either need to do a full dump/restore of application state (which, as I've said a couple of times, is complicated), or you need some application-level support. There really isn't anything inbetween. Sure, the OS could restart an application, but then what should it do? Without a full state dump, how do you make the application go to the state it was in?

[tmpusr]

I'm requesting a much simpler thing: just start the apps that were running, just like you do manually, and open the files that were open in them, also just like you do manually and set window sizes and positions back to what they were, just like... That's all. I think there already are separate apps coded in AHK that have all or most of the required features.

[f0dder]

Thing is, that isn't simpler

Yes, you can detect which files a process has open, and you could re-open those files and set filepointers to the right position, etc. But without a full state restore, how do you get the (restarted) application to know it has those files open? The same goes for open windows - you can reconstruct the windows GDI widgets, but there's application-side state as well...

You can either do a full application state save/load (which is hard), or you can do per-application support (like, AHK sending key/mouse input events... which is a really fragile "solution"), or you can program restore logic into each individual application (which is the route taken for VS2010 apps).

[tmpusr]

Just open the apps (like run app1.exe, run app2.exe, that were in the task list and the files that were open in them, if any (run app3.exe file.txt) and I'm happy... is there more to it? What?
Over at the AHK forum there's code that does window size and position save/restore.

[f0dder]

Putting a filename on an application's commandline doesn't necessarily open it - works for a lot of apps, but not all. Also, there's the issue of figuring out which files the application has open. You can enumerate the files a process has open, but that's going to include a lot more than what you think you're working with - also, some applications only use the files while loading/saving, and thus the files you're working with isn't detectable without knowledge of the specific program.

Window size/position restoring, yes... you can reposition windows the application opens by itself, but you can't make it open child dialogs without specific knowledge of the app. And the window will appear at default location before you reposition, so there'll be a bit of flickering

[MilesAhead]

Basically you would have to freeze the state of things to some storage.  Then later load it into memory, and have it thaw.  Only thing is, as f0dder points out, there are dynamic things that don't react well to being frozen.  Stuff like network connections etc..

Probably the best you could hope for would be a window tracker that would save the positions of all top level windows.  You may be able to get the desktop to come up with apps open at certain positions.  But in the case of things crashing, if you perfectly save the memory state of the app that crashed, chances are high you've reinstated the conditions that caused the crash. It will just crash again. Most crashes are memory issues.  Invalid access, uninitialized pointers etc..  you're just freezing it only to crash again when you thaw it out.

[tmpusr]

Even a partial solution would be nice to have, just restarting the apps and repositioning windows, for which code already exists:

Save and Restore window sizes & positions
http://www.autohotkey.com/forum/topic55937.html

[MilesAhead]

This PCMag utility looks like it may be helpful:

http://www.pcmag.com/article2/0,2817,2339650,00.asp

Usually on these things you can download free if you sign up for zdnet and let them send you emails.

Hmm, just took another look.  They don't seem as generous now.  But there must be some rough equivalents on sites like Softpedia, Snapfiles etc..

[MilesAhead]

This app seems like it would at least save window positions and move windows to those when it spots a matching window according to several criteria.  It may be worth a look:

http://www.softpedia.com/get/Desktop-Enhancements/Other-Desktop-Enhancements/HandyThing.shtml

[MilesAhead]

I just ran across this freebie:

http://www.computingunleashed.com/save-restore-desktop-session-restore-when-windows-starts.html

[MilesAhead]

I just noticed another utility for saving Windows layout. I haven't tried it myself.  The description makes it sound pretty versatile as far as windows matching:

http://www.softpedia.com/get/Desktop-Enhancements/Other-Desktop-Enhancements/Windows-Layout-Manager.shtml

[MilesAhead]

I'm experimenting with this one:

http://sourceforge.net/projects/winsize2/

It individually memorizes windows size/position when you hit a hotkey. It's an ahk compiled script with source included. Looks like it may be handy for those windows that don't remember their position. From looking at the options notebook it seems to use the class name as well as window title or title substring to recognize saved windows.

More for those pesky windows that refuse to remember where you put them than for saving a layout.  But I thought it may be of interest.

[worstje]

Ok, call me silly, but what is it that the hibernation feature in Windows does not have? It's functionally pretty identical to the save-the-vm-state thing people keep offering up, or so I believe anyway.

Sure, it doesn't deal with crashes etc very well, but I wouldn't know how well VMs would deal with that either...

[JavaJones]

Another interested related app I just read about today:
http://alacritypc.kensalter.com/
Haven't tested.

- Oshyan