First off, yes the kernel can also do this, second, if the dump fails, like I said, the app MUST make a dump as it starts. This dump should be pre-configured somehow (a file, or key or something). This is to assure correct ability no matter what. And as for how:
1- Maybe read the memory address at which the error occurs, and find links to other referenced addresses? Windows can tell where an error occurred... Why couldn't I?
2- WHY DO YOU THINK I'M HERE?!?!?
New OS
1st, yes the kernel has a dump. 2nd, since all the apps (even the kernel) must create a basic dump as it starts, if the re-dump fails, it can use info from the original one (it should contain basic info for thread maintenance)
Here are two examples:
1:
Two software apps have an incompatibility ( a system setting say ). If one (or both) bomb out because of this, they can use a predefined default from the dump in order to DYNAMICALLY adapt to the issue.
2:
Say a program bombs for some reason, and say it was not detected in time. Say the kernel made a boo-boo and tried to write over a memory sector because it though it was orphaned from it's process (automatic memory freeing concept). Then say they both did this at once. Windows would bluescreen right? But no! The kernel uses it's dormant thread to recover basic functions. Then it uses the dump to re-create the environment as it was moments before the issue. It finds the errors address, and any linked ones and skips those procedure calls, instead using basic ones left in it's original dump. The app uses a similar procedure, and voila! No more issue. And as for why not just terminate the app? Imagine an environment in which no incompatibilities or errors relating to memory can occur.
Here are two examples:
1:
Two software apps have an incompatibility ( a system setting say ). If one (or both) bomb out because of this, they can use a predefined default from the dump in order to DYNAMICALLY adapt to the issue.
2:
Say a program bombs for some reason, and say it was not detected in time. Say the kernel made a boo-boo and tried to write over a memory sector because it though it was orphaned from it's process (automatic memory freeing concept). Then say they both did this at once. Windows would bluescreen right? But no! The kernel uses it's dormant thread to recover basic functions. Then it uses the dump to re-create the environment as it was moments before the issue. It finds the errors address, and any linked ones and skips those procedure calls, instead using basic ones left in it's original dump. The app uses a similar procedure, and voila! No more issue. And as for why not just terminate the app? Imagine an environment in which no incompatibilities or errors relating to memory can occur.
short of physical memory module corruption, when exactly is the kernel/applications going to go into meltdown mode where you would need memory redundancy? The only way I could see 'corruption' happening is only due to insecurities in the design thus being (inadvertantly) exploited to harm the core kernels' operation. Also, apps will do what they are designed to do, if you make dumps that can self correct the 'corrupt' code, it will only correct it back to its origional state which could still be a corruptive program to begin with.
I think there "MIGHT" be applicative properties for this project, but I believe the path you are on will lead you nowhere great.
BTW, I wasn't all that impressed by JamesM's initial reply, it was unnecessary and could have been more productive not being said at all.
I think there "MIGHT" be applicative properties for this project, but I believe the path you are on will lead you nowhere great.
BTW, I wasn't all that impressed by JamesM's initial reply, it was unnecessary and could have been more productive not being said at all.
Website: https://joscor.com
Morning!
Having sobered up somewhat over the night I've decided to (a) not post on osdev.org after drinking whisky and (b) make a serious, to the point reply to attempt make up for the initial one.
Your idea seems good, or would be had memory management units not been invented. The idea of storing a "backup" of memory somewhere and restoring that sounds good in concept, but there are a few problems I can think of:
* Programs are essentially state machines. They can be in different states at different times, and normally these states aren't defined explicitly in the program but rather can be observed by their behaviour, for example a program may (1) wait for input, (2) do some processing, (3) output.
If a problem occurs at a latter stage of (2), the only safe place to restore the program to is the start of (2) - that is, a state transition boundary. You may say "Well, why's that? if I set the instruction pointer the same as it was 1 second ago, and all memory contents too, what could go wrong?". The answer to that is that no program is a "black box". Damn near everything relies on I/O, be it Oracle accepting transactions, or a CD burner burning to CD.
You only have control over the program execution and what's in RAM. You have no control over I/O, and thus rewinding time in that respect is an impossibility, there is no way you can restore a state perfectly unless all the I/O devices (be they actual devices or remote computers) are restored to the same state. And that is just impossible.
* Yes, windows can tell you 'where' an exception occurred. I use 'where' in inverted commas because it's not actually where the problem was. For example, my program stupidly reads from a null pointer. So it tries to read the location "0x00000000". The program is killed. Where's the problem there? How do you fix it? Answer - you can't.
There are very few errors transparent enough to be recoverable, which is why most operating systems just don't even attempt to recover. They just kill the process and possibly restart it (Which is a sure-fire way of returning to a valid program state boundary - the initial one!).
Another example is a JIT compiler. These programs will deliberately cause illegal reads and writes in order to trap an exception condition, also known as "lazy compiling". It will leave an area of memory unmapped, and point pointers at it so that if those pointers are followed, a trap occurs. This means that the JIT compiler doesn't actually have to compute everything at once, rather it can wait until it's needed. In this case, how do you distinguish as to whether the trap is valid or not? How can you, the kernel, who doesn't know anything about the program or its characteristics, make a decision on what to do? If you 'rewind' the program, the program will continue in an endless loop!
* My last point is that I think you may have things confused:
As to the latter half of your statement, you seem to not understand what virtual memory is about. In any case, a process itself can never free or allocate its own memory, it must system call into the kernel to ask the kernel to do it. Only the kernel has control over the hardware page tables. The allocation/free mechanism will also be mutex-protected, so only one thread on one processor can allocate/free at any one time. So firstly the case can never happen. Secondly, only managed OS's running managed languages (such as C# or java) have inbuilt garbage collection.
The above is what makes me think that you've come up with a solution to solve a nonexistant problem, and are still backing it to the hilt instead of doing the reading you should have done in the first place before posting such gems as:
Hope this helps somewhat,
James
Having sobered up somewhat over the night I've decided to (a) not post on osdev.org after drinking whisky and (b) make a serious, to the point reply to attempt make up for the initial one.
Your idea seems good, or would be had memory management units not been invented. The idea of storing a "backup" of memory somewhere and restoring that sounds good in concept, but there are a few problems I can think of:
* Programs are essentially state machines. They can be in different states at different times, and normally these states aren't defined explicitly in the program but rather can be observed by their behaviour, for example a program may (1) wait for input, (2) do some processing, (3) output.
If a problem occurs at a latter stage of (2), the only safe place to restore the program to is the start of (2) - that is, a state transition boundary. You may say "Well, why's that? if I set the instruction pointer the same as it was 1 second ago, and all memory contents too, what could go wrong?". The answer to that is that no program is a "black box". Damn near everything relies on I/O, be it Oracle accepting transactions, or a CD burner burning to CD.
You only have control over the program execution and what's in RAM. You have no control over I/O, and thus rewinding time in that respect is an impossibility, there is no way you can restore a state perfectly unless all the I/O devices (be they actual devices or remote computers) are restored to the same state. And that is just impossible.
* Yes, windows can tell you 'where' an exception occurred. I use 'where' in inverted commas because it's not actually where the problem was. For example, my program stupidly reads from a null pointer. So it tries to read the location "0x00000000". The program is killed. Where's the problem there? How do you fix it? Answer - you can't.
There are very few errors transparent enough to be recoverable, which is why most operating systems just don't even attempt to recover. They just kill the process and possibly restart it (Which is a sure-fire way of returning to a valid program state boundary - the initial one!).
Another example is a JIT compiler. These programs will deliberately cause illegal reads and writes in order to trap an exception condition, also known as "lazy compiling". It will leave an area of memory unmapped, and point pointers at it so that if those pointers are followed, a trap occurs. This means that the JIT compiler doesn't actually have to compute everything at once, rather it can wait until it's needed. In this case, how do you distinguish as to whether the trap is valid or not? How can you, the kernel, who doesn't know anything about the program or its characteristics, make a decision on what to do? If you 'rewind' the program, the program will continue in an endless loop!
* My last point is that I think you may have things confused:
Why do you need a memory dump to obtain this behaviour? Why would the process not just get restarted in a 'failsafe' mode?Two software apps have an incompatibility ( a system setting say ). If one (or both) bomb out because of this, they can use a predefined default from the dump in order to DYNAMICALLY adapt to the issue.
This quote in particular harks of a lack of understanding. A program 'bombs'; I assume you mean segfaults - what is not detected in time? what can one detect?Say a program bombs for some reason, and say it was not detected in time. Say the kernel made a boo-boo and tried to write over a memory sector because it though it was orphaned from it's process (automatic memory freeing concept). Then say they both did this at once. Windows would bluescreen right?
As to the latter half of your statement, you seem to not understand what virtual memory is about. In any case, a process itself can never free or allocate its own memory, it must system call into the kernel to ask the kernel to do it. Only the kernel has control over the hardware page tables. The allocation/free mechanism will also be mutex-protected, so only one thread on one processor can allocate/free at any one time. So firstly the case can never happen. Secondly, only managed OS's running managed languages (such as C# or java) have inbuilt garbage collection.
The above is what makes me think that you've come up with a solution to solve a nonexistant problem, and are still backing it to the hilt instead of doing the reading you should have done in the first place before posting such gems as:
It will be called .... I already built a replacement Command Parser... I will soon create a fake screenshot of what I think it should look like.
I REALLY need help... so anyone interested PLEASE email me
The last line is so pretentious it actually made me laugh out loud!Sphinx Gaming Inc., C.E.O., Founder
Hope this helps somewhat,
James
Re: ...
Rule of thumb: if people misunderstand you, you haven't explained good enough.SphinCorp wrote:You seem to have misunderstood me completely.
Apps can never trash the kernel if apps run in user space and the kernel in kernel space. No need for weird schemes eating up half my memory.This system is to protect the kernel at all costs, not the apps.
The kernel can't. If it could, it would be an automatic bug tracker. If such a tool existed, we'd all be very happy.The only reason the apps make a dump, is so that that kernel can find out exactly what went wrong,
How? An application knows nothing about its image in memory. It's just a dumb instruction list at the bottom, after all.and cut the app out of memory, and then put it in dormancy ( minimum information stored by the kernel in the memory protection half for eventual reanimation of the thread / process) it is the application that must handle the error, retrieve the info, then parse it.
"because" usually signals that what comes after it is the reason for the first. However, I can see no way to connect "kernel will never panic" with "kernel can retrieve runtime info".The kernel should help with that. That way, the kernel will never panic, because it can retrieve past runtime info, and basic runtime info from a basic system thread constantly running in dormancy in the background.
No, it does not make more sense. And your teacher is an idiot. Wouldn't be the first idiot teacher in the world, though.Does that make more sense? My teacher thought it was genius...
JAL
Minix 3 has a reincarnation server, which just reloads all the programs / modules from the start.
I think that is an example of what you were trying to do but shows that
JamesM is right in that it is nearly impossible to restore all the IO states, so it is impossible to reload the program as it was not just 1 second ago, be even the last instrution executed
I think that is an example of what you were trying to do but shows that
JamesM is right in that it is nearly impossible to restore all the IO states, so it is impossible to reload the program as it was not just 1 second ago, be even the last instrution executed
well... screw that plan then... I have to come up with something cool for it though. btw: I know I'm getting ahead of myself here, but I designed what it should look like, and I see it more in public, or handheld devices. Will post the image here soon.step one: make a bootloader and choose a filesystem. Fat32 maybe?
To get an idea of the basic steps, have a look here. I'd advise you to create an OS for x86 before going embedded, as there are more tutorials, guides and manuals available for x86.
yup,
http://www.osdev.org/wiki/Babystep1
then follow the tutorials.
or use grub for the bootloader and follow
http://www.osdev.org/wiki/Bare_bones
or
http://www.osdever.net/tutorials.php?cat=0&sort=1
which has tutorials sumwhere
and im sure theres many more but i was only doing a quick 2 second search
http://www.osdev.org/wiki/Babystep1
then follow the tutorials.
or use grub for the bootloader and follow
http://www.osdev.org/wiki/Bare_bones
or
http://www.osdever.net/tutorials.php?cat=0&sort=1
which has tutorials sumwhere
and im sure theres many more but i was only doing a quick 2 second search
Picture this if you will:
--> menu bar is on left side of screen it has a cool blue theme to it.
--> there are by default certain buttons, but you can change then. they are a slightly darker blue.
--> no menu appears until you click, rollovers darken buttons
--> Single user OS for desktop use
--> each drive assigned a name (example path: system:/config/desk_menu.conf)
--> all maintenance tasks automatic (routine defrag, temp files emptied, ect -- all in background)
--> built in apps for routine uses (ftp client, web browser, email, office suite; sort of like linux)
--> all is simple, accessible and done through GUI, for optimum noob-friendliness
Would this work / be efficient?
--> menu bar is on left side of screen it has a cool blue theme to it.
--> there are by default certain buttons, but you can change then. they are a slightly darker blue.
--> no menu appears until you click, rollovers darken buttons
--> Single user OS for desktop use
--> each drive assigned a name (example path: system:/config/desk_menu.conf)
--> all maintenance tasks automatic (routine defrag, temp files emptied, ect -- all in background)
--> built in apps for routine uses (ftp client, web browser, email, office suite; sort of like linux)
--> all is simple, accessible and done through GUI, for optimum noob-friendliness
Would this work / be efficient?
Is that a joke, this gives the impression that you want to roll a windows clone....Ok... So I need a bootloader. I wish to use the exe format and on fat32. any suggestions?
As for not getting a head of yourself, your starting by designing th GUI, do you know how long your going to have to be coding your OS for before you can even THINK of starting a GUI?
I seriously think you should stop having high level ideas of rolling windows clones with miraculous abilities to fix all errors...
You should start doing some actual coding before you start thinking about vista style GUIs, etc... and if you think its going to be as easy as this:
(By this i don't mean to be insulting)
http://www.belong2us.com/sphinxgaming/Products.html
Your sorely mistaken, nearly all of us could roll similar 'products' (their not products if their available for free download..., also I have a felling you have little idea how hard it is to run a company (though of course i might be mistaken)), in a few days if that.
Again I want to reiterate that by this I don't mean to discourage you from your product (and I know what it is to have huge ideas of making 'miracle' OSs, I had loads myself, though they had (mostly) evaporated before I even made my first post here.
Good luck for your project and don't hesitate to ask if you do have a problem, though please do ask them in an intelligent way... (and do as much searching as you can yourself first (though I often break this rule...))
Jules
P.S. again no insults meant but its pretty stupid to be making 'fake' images of your OS before you even start coding it...
P.P.S having said that you want a vista like GUI, I might be wrong, you might be making 'fake' pictures of a perfectly reasonable TUI, but somehow I have a doubt
edit: sorry I missed your newest post, so my P.P.S is no longer applicable
Have you perchance asked PhpBB if you could use their artwork for your website's navigation bar?http://www.belong2us.com/sphinxgaming/Products.html
EDIT:
http://www.belong2us.com/sphinxgaming/Services.html
Hahahaha, you offer web design services, but you manage to put that text in the same colour as the background so people can only view it if they highlight it.
Last edited by JamesM on Mon Jun 02, 2008 2:06 pm, edited 1 time in total.
Are you seriously thinking about all this stuff before righting any code, I've heard off having a clear plan, but...--> menu bar is on left side of screen it has a cool blue theme to it.
--> there are by default certain buttons, but you can change then. they are a slightly darker blue.
--> no menu appears until you click, rollovers darken buttons
--> Single user OS for desktop use
--> each drive assigned a name (example path: system:/config/desk_menu.conf)
--> all maintenance tasks automatic (routine defrag, temp files emptied, ect -- all in background)
--> built in apps for routine uses (ftp client, web browser, email, office suite; sort of like linux)
--> all is simple, accessible and done through GUI, for optimum noob-friendliness
Can I ask have you even written a single line of code for your OS yet?
Jules
edit: As James said have you asked PhpBB if you can use there art work (thank you for bringing that to my attention hadn't noticed, even though it is quite distinctive), also I wonder what language you intend to program your OS in as the only executable listed as a product on your website (which by the way failed to run: "The application ailed to initialize properly (0xc0000135)."), after analysis in hex edit wasn't compiled by anything C/C++ compiler I've seen before and I suspect it of being some form of BASIC (though I might be wrong...). I can also see that it was compiled under windows and the name of the account you are using is Richard, suggesting your first name is Richard.
edit: added error
second edit: sorry about the dissection, but I was bored...
Last edited by suthers on Mon Jun 02, 2008 2:59 pm, edited 3 times in total.