"But what about 5 copies of OWB, with opening pages and alt ? Will it saves too ?:) If it will be save everything just 1:1, and reboot will be no more than 5-10 seconds, then, it can be really good solution."
That is the idea.
And it's a good idea. It does need built in protection against triggering the very action that caused the crash in the first place. One of my friends said that him and a few others created a page with javascript that continually opened new windows. This was back in the days when Netscape was a major browser. Anyway, visiting this page would trigger a mass opening of windows until it crashed. The browser was designed to restore your settings from last time and so, every time that the browser was opened, it would visit this page, spawn hundreds of windows, and crash. An infinite loop of crashing.
This is why Firefox asks you if you want to restore your pages after a crash.
This is why Firefox asks you if you want to restore your pages after a crash.
But that is supported by Firefox itself, right? I mean, tabs are restored when I close and open Firefox again, no matter if it crashed. So in this case, OWB has to support that. It is right that the OS keep track of every tab/window opened by the applications or would it be better to keep track of what it is running and then each application keeps track of its tabs/windows?
>And it's a good idea. It does need built in protection against triggering the very action that caused the crash in the first place. >One of my friends said that him and a few others created a page with javascript that continually opened new windows. This was back in the days when Netscape was a major browser. Anyway, visiting this page would trigger a mass opening of windows until it crashed. The browser was designed to restore your settings from last time and so, every time that the browser was opened, it would visit this page, spawn hundreds of windows, and crash. An infinite loop of crashing. >This is why Firefox asks you if you want to restore your pages after a crash.
That's the way it must be done. Another addition to that would be that, if OS already asked user if one want's to restore everything (if restoring was set automatic by the user in OS prefs, it must be possible that the restoring could be disabled, for example by holding down R button during reboot or from BOOT menu) , OS tells the application to restore, so that the user would not have 10 applications asking the same question.
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
From other side, to many question like "do you want to save that and that and that", in end will annoy very well too, if it will have too much time.
The real problem, it's just fast reboot, and have the same apps running on the same stage , as before freeze/hang/crash happenes. If after crash, many progrs will ask for something, then, for first, programm must to do it (support that), for second it can't help with freeze/hang.
Maybe somethign like "auto-save enable yes/no" for prefs, and every 10 minuts (for example) save state, then after reboot everything will as 10 mins ago will be ok too .. but .. anyway, spawning and reruning all of these programms will take time 100%. And there is still question, what will be faster : reboot and run manually, or boring with auto-save, then black/white lists, then ask from programms need/not to save, and after all, all these programms will re-runs after reboot (which also will take time).
Something like that (restore save), need to do, but, if only it will be fast, light and nice. Of course for begininig it possible to add to GR button "save-restore/reboot". But what about hangs/freezes, which still, happenes from time to time ?
The system would enable OS to time & send "quicksave" orders to applications every n. seconds or only when user triggers it or when grim triggers it, etc...
(and quicksave must not overwrite the actual file that is opened, so that it does not save stuff that user does not want on top of the previously opened file, so quicsave must not be same as "save". More like "save to temp" or "save processed stuff to temp" or "save changes to temp".)
So, quicksave should be usable also when user is not going to do reboot anytime soon. It can be used also as a "just in case" measure. Also a UPS power supply indicates that it is running out of power, AOS could tell apps to "quicksave" and later shutdown if (optionally, again) needed.
The feature should be documented first, then implemented to OS, then application developers could start to use it. And ofcourse it does not work with old apps.... untill the AOS7 that I mentioned.
(AOS7 would have perfect resource tracking and MP anyway and it would be able to "freeze to disk" any/every application, including 68k apps in UAE, etc. If user tells it to do so, etc. .... ok .... it's like a "BuiltInActionReplay" http://en.wikipedia.org/wiki/Datel_Action_Replay)
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
Well, MP might help to keep the system stable if a "bad coder" (I call them "lazy coders") released his program to the public. But does it help then to make the software better? Does it help to make the bad, lazy coder an excellent one?
No, it doesnt. It helps to drop software quality to a level that is, well, "accepted" by the public. Thats what the origins of the quirks I told of before are. These are e.g. drivers distorting the timing of Windows, distorting other processes, and the OS isnt able to do anything against it. I have to reboot to get rid of them. Until next distortion...
"Accepted" flaws in software engineering that would have been fixed if the OS wouldnt catch those flaws the "comfortable way".
It sounds like you misunderstood what MP does! MP most certenly does NOT hide errors in comfortable ways, on the contrary, it exposes the errors by crashing the programs that have a bug and presents some debug info so the developer can fix it.
OSes without MP on the other hand (like AmigaOS and VxWorks) hides the bugs by allowing incorrect behaviour and very lazy programming.
Just look at all OS1/2/3 software which was lazily and incorrectly written. Now, when run on OS4 which has some MP these bugs are exposed! Unfortunately most of these developers are not around anymore to fix there old bugs and we have to live with crashing 68k software and the inability to implement better MP in OS4.
Quote:
This "help" by catching software flaws in "a comfortable way" supports lazyness of developers, who are more and more working with highly abstracted layers for things that arent as complex in reality without thinking about it.
This is more a design desision and not so much because of help from MP IMO. I'm right in the middle of this hell of highly abstracted bullshit right now developing mobile phone apps. It's horrible but I wouldn't say it's because of MP.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I guess this discussion is off topic but you could do automatic close and restart of applications using application.library and launch-handler. But apps have to support that themselves. (One can send Quit, ForceQuit and OpenDoc messages, for example, to all apps through application.library.)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
IMHO, the OS should not be bothered with any "quick save" or "auto re-open" stuff, it should be handled the the program itself. More specifically, I imagine something like this:
User enables "auto state saving" in the prefs (or perhaps it is enabled by default). Then every X seconds the app saves it's state, so that if it crashes (etc) then it can offer to restore that state the next time it is started. Firefox basically already works like this, and it saves a LOT of time, without getting in your way.
At the very least, I'd like to see apps like OWB save their state when the user quits them!
One thing the OS could do is send an "emergency save" message to apps, if the user has just pressed Ctrl-Amiga-Amiga (or similar).
One thing the OS could do is send an "emergency save" message to apps, if the user has just pressed Ctrl-Amiga-Amiga (or similar).
For sure almost no one will add that to their programms :) And all the current programm does not have that => the best solution imho do everything on OS side.
Or maybe just any 3dparty programm, which user can run in background, and it will save states, then restore after reboot. If not want, then no run that programm.
ChrisH wrote: IMHO, the OS should not be bothered with any "quick save" or "auto re-open" stuff, it should be handled the the program itself. More specifically, I imagine something like this:
User enables "auto state saving" in the prefs (or perhaps it is enabled by default). Then every X seconds the app saves it's state, so that if it crashes (etc) then it can offer to restore that state the next time it is started. Firefox basically already works like this, and it saves a LOT of time, without getting in your way.
At the very least, I'd like to see apps like OWB save their state when the user quits them!
One thing the OS could do is send an "emergency save" message to apps, if the user has just pressed Ctrl-Amiga-Amiga (or similar).
IMHO, the OS just needs to track which applications were open, and provide an API that makes it easy for applications to detect whether it crashed last time, and load/save state data. The OS would reopen the applications, and it's the application programmer's task to make sure that the application restores its own state.
@Hans In case you missed it: I would like apps like OWB or TuneNet to save their state ON EXIT, so it looks the same when you start it next time. It would be a bonus (and perhaps easily implemented) to save the state at frequent intervals.
(I guess I am wanting this behaviour for "viewer/player" kind of apps that do not traditionally have any save functionality. But "editor/creator" apps that already offer the ability to save documents don't really need this so much.)
My PictureAlbum app already works a bit like this - each folder you view has it's own state, which is saved when you leave the folder or quit it. When you restart the program, it ask what folder you want to view, and suggests the last folder you viewed. Thus accepting the suggested folder causes it to be in the almost identical state as the last time it was quit.
"Saving on exit" mean pressing buttons, pressing gadget, think about it , and loose the time. That boring. Because when crash is happens, i just want to press reset button, or magic combo for soft-reset, or button in GR window only, and after reboot, everything the same as before crash.
I think "my" quick save is exactly the same as "emergency save".
@Hans
"IMHO, the OS just needs to track which applications were open, and provide an API that makes it easy for applications to detect whether it crashed last time, and load/save state data. The OS would reopen the applications, and it's the application programmer's task to make sure that the application restores its own state."
Yes, that's pretty much the idea. But I'm pretty sure that almost every Amigan want it to be totally configurable. IMO, The OS is (and applications exist) to serve the user.
@Chrish
"It would be a bonus (and perhaps easily implemented) to save the state at frequent intervals."
Would it be harmfull if user could set the OS to time all apps (or some apps) to save automatically their state & draft/snapshot of data, instead of configuring timer for every application separately?
(if some app does not support emergency save/ quick save, then the OS could report to some log of that kind of sh*tty application that does not reply to the request. Surely pretty soon apps would start to improve.)
There are times when I would like to reboot the OS and have it automatically load back to the same situation with all apps, where it was before. On Linux I sometimes do it to change kernel "on the fly". On AOS4.1 I might want to change between debug kernel and normal kernel "on the fly".
.... To me all this sounds like a killer feature to an OS, but perhaps it's just me.... some people even insist that any R&D on OSs is futile work. And that we should just copy windows and not to try to invent new things. 8-o
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
On Amiga one could configure F11 to cause function like "emergency save" + poweroff, F12 to cause "emergency save" + reboot, shift+F11 to just "emergency save" just in case my helloworld divides by zero, shift+F12 to just finish disk I/O + SW shutdown in 0,5 seconds.
Ofcourse one should be able to set what happens when one "ticks" on power button... ... ... ... perhaps that should not function at all if my 4 year old is in the room ... .. ... job to xena to handle sensors that detect my kid's precense in the room and then temporarily disables the power button ... ... ... and send SMS to me.... .. ... ... .
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
Couldn't you use a named memory section, where a task needs to know the memory area name to gain access to it? And then generate a unique random name in the initialisation, passing the name to the threads as they are spawned.
Another thing they could have done, since they didn't go down the full sandbox path, is to just allocate a whole 512KB of RAM for every 68K process (and more if set in say, a ToolType), and let the 68K process get all it's allocations from that pre-reserved space. Then if it overruns or accesses illegal addresses it doesn't matter. If it calls OS functions, it should only be reading anyway not writing to memory owned by the OS. Exceptions could be made for filesystems or device drivers, which are more likely to be extensively tested and 'play nicely'. 68K apps shouldn't be communicating through writing to public / shared memory and if they are, fine, create a named memory section exclusively for 68K apps to share and let them all have access to that by default. But not access to memory used by PPC code.
Any memory allocations made by a 68K process should default to SHARED but PPC code should be protected by default.
Sure, it's maybe not efficient but memory is cheap and ample now. And chances are low anyone needs to run 4000 68K apps simultaneously. Even Cinema 4D, lightwave or page stream are happy with only 16MB, they never expected to get more.
i'm facing some troubles now when i'm porting some stuff using my clib2 version. I know it could be a bad code but why some OS when you do a "free(pointer)" doesn't crash everything? This is (i suppose) the user are asking. If i get a DSI in the kernel (or any other OS component) the problem is not only i'm writing bad code. and if i use:
if (pointer) free(pointer)
to avoid the problem, yes will fix the problem on my code but doesn't fix the problem in the kernel (or any other OS component). This is the thing i don't understand at all. Why the OS component doesn't check its operation and avoid the crash?
Why the OS component doesn't check its operation and avoid the crash?
Because it will be those parts which piece by piece mean memory protection : you protect things there, there, there, and in end our OS are bloated and slow. Yes, some things still can be protected , just few, and it will no slow down a things, but full memory protection is that bloat which we happy not have. Yeah, not user friednly, yeah, not attract new users, but all the oses which have memory protections always ends up in crashes anyway and still, just with bloat on top.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
