DonationCoder.com Software > Finished Programs

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

<< < (2/5) > >>

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).

Navigation

[0] Message Index

[#] Next page

[*] Previous page