OSDev.org

Hello to many people here at OsDev,

I am still learning how to write on OS but throughout the years I have seen that many Os software experiments were tried yet there is still more ideas to be added. My dream is to write an OS called the New Era OS.  So here is a little description of what I want to write.  I basically want you to read over it.  Add anything that could be added.  The basic ideas behind the system:

All user programs are interpreted.
Object / File transparency.
        Programs are all functions
        Event based approach
        Transparent Networking
Each Frame is redrawn

All user programs are interpreted.  

So all programs that are not the Kernel or the Drivers would be byte code interpreted (Simmer to java). This takes out the program crashing and taking out the entire machine.  Then all user programs can run on any hardware.  This means that New Era can easily move to a new architecture and have all user programs running. There has been lost against byte code interpreted code but I see that those two advantages out wage the speed you get with machine code.  Don’t get me wrong.  Os would be written mostly in assembly in order to speed up the user programs where ever possible.  Maybe C or I was thinking about writing my own compiler to do the not so critical sections. But hey commuters are faster every day so we might do it all in C.

Object / File transparency

All objects would be files.  Member functions and internal data could be easily added or removed at run time.  So the class can change  it shape during execution of the program.  Then all large data structures like arrays and trees would be stored in its own files.  So say if a program stored data in an array.  The array is actually a file so it does not need to save it.  When the app quits and then user runs it again the array would not change its values.  So really programs would never exit like in other OSes.  Don’t get me wrong the File system exists but it is transparent to the user.


Programs are all functions

Because program is a file and file is an object of an operating system (Or of the directory).  The Program becomes just like an Os function so any other  program-function-object-of-the-OS can call it.  So to call paints rotate function you word do something like:

Dir = Find(“paint.exe”);
Dir.Paint.exe.roatate( 90 );

Every time you get a new program you can use any function with in.  Ha! This can speed up program development.

Event based approach

Windows is message based it send you messages when some thing happens. Most of the time program ignores it, so way bother sending it in the first place?  Instead the user program would check for what it wants.  Like has this button been pressed? Or is this key pressed? Did the window minimize yet?

Rights of Program-Object-File

Security is the main part of a modern OS.  But It becomes such a hassle when it gets in the way. So user never asks the Program to open the file but user asks the Document to run the Program associated with it.  If the document has the rights to run the program (Bitmaps could only run Drawing software).  The program starts up.  Gets the pointer to the Object-File and start working with it.  If you want to insert a bitmap into a text document you would either drag it onto (and it would give a pointer and say hey I am hare to be insured) or text editing program asks the  OS to insure a picture (Then same process would happen)  

Transparent Networking

When you log into an “environment” it does not have to be just on one computer.  The files could be stored on any computer completely invisible to the user over a network.  Even processes that are non user dependent could be run on any machine in the network.  So the network has only one file system.  User might have his own for security reasons.  If some of you remember this would be like the Ameba OS in a way.

Graphics

Modern OS will relay heavily on high quality 2d and 3d graphics.  So just like in almost any game the screen will be redrawn every frame.  The objects that are to be drown needed to be registered to the main graphics controller first.  So when time comes to redraw the frame one just goes down the list and draws all objects 2d or 3d objects.  2d Object would be treated like flat 3d objects.  I was thinking of just getting all trusted OpenGL incorporated.  And writing a more user friendly 2d add onto the OpenGL.    

Day in life of a the New Era OS

Ok, much of the stuff up there might not make since so here I demonstrate it.  Lets say we need to edit some text.  We click on a little text editing program.  It starts an untitled document.  And the function bar.  Now its job is done.  The document is its own object and so is the function bar.  As we type into the document we can run another program in the function bar say “B” for bold which starts up and checks which characters are selected and converts them to bold.  So in reality every button is its own program (which can be called from any where remember?).  You even have no need to save the document because there is no such thing as a file.  If you turn off the computer right now the document would be saved to the hard drive (I mean proper shutdown).  If you wanted to replace the bold function you would need to ask the User Shell (Which has right to everything) to give the bold function the right to be modified and then have the bold be replaced with your program.



I wrote this order for you to evaluate idea about my Os.  So please fight with me for all the points in this here, ask me to clarify, or if this software experiment sounds like something you would like to do I am recruiting a team so email me at [email protected].

Thank you for your time.
            

"So all programs that are not the Kernel or the Drivers would be byte code interpreted (Simmer to java). This takes out the program crashing and taking out the entire machine."

