Yes, but then you can’t use the BApplication(BMessage*) constructor. So the app normal constructor may have done things already (usually it will already have started a new window), so it may end up not being that simple to manage for app developers if done this way.
This can be solved by allowing to exit and run new BApplication instance. When receiving restore message, new BApplication with archive constructor can be called and replace existing BApplication.
Me too. But a laptop I bought had it preinstalled and I decided to keep it there “just in case”. I wondered why I could not mount the ntfs partition from linux, it turns out that windows does not even cleanly unmount it unless you use “shutdown -q”, and when I found the explanation it also mentioned the caching. Windows keeps a directory full of data for each program IIRC. I am not sure exactly what it caches though, or if applications need to explicitly support it.
Thanks for those details. Interesting. I’ll keep them in mind!
I would still prefer for this to be in the shutdown menu somewhere though, although there probably isn’t enough space in Deskbar for that.
I agree that some sort of selective preservation/reload of application state for everything sounds both cool and useful.
As others have pointed out, Windows’ traditional save everything in ram to disk and put it back later can be problematic because as ram size increases you have to reserve an increasingly large chunk of disk space. It’s also worth noting that if the necessary files get corrupted then resuming from hibernation often fails utterly and you lose everything anyway. Probably if you have ram sticks that are flaky/starting to fail that could cause trouble too.
In addition not everything is necessary or meaningful to save. If I was writing code in an IDE then I definitely want to hang on to that, especially if it hasn’t been saved yet and I would like to return to what I was working on before. Possibly I would want my tabs back in a webbrowser too. On the other hand other things don’t necessarily need to be restored. It’s probably no big deal most of the time if things like the task manager, calculator, file manager, media player, terminal, etc aren’t restored. Being able to put back some things and not others seems useful. But on the other hand it would be nice if the user could specify which things they care about and which they don’t.
Some applications do something of this sort already, at least on Windows, so far as remembering the files that were open so they can be reopened or keeping a temporary/scratch copy of the file’s current state so if the application crashes it can restore itself.
1 Like
And there’d be no real reason why not, right? I mean, suppose every character of code went straight to a disk block rewrite. You have your own computer there, you aren’t sharing it with dozens of other users like the situations UNIX is designed for, and the I/O burden is very small. Why would an application like that - or most applications really - even think of using process I/O buffers that would have to be flushed?
Of course here I’m talking about something beyond what a system shutdown protocol can manage. As long as such a protocol leads to a normal termination of the program, that will flush the I/O buffers. Unbuffered I/O saves you from an unmanaged crash, of the program or the system.
Apple’s implementation is top-notch with versioning and auto save. Using native macOS applications there is no need to worry about interim saving, since every typed character is already saved automatically.
What “Windows people call hibernation” is a part of the ACPI standard and called there this way. Or S4. why Haiku shouldn’t want it? an example of linux struggling (still) to get it right is kind of a weak argument. linux inability to properly handle ACPI sleep states is linux problems. not ACPI sleep states (working perfectly fine on Windows).
for saving the whole system state, maybe? S4 is another boot option - it is a complete shutdown, considering power consuming, yet its boots way faster, than the full start - because all the initialization has been done before. With NVMe SSDs, it would be just an eye blink. and contrary to the several times mentioned “more RAM is more problematic” argument, S4 is more beneficial for for such scenarios - more loaded OS sessions win from it more, than lightweight - just because all this initialized state is preserved. the more state preserved, the better - no need to reinitialize all that again. And secondary storage always will have a magnitude bigger sizes, than RAM. the size of RAM gets larger, so does the size of secondary storage. and its throughput speeds up as well, so if one has 32GB of RAM, he/she/they probably have also several TBs NVMe SSD, capable of doing several GB/s of sequential write (and even faster - read back on restore), so, hibernating in such situations isn’t a problem. but of course, if your system has 32GB of RAM and 64GB of slow eMMC as the only secondary storage, which is an interesting configuration per se, 
then you probably are better off to switch hibernation off, thankfully it is switchable, so this “problem” is made up purely as a bad excuse of this weird reluctance to the standards.
it is much more straightforward, than it looks, certainly not harder, than what you very blurrily give as “a better option” (in fact, imo, what you say would be impossible to reasonable implement, or, putting it another way, if saving states is “better” to be application specific, then they, the applications, know better how to exchange data between their instances, without OS mentoring. oh, it’s already exits - formated files, protocols, distributed component models etc).
At the very rough level, with S4, the FW does exactly the same process as an ordinary cold reset. Starting with “boot options”, there is a “note” from the previous OS session, that it’s about to be a resuming from S4. Then, the check is performed to examine if the machine hasn’t gone through some signifcant changes. it might be tricky, but it’s doable, - we have the working examples, everything worthy, comes with its price. Then if everything is OK, the resume loader, just reads the hibernation file into memory, restoring this way everything - memory mapping, driver data, code, dynamic memory, stacks etc.
how it’s different from “files got corrupted” event in any other scenario? if you hit your computer with a hammer, then it will “fail utterly” with loading. that doesn’t mean, it’s a hibernation problem. on the other hand, hibernation file isn’t more susceptible to corruption, than any other file.
I experienced cases when Windows permanently freeze or hard reset when resuming from sleep.
so? ah, I got it. this is a “proof”, that S4 sucks. this changes all. let’s blame s4, who needs it? eww. meh. let’s do it "the other way"® - hypersleep, or, better yet - iHypersleep, that does something, somewhat. but cooler, than everybody. am I doing it right now? >_>
Hypersleep would indeed be closer to Resume from the Mac side of things, over “Safe Sleep” (which essentially, depending on the sleep level set in Terminal, is fast shutdown or hibernating on the Windows side and on the Mac there’s the label hibernatemode in pmset). But imho, hyper sleeping would be far superior. Including to Resume.
Hibernation needs a space to hibernate to and this can become a problem for those quite the amount of memory (which this thread has already established). And it doesn’t give any of the benefits that having hyper sleep would offer.
So how hypersleep would work behind the scenes ideally is that each app would have a way to store the frozen state in a package (so think of how Haiku has packages and system states now, but extend that) or in cached images.
Another idea floating here is it could work like Tracker and MediaPlayer (and have yet another way to save states).
But either way, hyper sleeping would allow better control (because one could manage sleeping apps where hibernation stores the contents of that session in one big file), multiple and portable application sessions (because one could switch between, load, and copy app states), and while as my concept shows it could apply system-wide when Hypersleep was clicked, there’d also be a way to fine tune what app states get cached to disk and what doesn’t (hopefully in an AppStates preflet or something similar, like in R2 or something).
But tbh, and I’m probably not alone in this, as I’ve seen you defend Windows several times on the forum — why not use all your talents to help improve ReactOS, a free and open Windows NT clone? They could really use help getting it caught up to where Windows is now — including hibernation. But tbh, posts saying do it the Windows way are like me or someone else here heading over to the ReactOS forum and telling them to do things the BeOS or the Mac way. Why the heck would I do that unless I wanted to troll people?
Proper implementation of hibernation is difficult because it requires to handle resuming from hibernation by all device drivers that require a lot of work and redesign of device driver system. It will be likely not implemented in Haiku R1 and nobody seems trying to implement it.
Personally i don’t think that hibernation is useful, I disable it everywhere because it waste disk space and it can cause troubles. I use sleep or complete shutdown. Starting system without hibernation is fast.
a device driver system, that doesn’t care about their devices power management, would need to be redesigned anyway, honestly. other than this, hibernation is a lot simpler, because of exactly what it preserves - the state of the software components, handling the machine. but eh, whatever.
the full boot with all kinds of probing, initializing is faster, than the sequential read of one file and filling RAM with its contents, really? okay, then!
the only thing, to your lengthy by words and empty by meaning post, that really asks to be replied is the highlited:
dude, again, since you are an apple fan, it’s not easy for you, I understand - hibernation, S4, is an industry standard, written out in the ACPI specification, get it? and what you are talking about is, sorry, - a meaningless gibberish, the only recognizable details of which are the fancy names, taken from macos and conviction, that it’s “superior”. that’s not enough, you know. drawing nicey mockups isn’t either.
and second, you see, you confused Haiku with apple. just the same way, I could, if were as irritated by your apple fanboying, as you are with mine for Windows, say that why don’t you go on apple fan sites and direct your artistic enthusiasm of showing pictures there, instead of showing up here and making numerous “let’s make it as is in macosx” suggestions. but I haven’t done this. why? because I think, that unless it’s not against the forum rules, it’s not one’s freaking business as to what I “defend”. is expressing liking Windows prohibited on this forum? no? was I on topic, even if someone only saw “windows ways defending”? yes, I was, - I argued with people, saying that hibernation is “trash”, followed by far-fetched arguments; because unlike this blurry, pinky, BS with sparkles, S4 is an established (and proven by time) way to go for every OS, that wants to have been used at least a tiny bit by desktop users conveniently. so, what annoyed apple fans should do with their inconvenience of having me here?
Boot time difference is not significant for practical use, but regular system loading is more robust: it will not fail because of misbehaving driver power management, changed hardware etc. . It will also clear system from possible memory leaks, data structure corruptions, RAM loaded malware etc. .
Nobody forces to implement all specification features. Some of ACPI features are undocumented and Windows specific.
Well this one (who tangled with your last post) will apologize and offer to chill on differences 
No, Sx states and basically ACPI is just overengineered crap which misses the point where it actually checks for the running operating system and uses OS specific codepaths in DSDT.
What do you think which OEM will run to implement a case for Haiku?
Or should Haiku just pretend it is Windows just to get the neat features enabled?
I have only 1 problem with programs restoring their state, imagine the following scenairo:
You have a graphics editor with a bunch of 8K images open. At exit the program saves the list if the currently open documents so it can restore them.
Now you want to open a completely different image just to make a quick change, so you start your program, expecting a fast launch, but instead of completing the required changes in 1 min now you are looking at loading bars for the 8K pics for minutes.
Software states can be horribly irritating, and i am fully against them and disable them everywhere, because i am old enough to know what i want to do, but many program doesnt allows to disable this “feature” which drives me 10/10 crazy, annoyed and angry (on this level you can contact electrical leads to my skin and i would be able to power the whole damn earth with electricity, that kind of angriness).
At least a killswitch should be implemented at OS level to allow to disable this “functionality”.
Proposed feature do not automatically restore application state on launch. Applications state are saved and restored by special shutdown option. Application state saving is requested explicitly.