OS/2 Auto-restarting apps after crash / restart

[RickCHodgin]

Has there been any movement on changing the way OS/2 auto-relaunches the running apps after a crash / restart?

If not, I'm thinking that is something that needs overhauled as well.  I think at the very least it should have a confirmation screen that comes up to verify which running apps should be restarted, for example.

[Doug Bissett]

I NEVER restart anything automatically, except what I put in STARTUP.CMD, or startup folders. It causes nothing but problems to try to restart anything else (possibly a program that crashes the system at startup, which puts you into a boot loop). Asking is not much better, because a user may not even realize what is going on.

The line:

Code: [Select]

SET RESTARTOBJECTS=STARTUPFOLDERSONLY,REBOOTONLYin CONFIG.SYS is the default in ArcaOS, and it controls what, if anything, gets restarted..

[RickCHodgin]

I NEVER restart anything automatically, except what I put in STARTUP.CMD, or startup folders. It causes nothing but problems to try to restart anything else (possibly a program that crashes the system at startup, which puts you into a boot loop). Asking is not much better, because a user may not even realize what is going on.

This is part of my thinking.  By modifying the boot process after a crash so it registers hard locations (to committed-to-disk files) for things it retries, then it could, rather than enter a boot loop, report on the second re-attempt that it failed on the first re-attempt and that it should not be restarted.  That would prevent the multiple-boot-loop per one app, though each app that was running could theoretically have its own dual boot attempts.

But if there was a way to give the user dynamic control over things at startup.  Maybe even something like you press a key combination at any time during startup, then you get the interactive boot sequence, etc.

I'm just trying to think of things I see as issues with OS/2, and things that should be at least looked at in considering a replacement version like ES/2.

[Doug Bissett]

IMO, there should never be any reason to start anything that isn't in CONFIG.SYS, STARTUP.CMD, or the STARTUP folder(s), when the system is booted. If something else is running, when it shuts down, it can be manually started, if desired, when the user is successfully past the boot sequence. If something unexpected gets started, it only adds to the confusion, especially if something else got damaged at shut down.

I would say, "don't even consider the possibility". It was never a good idea, and I haven't seen any evidence that other operating systems allow such nonsense (but I haven't used most of them). Others may think otherwise.

[RickCHodgin]

I would say, "don't even consider the possibility". It was never a good idea, and I haven't seen any evidence that other operating systems allow such nonsense (but I haven't used most of them). Others may think otherwise.

I think the feature is a good one, but it needs to be expanded to be useful to a user.

Applications should have a mechanism to register with the OS key information about their current state so they can snapshot themselves at any point, and then restart exactly at that point.  This would be useful for a message sent at shutdown, as well as a periodic thing such as each time the user does something update the snapshot.

I think the app should request a base object from the OS, then when it wants to update it lock it, update it, and unlock it, where the unlock operation auto-triggers the OS to save that state to its internal buffers so that on startup it can restart to that point, signal the app, and when the app starts up it can query the OS for its prior saved state (if any) and auto-relaunch to that point.

I think it would be a nice feature.  It would even be a good one for an app to implement to allow a new type of menu option, instead of just File -> Exit or Close, now File -> Suspend or Suspend.  It updates that OS object, then exits, so it can resume right where it was later.

Have always wanted that feature in an OS.

[Doug Bissett]

I think the feature is a good one, but it needs to be expanded to be useful to a user.

I think it will be a lot of overhead, with very little advantage. Programs would need to be (re)written to use the feature, and ported programs (most of them, these days) probably wouldn't  work well with it, unless they have some major changes. Leave it on your todo list, but there are many things that need to be higher priority. Suspend/Resume comes to mind, and that may be related.

It would even be a good one for an app to implement to allow a new type of menu option, instead of just File -> Exit or Close, now File -> Suspend or Suspend.  It updates that OS object, then exits, so it can resume right where it was later.

That is actually possible today, if the program is written to do it. I suppose that some sort of OS support would make it easier to do, but the program would need to be written to make use of such a feature. I suppose that you could just snapshot the memory spaces, but how would you handle DLLs, and things like video buffers? Sounds like a lot of, time consuming, work, to me.

[Dave Yeo]

Just having a working hibernate would have mostly the same effect, resume from hibernation would open apps at the same point.

[RickCHodgin]

Just having a working hibernate would have mostly the same effect, resume from hibernation would open apps at the same point.

I had that thought too, but hardware suspend / hibernate is a little different.  It requires the same hardware, everything about the machine is saved / suspended.  With auto-restart, new hardware could be employed, new drivers or driver versions.  It would just save you the steps of manually getting back to where you were and it would be contextual, meaning each session ends and resumes as you were when shutting down.

I'll think about it.  Still not convinced, but am leaning that way.

[RickCHodgin]

That is actually possible today, if the program is written to do it. I suppose that some sort of OS support would make it easier to do, but the program would need to be written to make use of such a feature. I suppose that you could just snapshot the memory spaces, but how would you handle DLLs, and things like video buffers? Sounds like a lot of, time consuming, work, to me.

The app would have its normal launch / startup, but then would receive a new message with its last saved auto-startup object.  It would parse that object and self-restore its context.  The OS would've provided the across-boot storage of context, sending out new messages instructing the app to save / restore its state.  The app could simply ignore those messages, but having OS facilities would make it easier to utilize and implement.  There would be no limit beyond physical resources on what each apo could store.

The OS could also provide slots per app, with each one being its own context.

Using that mechanism, multiple Suspend / Resume states could be available, and not just at auto-restart, but at any time.  Rather than File -> Open, there could be File -> Continue where you continue right from where you left off.

I'll think about it.