Actually, that's not a problem for any operating system using a protected mode of operation properly.  Moreover, using byte code does not in and of itself do anything to prevent this.  You can implement a safe virtual machine, but that's no easier than implementing a safe protected mode environment.  This is a good idea, but it's not in any way an advantage of interpretted code.

So the only real advantage of going the byte-code approach is "binary" portability.  That's all you need to justify this -- that's a tremendous advantage for an OS that also aims for network transparency.  I would expect, however, that any real-world implementation of the OS would actually compile the byte code (possibly using JIT compilation and caching the resulting binary code) rather than interpret it in the classic sense of interpretted languages.

I like the idea of the file system being "invisible".  Label an object as persistent and let the OS worry about the details of how that persistency is implemented.  Given this, an even a persistent object, even a "file", may not in fact be a file, but an object in some database somewhere.

As far as "programs" go, it rather sounds like what you really want is just objects, exporting an interface to be used by other programs to get things done.  The Find("paint.exe") example somewhat betrays this paradigm (as well as breaking notion of file system invisibility), but this could be refined into something like an object factory.

I think your ideas about rights/permissions need work.  Keep this first and foremost in mind: in a secure OS, the first and foremost thing that needs authorization/permissions is the user.  Whatever other measures kick in need to flow from that.  Not that restrictions based on programs or documents are a bad idea, just they're secondary and built upon the other stuff.  Problem here though: I think you're reintroducing things you don't want here: "So user never asks the Program to open the file but user asks the Document to run the Program associated with it".  You're undercutting your own model regarding transparency.  If programs are just a type of object, and documents and just a type of object, designing a system where documents have rights to programs and not the other way around (or vice versa) makes little sense.  Generalize it: objects have permissions to use other objects.  Make the user an object, and the whole system comes together.  The user has permissions to access object X (a document, in this case), which has permissions to access object Y (some "program").  Now, objects can act as intermediaries.  Maybe the user object doesn't have permission to invoke object Y directly, but it can ask some other object that does have permission to do so, and that object can either do it or reject the request for security reasons.

Going with this, a lot of the other problems disappear.  You talk about a network file system, but then a user's own file system for security reasons.  With the security built in on the object level rather than the underlying storage level (which may or may not involve "files" in the classic sense), this becomes unnecessary.

Hope this helps -- it looks interesting in any case.  Good luck with it.

“I would expect, however, that any real-world implementation of the OS would actually compile the byte code (possibly using JIT compilation and caching the resulting binary code) rather than interpret it in the classic sense of interpretted languages.”

If like in C++ I would use pointers to reference to objects and all objects are in virtual address space.  Now days every one runs with minimum of 30gb hard drives.  This mans that my address space must be at least 30gb?  Now think of the networks? I need higher bits per address space.  With 64 bit addressing I could address have 18,446,744,073,709,551,616 bytes of memory.  Enough for a single computer yet we have to deal with net works later. This is way I think compiling my 64 bit interpreted code into 32 bit machine code would be kind of tricky. (Unless Intel makes a cheap 64 bit processor)

I was also experimenting (with my ideas) of self modifying code.  Like in assembly I wrote some queer programs with variables stored in code itself

D: mov ax,1234 ; 1234 – some variable

Then to change I would :

Mov [D+1], 4

Witch would change it to 4.  I was thinking of experimenting with things like that using interpreted code (which would be easer because of the smaller command set) .  Command like find all references to address 123 and change it to 456.  Did somebody do some thing like that?  Or is that just too queer?

“As far as "programs" go, it rather sounds like what you really want is just objects, exporting an interface to be used by other programs to get things done.  The Find("paint.exe") example somewhat betrays this paradigm (as well as breaking notion of file system invisibility), but this could be refined into something like an object factory.”

I am probably not made too much since with the paint thing.  What I want is file system transparency.  So that complex objects could be composed of simpler objects that are not only visible to the program that wrote it but to any thing that would try to read it.  So completely different form Unix and Windows where files are just binary strings.  Instead files or objects would be more like C++ classes that would able to display, and run them selves.

“Generalize it: objects have permissions to use other objects.  Make the user an object, and the whole system comes together.  The user has permissions to access object X (a document, in this case), which has permissions to access object Y (some "program").  Now, objects can act as intermediaries.  Maybe the user object doesn't have permission to invoke object Y directly, but it can ask some other object that does have permission to do so, and that object can either do it or reject the request for security reasons.”

Yes you are right. During security I of have wondered off my file system transparency and object generalization.  That helps a lot.

Thanks

Hmm, allright I hope I followed this correctly. The object things sound very good. It should deal well with security isues. And about that address space: Mabye make some sort of ordening. For example in a tree form: Documents->Text->All text objects and Documents->Drawings->All drawings..... And Devices->Input->Keyboard? But then you get a file system like the linux one (/dev/hda1 for example). Or some way of regestrating objects with properties and connect them to a name?

