OSDev.org

XANA is an experimental os for R&D -- a test bed for possible "future os" concepts, to see how practical they are for implementation and use.

I'm borrowing most of my basic starting points from Project Xanadu.

Currently, the filesystem is an XU88-type database, pretty much, though with some extensions. It is serialized into enfiladal addresses (versioned, like the ENT), though the C level APIs (i.e., those used by ports of existing code -- the "std" libc functions) will see the filesystem as much like the RiscOS filesystem. In other words, root is a $ and the directories are separated by dots. The directory names themselves are the enfilade's tumblers. Programs exist as bytecode scattered across the filesystem with transpointing enfiladal arguments, and device drivers are programs (which act like files anyway).

The OS has two UIs -- the Zig and the Z2. The Z2 is the primary interface, based on Project Xanadu's "ZigZag" concept (except absorbing UI concepts from the PS2, NeXTSTeP, Enlightenment, and various other things). The Zig is more like a mind mapping system, which is used for displaying and navigating all the links of a document at once, as well as the connection between documents.

The OS internally is written in D, and has a built-in Lua interp as a command shell. The Zig and Z2 are built in as well (simply out of need for a trivial implementation), as are the enfiladal file system and all the basic (disk, keyboard, video) drivers.

Once again, XANA is not designed to be a usable primary OS -- it's an experiment, and any application of these concepts would be extremely far diverged from the original XANA code and design.

If you're interested in more info, check out the "Project XANA" thread(s) in the project announcement forum, or check out the source at :
http://projectxana.twilightparadox.com/xana.tgz
http://hakware.oopsilon.com/xana/xana.tgz

(The second URL is slow, so use it sparingly).

~ John

I thought I should mention an old IPC method I used for transferring large amounts of data.

The kernel allowed one process to send another process a 32-byte message. The sending program would allocate all the memory possible, creating a memory monopoly, then sending a message to the receiving program on how big the data transfer was.

The receiving program used the kernel's messaging system to tell the sending program it was ready to accept the message. The receiving program then changed it's scheduling order so it would run straight after the sending program.

Then the sending program freed the memory containing the data to transfer, and on the next context switch, the receiving program allocated the memory, and thus the data is in the receiving program's virtual memory! Then the sending program released it's monopoly on all the system's memory.

It was dodgy and slow, but it was reliable and worked! It's how my programs use to send their window bitmaps to the GUI manager. But as I said, it was slow, and I decided to scrap the idea and just give the GUI manager direct access to where the bitmaps are located.

I'm not a good OS designer, and will get flamed for this.

Normally memory managers would zero any memory they give to application so that they can't read each others memory.

But at least that's a creative method.

It's one of the best examples of what "hacking" truly refers to - using a method that's not supposed to work, but because of all facts combined does, which is in a way pretty quirky and odd to use.

I have an idea for an OS (I am working on finished design sheets). It will be modular as well as be set up to run as fast as possible, without data loss or similar things.
Also, it would do away with the standard Icon/taskbars and replace them with a sphere that has options that can be cycled through by either scrolling the mouse wheel or by moving the cursor over them. Left clicking would select the option and if applicable scroll out a menu in what ever direction the option is (e.g. if you click on the far left option and it has a menu, it would scroll out to the left).
Finally the window bars would be non-existent. If you move the mouse up to the top-right(or left) corner the minimize/maximize/close buttons would appear when you move over them.
Also what do you all think of replacing the traditional example.odt stuff with something different like example::OpenOfficeText or example::odt. It would allow periods to be more readily used in document names, while still retaining the ability to use the colon (notice it is 2 colons right next to each other that does it.).


And please note that this is (C)Copyrighted Information. No Idea stealing. If you like my ideas and wish to use them PM me asking. I will probably say yes under an agreement where i get credit for the idea.

You've only given some GUI ideas and exactly one idea about changing the characters used to denote file-system extensions. These do not an operating system make.

Oh, and (C) + a posting timestamp + your username != a valid copyright notice. Those ideas now rest happily in the public domain. Thank you very much.

You can't "Copyright" information... you can copyright text, imagery or other original works but not the pure information and definetly not the ideas which are covered by completely unrelated (despite peoples attempts to call it all IP) patent laws.

Secondly appart from your rather unpatentable (its not original) graphical ideas i think you need serious work on your design. You can't simply say...



...and assume it will happen. Ideas are original concepts that are a means to this end. This mean learning to you are the height of all current knowledge on computer science and os development so you can begin to form original ideas.

I think you get the idea.

I can see where the guy needs to learn, but did you have to start in with the We Must Bow Humbly Before the Gods bit? Now another one will think he can never accomplish anything original, thereby feeding into the pool of people who can't accomplish anything original.

I'll make you a deal... the day i feel a shred of confidence about my musical ability, i will instill confidence in the computing ability of newcomers to ths OSDev world. Until then, burn-a-hoy!

Mu. I, personally, find that originality of thought has little to do with ability. Hence, discouraging people from original thought based on their own lack of ability just depresses them. Instead, we should encourage ignorant people with original ideas to learn so that they can give the world their original ideas.

In my experience, ignorant people who come up with "original ideas" actually come up with good ideas that have been around for years, and they just weren't aware of them.

Unfortunately, I have seen lots of good ideas go to waste due to there not being an ignorant person making them live for anything functional. Ideas themselves can't work, you need an implementation.