between tasks. And if you save them in a shared area, you`re mixing shared
data with process data. If an process crashes, it can crash other process
as well, and it`s very very bad.
Not mixing nothing... sharing. is the ability to distribute resources.
?!?!?!?!?!??!?!?!
Are you sure you read my message and replyed the correct text????
Distribute resources != program data.
Distribute resources != sharing data.
Will you `distribute` the stack of current foreground process with the stalled
processes??? I don` think so.
If you are trying to say that you save current process data on a shared area,
it`s not `distributing resources` or `sharing data`. It`s a bad design decision.
Should I explain why?
So MNBIOS application can output data to screen only when they`re
foreground
tasks? Hum... So MNBIOS applications must conform to some sort of
`model-view-
presentation` scheme, that makes things harder for programmers... Mainly
when
you`re talking about ASM programming.
Is structure programming, MNBIOS is a structure OS.
You didn`t reply my question and now you introduced a new type of operating
system... :) `structured OS` doesn`t mean nothing. Even a Pascal program is
structured. If you`re saying that `MNBIOS applications must conform to a
structure`, it`s also obvious, because all applications must do this (for all
OS,
or even for a machine without an OS).
I`m sorry, but I really didn`t understand what you tried to explain.
Please read the manual, on the first chatper (or second), you will learn how
to structure a program under MNBIOS...
Ok, ok.
If I read this manual, I hope you guys are prepared for a lot of english
comments. :)))
And if background applications can never output data to screen
YES, for the moment YES... about SCREEN. I need check if is possible to
change the active window on the BackGround proccess and restore it before
exit, that for allow to output chrs to the windows....
Virtual screens? Hum... This will need a lot of memory... And video functions
will be slowed...
So in kernel mode the system cannot be interrupted?
No to run background process, yes for interrupt BIOS tasks.
But that`s bad. You may get reentrant BIOS calls and even corrupt
current processing of a BIOS call if it`s interrupted by a user request...
You`re confusing basic concepts of OS. `Kernel mode` and `user mode`
doesn`t
means security, but mainly two different operating modes. If you don`t
have them,
you don`t have an OS, specially if talking about a multitask OS.
That is not true...you know that as all know that is the definition of an
OS.
This sentence is a bit confuse. I didn`t understand it, and it doesn`t seems to
refute what I wrote. I`m not talking about the definition of an OS. I`m talking
about operating modes of an OS.
Maybe you not understand what i mean because you only are thinking in the
UZIX way.
No. I disagree because you confused `security` with `operating mode`.
Regards,
Adriano
