Re: Writing an Operating System in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 12 Jan 2010 09:37:11 -0800 (PST), Shark8 wrote:

> On Jan 12, 2:41�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
>>> Anyway, I was wondering if anybody here would be interested in such a
>>> project.
>>
>> If that will be a really new OS (not a UNIX clone), OO, portable,
>> distributed etc, for interesting platforms like this:
>>
>> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi...
>>
>> why not?
>>
> You know that was a frustrating / discouraging thing to hear almost
> everybody I talked to about wanting to write an OS say something along
> the lines of "Why don't you just download the sourcecode for
> Linux?"... I'm sorry folks, but I don't want to be the OS equivalent
> of a 'script-kiddie'.
> 
> One thing I find very annoying about the Unix/Linux mentality is the
> "everything is a file" philosophy... coupled with the C/C++-ism of
> simply assuming that a file read/write went well and you're asking for
> trouble. {Yes, I know that you CAN check to see if writing is
> successful or not in C/C++, but it goes against most C/C++
> programmer's sense of terseness/'beauty'... the same one that makes no
> check on array-bounds.} </Rant>

Wow, can you read minds? (:-)) I wrote about something like that many many
years ago. Yes, "everything is a file", "fore every possible job is a
utility", "every action is a process" is a pest of UNIX.

> Now the idea that everything [system-wise] is an object is much more
> appealing to me.

World-wise (a modern OS must be distributed)

> Objects are a very natural way to [generically] model
> hardware: a display has a running-resolution, available resolutions,
> OpenGL/DirectX compatibility, etc. It could even be engineered in such
> a way that every device-object 'knows' how to write code for its
> device and that code is JIT-compiled for the specific system.
> (Example: A PCI-card can be inserted unto a system-board with a SPARC
> processor, or one with an AMD processor, the two different endian-ness
> but the card is the same for both, so it stands to reason that a
> device-object [device-driver] could be written in a high-level manner
> abstracting out the low-level... probably by having the aforementioned
> JIT which is linked to the CPU's device-object tell that object to
> output the codes for the PCI-card-object.)
> 
> Having such a system means that we could support disparate
> architectures by having base-CPU objects & the high-level driver-
> objects on a bootable CD with a VM such as DOTNET or JVM and
> 'installing the OS' would be compiling it for that HW-setup. The
> downside to how I'm describing it is that it sounds a little too Unix-
> y.
> 
> Using the Java-style interfaces we could have a file-system interface
> which would allow the OS to use any FS which was implemented in an
> object using said interface.

There should be no file system at all. If you have objects, I mean if you
do have them consistently all the way, then you do not need files. Make
objects persistent in the corresponding device, that gives you all
functionality of any file. No I/O is ever needed. Map the object into the
memory, call its operations, what else any program would have to do?

The problem is that we followed the wrong path for too long. All these
standards (XML to name one) are based on these flawed untyped file - "don't
care about the contents" model. There could be no return, maybe.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de