Or use longer names, for example an 8 bit system: 256 entrys. 2*8 bits=16 bits=65536 entrys.... And so on, but to make it workable for a user shouldn't you stay with chars? Humans have a better time dealing with names. Thats the reason for the DNS instead of IP's.

Or am I thinking in a diffrent direction??

You would not need a 30gb large address space as I doubt you would want to access your hard disk completely at once *most* times. You'll only have some portitions mapped at best into your virtual machine at best, too.

I guess self modifying code would only give you a marginal improve at best. Either you have a JIT - or you'll be really slow even on today machines. (I mean if I buy my Pentium IV or whatever with 3GHz+ I expect it to do things that a 3GHz+ machine should be able to do and not waste everything by interpretation). However compiling a safe language at that point should help avoiding the problems that you fear - at the same level as interpretation (If your compiler would have a leak there I guess an interpreter that you wrote is likely to have a similiar problem).


However, I dislike the file abstraction, at least from what I saw on Linux with device files. I think it is like mixing up two different things that don't belong together, on a level of lot of details - an object with a filesize, but perhaps I may read more out of it?
However, a naming system for objects would be in some way doing a similiar job to a file system.
And don't forget that sometimes, others should not be able to see behind the interface. That is why public/protected/private in C++ and other languages was invented.

Ok, I hope to answer get to the point.  The objects would look some thing like (All is up to debate right here).  The language for what I want to show does not exist so kind of C++ is used.

A text file object

object “Some Text File“; // object’s name
{

dynamic char text[]; // the array with name “text”
void Show(); // shows text icon when minimized when not text

}


Now a program object

object “Text Editor“; // object’s name

{

object TextFile = NULL; // name current file

void Show; // displays buttons user can click

void Init();
void Copy(); //lost of functions…
void Cut();
void Paste();
void KeyPress();
void Find();
...

}


Now Every thing is running User wants to modify “Some Text File” with “Text Editor”.  Text Editor can’t access my file object because it has nothing pointing to it.  So the shell (Witch has access to every thing user has access to) must set “Text Editor”.TextFile = “Some Text File“.  Now the Functions Copy, Cur, Paste, KeyPress, Find will modify the “CurrentFile.”  Now the “Text Editor”.Init function is called by OS. Now this function inserts a new function by

New “Some Text File“::KeyPress() = “Text Editor”::KeyPress();

Witch makes the “Some Text File“ look like

Object “Some Text File“; // object’s name
{

dynamic char text[]; // the array with name “text”
void Show(); // shows text icon when minimized when not text
void KeyPress();

}
Now the “Some Text File” will have KeyPress function and all will work.  On “Some Text File”.KeyPress( key ) will call the “Text Editor”.KeyPress ( key ) and all will work.

I hope this is clear.

Actually, this sounds remarkably like my OS. I'll write a more complete description someday, but here's basicially how it works:

Like in yours, all user-mode applications are interpreted from a bytecode for the reasons other people have mentioned, and because it's something I've always wanted to write. I'm currently working on the virtual machine (hosted in Linux, not in my OS -- it's not mature enough yet). I currently have the interpreter working with a  limited instruction set. I'm working on an assembler now.

Also like yours, applications have on a highly modular nature. Every component (I've started calling them "atoms", because by nature they are the smallest indivisible chunk of code) of the system exports an interface of some sort to the outside world, which other components can call into. Components publish an import list that lists what components of the system they require. An import is then called by executing the call_import instruction and specifying the offset in the import table. In the future, I'll add a more dynamic version where things can be imported at run-time. The HLL wrapping this all up will actually resemble Objective-C quite a bit, simply by nature.

You mentioned network transparency. That's simple. Imports are specified with a URI syntax with the format "lire://[hostname]/[atom]/[segment]/[export]". Any field, except [export], can simply be "." to specify the local host/atom/segment.

One thing I'm mulling over right now is how interatom calls will be accomplished. There are two possibilities:
    1) Each atom runs in a seperate process, and they are passed some sort of context.
    2) Calls into another atom happen in the same address space. The corresponding code is simply run like any other function within the same atom.

Option 1 is preferable, because it maintains the modular nature of the system. However, it causes concurrency issues, and is slower due to the context switch. Option 2 may cause some security issues (by breaking the bubble, so to speak, and bringing external code into the process), depending on how it's implemented. I haven't thought through this well to figure out the ramifications of those issues.

Gnome.