OSDev.org

Hey, I'm new on OSDev.org (though I spent most of my time from age 12 to 15 coding failed os attempts . I later found that I'm better at doing backend designs than I am at coding the very low level stuff (asm, etc) that forms the core of osdev, though there has remained a soft spot in my heart for creating OSes.

Two weeks ago, I picked up a friend's partially completed simple os project (OCD, an experimental OS in D that barely booted and had only the simplest functionality, broken when he updated D because he had no memory manager) and I created an offshoot OS from his initial code which really IS experimental. I combined some of the concepts from Project Xanadu that I have been obsessing over for some time now with the very core functionalities of the OS, and I have to say, it's coming along nicely.

The current version (at the time of this writing) does not boot, however is has pretty extensive code written, which I am working on debugging. The newest build is perpetually at:
http://projectxana.twilightparadox.com/xana.tgz
and
http://hakware.oopsilon.com/xana/xana.tgz

Current features include:
- Memory manager
- Keyboard/console support
- Pmode
- Hard disk support
- Enfiladal file system (on RAM, hard disk, or hard disk partition)
- Enfiladal/link-based "Cell" bytecode (unfinished)
- Microkernel (may change this soon)

Future features may include:
- Graphics
- ZUI and Z2UI (two alternatives to the typical WIMP GUI paradigm)
- Mounting
- Networking
- Network mounting
- Multithreading
- Joystick support
- Maybe a custom computer arch to run it on (would be nice

I'm looking for some more developers, if anyone is interested. Note that this OS is highly experimental, and doesn't plan to really support any typical stuffs (ex., no ELF/COFF/.NET executables, and probably no mouse support . It's an attempt at creating an OS in the theme of a possible nExt generation, and isn't designed to necessarily be fast or practical at this point. If we get users, then hell, maybe. But it's primarily a B&D OS; if that's what you're into, then take a look at the code -- you'll probably get a kick out of it XD.

~John

The mockup of the ZUI is here.
An AVI (lavc codec) of the Z2UI mockup (prelim -- just something I whipped up in a few minutes with GIMP) is here.

These UIs are rather complex, despite their simple appearance, and draw heavily upon the xanalogical nature of this system.

The ZUI (or "Zig") is similar to a basic mind mapping program, though it is primarily operated with either the keyboard or a joystick. It provides a zoomed-out interface for manipulating and browsing transpointers (links) and enfilade sets, and provides searching features. This is the auxiliary or alternate interface to XANA, and will be added at some later time (it is rather difficult to implement, especially with the low-res video that I'm currently restricted to if I don't write a driver for every SVGA chipset).

The Z2 (actually, Z^2) is a new take on Project Xanadu's classic (original) "ZigZag" paradigm, borrowing UI ideas also from the PS3 UI. It is operated mostly with a joystick or with keyboard arrow keys. It may look like a simple menu, but in fact it hides a bit of complexity: when one scrolls along the x, the y becomes the submenu for the x selection, however -- and this is the tricky part -- when one scrolls along this y submenu, the x becomes the submenu for the y selection. Now, mind you, this isn't a simple matrix. Actually it is a doubly linked binary tree. Therefore, things do not need to be linked linearly. Also, there will be a third "dimension" for 3spans, which can be swapped with either the x or the y. 3spans are like mime types, but are actually one-way transpointers to the actual code used to interpret the data.

The Z2 demo was initially going to include exploring the filesystem, exploring a network, and writing a simple program, however time was cut short. Animating frame-by-frame in GIMP is time consuming, and I was in a crowded urban cafe with a rapidly losing battery and a full bladder. Anyway, a full demo will be created soon, and until then, I'll treat you to a description of the programming language (EPL, for Enfilade Processing Language).

EPL is a graphical programming language. It is odd -- think assembly language instructions in the form of graphical mnemonics (glyphs), with a syntax similar to what lisp or scheme would be if their parentheses were replaced with (graphically visible, navigable) hyperlinks. Data structures are the same as normal documents, but have a structure similar to data structures in, say, C. Arrays are document/enfilade spans, and structs are documents with links and/or transclusions intermixed with the data. Iteration is done via a process called "chugging" -- essentially the same as stepping over a linked list. Chugging can be done in parallel, stepping over two or more nodes at once by forking. Programs are actually interpreted via chugging, so this can be a concurrent programming environment. EPL is not just fast because of its parallel nature -- its organization is similar to the tree structure of already-parsed code in an interpreter or compiler. Needless to say, it's not as fast as native code, but at least it will work well between platforms and not require much parsing or any compilation. One programs in the bytecode directly, using the Zig and Z2 interfaces, graphically. Also, the organization of a program is such that one starts a program or function with its initial input and its return value, and then propogates backward from there. EPL programs can be strung or piped together using 3spans like parentheses are used in lisp.

Anyway, some feedback would be nice. And no, I probably won't be using the old dia icons in the actual UI at release time

I hadn't seen those concepts like that before, so I guess it will take me some time to properly figure it out properly.

What do you want feedback about?

By the way, does the content on your site everything needed to know to follow this project?

And also, why not support mouse, at least PS/2? It's not that hard, almost as difficult as keyboard...

Ah. The site's under construction, but will have all the necessary info pretty soon. I suppose I'm looking for feedback on the concepts, but since they're unclear, I'll have to wait until I have better docs on them.

Also, I probably will support a mouse, but it's just not necessary. It could be used for the Zig (though not spectacularly well), but it almost definitely would have no purpose in the Z2. It would, however, be useful in browsing documents and such.

Xana boots, the text display works, and the garbage collector/memory manager works. foreach() is having problems (creates automatic infinite loop :-/), however the stuff boots and the IDT works (that was the big hangup before). Once we get foreach() to work properly (probably requires hacking a bit at the array typeinfo or some such) we'll be able to deal with enfilades and such properly, and probably try out ENFS ramdisks.

The hard disk driver does NOT work (or rather, it does, but not properly -- it assumes 1 byte per sector ). We'll be fixing that before bringing the estage back into full play.

Anyway, if you want to see interesting code, read our docs, and watch the OS boot up and halt, check out the source.

Tarball, as always, is at http://projectxana.twilightparadox.com/xana.tgz and http://hakware.twilightparadox.com/xana/xana.tgz .

~John

Got IDT working and such. Keyboard interrupt kills it (still working on that).

The project site is up: http://code.google.com/p/projectxana/
Check there for the todo list (where we are currently, and where we're going) and the setup procedures, etc.

Also, we have a new logo:
[/img]

Keyboard works (including not crashing, proper characters per scancode, etc). Shift and control are not tested (probably don't work), nor has backspace. However, this is enough to start working on the Z2 text UI, and eventually the Z2 graphical UI.

Also, we have the code up on SVN (see the google code project site), and we have some useful wiki articles on design issues (such as enfilades and transpointers/transclusions) on the same site.

If anyone wants more info, contact me, either through this board or by email, or on irc (freenode #xana ).

The executable format has been documented:

http://code.google.com/p/projectxana/wiki/EPL

I'd like feedback if at all possible.

http://code.google.com/p/projectxana/wiki/Trans

How about you give a example of where this is useful? And convert it from a pure concept into some actual practical explanation...

I mean I could just sit and make up a bunch of cool sounding words that actually describe a process which could be a simple as a link list. So I think a actual practical description instead of a conceptual one would be highly useful.

I mean it feels like you are about to tell me you have invented a perpetual motion machine and want me to invest money...then disappear. That actually raises a red flag in my mind unless the intentions are not what would be considered normal so maybe you could enlighten me?

I have yet to actually find any real code on this project. And all the links in the table of contents on the main site are all broken? Give us substance :]

Well, a good example is saving space. Transclusions work like copies of data, but don't take up as much space as a copy. The bidirectional nature of transpointers means that you can navigate in reverse (like finding out who linked to something in a web page, something that google is still working on perfecting . Transpointers and transclusions can be used to model data structures, as they are in EPL. Enfiladal addresses have a much bigger number of possible permutations than anything else currently available, yet they are scaled simply, with little computational overhead (no explicit parsing for counting, like utf8).

The real code is in the source tarballs. The "site" is not up yet, so I haven't written the link content, but the google code project has all of the source.

http://code.google.com/p/projectxana
http://projectxana.twilightparadox.com/xana.tgz

Enfiladal addresses have a much bigger number of possible permutations than anything else currently available, yet they are scaled simply, with little computational overhead (no explicit parsing for counting, like utf8).

To increase permutations you increase the bits. So you are increasing the bits on something that will eventually have arithmetic operations performed on it with out increasing the computational overhead. I really would like to know how I could add two sixty-four bit numbers together on a thirty-two bit machine with out increasing overhead. If you scale something you are not increasing or decreasing the bit count but instead just using a constant factor to multiply against. So what in the world do you mean?

The bidirectional nature of transpointers means that you can navigate in reverse (like finding out who linked to something in a web page, something that google is still working on perfecting

Oh. You mean the classic: That has been around for a long time. Its just a linked list really. I mean you are writing a operator system. So what I am wondering is where this stuff fits in? Talking about Google and other such things is way up there in the application programming field. We are expecting you to be working and talking about system programming. So how do these transpointers do something that has not been already done for almost two decades at the least?

By scaling I mean that one can start with a length of say, 6 bytes for an address, and scale up to something on the scale of 2^128 bytes if necessary, without having to process each byte individually to see if it includes an "extend" bit. I didn't mean doing arithmetic on the addresses, which is, by the way, also rather efficient.

And, to tell the truth, transpointers and transclusions have been around since the 1960s -- they just have never been included in the basic structure of an OS. The enfilades and transpointers/transclusions are primarily the domain of the filesystem in XANA, but since the only supported executable format is a bytecode that is built into the filesystem, one can easily see why these additions are a big deal. Also, it is not quite as simple as a linked list (close, but not quite). For one, I'm not using pointers -- I'm using enfilades. In fact, I'm using enfilade spans, which is akin to having a pointer to individual slices of more strings than there are grains of sand on earth, each with up to 2^64 versions (being able to access individual versions), each of a size possibly bigger than 4GB, with the slices being capable of spanning between 1 byte and the entirety of all of the strings.

Oh by the way, I AM borrowing this from application development (to be more precise, it is an extension of ideas presented by Project Xanadu in their original hypertext project, which predates the world wide web, and is, in my opinion (and the opinion of most of its creators), superior to today's world wide web). That is the reason I'm using a higher level language (D rather than C), since C would make implementation of even the Enfilade by itself quite needlessly complex.

By scaling I mean that one can start with a length of say, 6 bytes for an address, and scale up to something on the scale of 2^128 bytes if necessary, without having to process each byte individually to see if it includes an "extend" bit.

So what are you going to do? Something like the structure (below).

I didn't mean doing arithmetic on the addresses, which is, by the way, also rather efficient.

You will have to elaborate more on this.

And, to tell the truth, transpointers and transclusions have been around since the 1960s -- they just have never been included in the basic structure of an OS.

Ok. Back to my previous post which gives a example of a data structure that represents exactly what you specify. I would like you to tell me that this has never been included into the basic structure of an OS, and _exactly_ where it would be useful to include it. If you can not answer this directly and correctly then just tell everyone including me. Here is my example:

The enfilades and transpointers/transclusions are primarily the domain of the filesystem in XANA,

And.....

but since the only supported executable format is a bytecode that is built into the filesystem, one can easily see why these additions are a big deal.

Oh. Here is the part to the "And" (above). Ok. So I should easily see the connection between the: bytecode, filesystem, and transpointers/transclusions. Umm. Well. I see a lot of things. Actually too many. Whats the point?

In fact, I'm using enfilade spans, which is akin to having a pointer to individual slices of more strings than there are grains of sand on earth, each with up to 2^64 versions (being able to access individual versions), each of a size possibly bigger than 4GB, with the slices being capable of spanning between 1 byte and the entirety of all of the strings.

So this one 'magical' pointer can point to multiple locations using just one value, right? Or. Maybe you flew out into the magical land of concept thinking again instead of actual concrete practicle examples here. So I will, out of regard to you actually not being crazy, try to find a logical explanation:

You mean a pointer as something unlike a C pointer which actually has the ability to point to multiple places. Ok.

So each of these pointers to the individual slices of strings have up to a maximum of 2^64 versions. Ok. You swam out into a ocean and dived under the water only to find a lonely rock and some talking plankton.. the plankton said let me try, out of regard to you actually not being crazy, try to find a logical explanation:

So. Each of these pointers point to a version of some data which has a cap of 2^64 versions. And able to access individual versions. So you are going to use this enfilades address in a enfilade span as a pointer would be used in C to point to these data chunks..

Oh by the way, I AM borrowing this from application development (to be more precise, it is an extension of ideas presented by Project Xanadu in their original hypertext project, which predates the world wide web, and is, in my opinion (and the opinion of most of its creators), superior to today's world wide web). That is the reason I'm using a higher level language (D rather than C), since C would make implementation of even the Enfilade by itself quite needlessly complex.

I searched Google before I ever posted in this forum just to see what sort of crazy crap you were up to. Honestly. The site I found looked like total bull ****. Actually it almost seemed like the primary goal was just to take normal technical terms and turn them upside down just to confuse people into thinking it is something really new and exciting. I mean...

Here is the original link I looked through:
http://xanadu.com/index.html

This in unfair, but you are unfair in the wording so I think it would be acceptable to bait people to read this first.
http://en.wikipedia.org/wiki/Vaporware
Then read this afterwards.
http://en.wikipedia.org/wiki/Project_Xanadu

Ok. You are most likely in the wrong forum or sub forum to be more exact. This is in my opinion why nothing makes sense. Everything you are doing is conceptual and not formatted or developed into a practical form. So blabber about it in the development forum where people generally or used to post ideas. People in this forum most likely expect, like me, practical things. Stuff that has been implemented and sports some functionality. I do not want to talk about computer philosophy, but instead actually making something work.

Here is something funny:
http://groups.google.com/group/rec.humo ... b41c16772c


And just as a side note: I actually take offense when someone throws bull at me just because they assume I will not actually read what they wrote. I will just pick and pry until I find out if it makes sense or not. So good luck..