OSDev.org

Hmm ... watch out that COM with C can become really hard to deal with (and generate quite ugly code with all those CLSID.)

I wish there was a nice language to express interface-based code and which would translate to plain C.




I'm also addressing this issue and the best way i found to have clean code is to generate those structs and __inline__ message formatting from a small interface description language called "slang".



and here's what "tidy.pl" will generate from it (segments only)

Gee. Seems i've been off-topic from the start and completely miss the point of this thread. Great Idea (tm), Daryl

I envision "Clicker" as a system from which the end-user can quickly control and describe the environment to fit its own needs. See future ideas and implemented features to know more about it.

File System
It should be more like a automated documents database than a real filesystem. Every user/application would have a specific view on it (so that your mailer isn't able to write to your MP3s, for instance), strongly typed, object-oriented (files and directories have classes which knows how to handle them, MsWord9x implements Document, Text, Printable, etc).
The FileSystem should also be able to track the dependencies across the documents (so that if you collate a bunch of Web extracts into a web.doc file, looking at web.doc:links will give you the list of URLs and external files where the datas come from

User Interface
It should be designed around a so-called Graphical User Interface Description Language (GuIDL) that will allow the end-user to quickly build up new applications by grouping existing tools

Rather than giving a detailed list of instruction to the Graphical Server, Clicker will send it a GuIDL script that defines appearance and behaviour (response to events) to be compiled and interpreted by the server.

A "ToolBox" should also be available so that the user can turn its cursor into "?" (get hint about a feature), "brush" (configure theme and appearance) or "wrench(cl? ? molette ?)" (configure shortcuts, add filters, edit tools dependencies, etc.)

inter-application communication
Every application should come with a list of plugs that other application can see. So for instance you can getApp("apps.audioplayer").getPlug("onair").read() to know what background music is actually playing, getPlug("queue").write() to enqueue some music request, etc.

Those plugs come along with an abstract description of what kind of data formatting they expect, so that once you get a reference to a given application (using its windowID, virtual name...), you can do app.getPlug("commands").describe() to know what kind of commands you could send to the application, display it as a form for the user so that it could tell "yes, it's <goToUrl> message i wanna use from my bookmark external tool"

Wow, Pype, I am highly impressed.

Great idea making everything an object, certainly very logical.

I do like the idea of plugs, sort of takes object orientism to a new level.

Its quite amazing the breadth of design on here, a lot certainly quite different from the accepted norm.

My goals are Simplicity, tinkerability in that order. I am not aiming for the next generation desktop, but I am aiming for an OS that is easy to approach, one that doesn't feel like its hiding anything. And one that is easy to extend and change. KISS is my motto!

Daryl.

just popping up this thread in case of whether someone has something to add and didn't find it deep the archive

Hakware is the kernel of the operating system (Jenova/Hakware OS) that i am working on. Since i'm the kernel man, that's what i'll be working on.
The kernel is designed to be simple, robust, and powerful, perhaps with speed where we can fit it in. The goal of the Hakware kernel is to be the host and controller of a programmer's environment. It supports both Linux and Dos interrupts and executable formats, as well as both systems' file systems through a vfs. It is written as simply and elegantly as possible, to make it easy for a beginner to understand and nice for an expert to look at. Most of it is written in nasm-syntax asm, with the exception of the vfs.
The vfs is written in C++, and mounts the filesystems in a modified Linux standard, with devices mounted as files and drives mounted as directories, except with full file names and intuitive directories. Also, all the non-user files are stored in /system or /programs, depending on their function.

-- edit
informations about the logical file structure is available here
-- /edit

The gui, in direct opposition to the kernel, is designed to be accessible to the standard user as easily as possible. It is a standard gui, but with focus on key combinations, and also an interesting new feature: the mui interpreter.
The mui interpreter is a small text box at the bottom of the screen which appears on a key combination, and interprets english sentinces as commands to control the gui, run programs, analyze situations, and build up customized user settings.
The interpreter is based on a system used at mit in the 1960's called Project MAC. That system interpreted english sentinces and translated them into mathematical equations to be solved, and asked questions if data was missing. The interpreter in Jenova OS does this on a higher level, translating sentinces first into symbolic knowledge representations (a la expert systems and Alan Turing), and then decides whether it is a command or data. It then produces a response, in the form of either a set of programs running or some data being recorded, or even an english-language response (be it slightly uneducated for social and "human" problems, but good for math and technical problems). This interpreter also acts as an automated help system. Instead of needing to read man pages (included in this Linux-based system), one can type the question into the interpreter and it will answer.
The kernel's internal structure is similar to Linux. It consists mostly of compiled-in binary modules (for efficiency), and eventually will include loadable-module support. essentially, every module in compiled before-hand and included as flat binary into the code that calls it, eliminating many of the jmps and calls that slow operating systems down and make them sometimes unreliable. Code for irqs would be dynamically generated, and when irqs are assigned at bootup, the system of handlers would be configured to work with the modules already compiled in.

Very interesting thread! Glad you bumped it back up Pype, I'd never have seen it. Threads like this are great for sharing pure concepts, and its great to see other people coming up with the same ideas as yourself.

My plans for my OS "Onic" are for it to be extremely simple and modular, even if it means redefining common OS concepts. The user interface is still in the early concept stages, though the primary goals are for it to be intuitive and easy to use. Here are some of the more technical design aspects I'm currently working on.

Application/Driver Architecture
There are no applications or drivers. All 'programs' are designed as plugins or modules. Modules are capable of running in three different execution modes: Independent, Library, and Kernel.

Independent mode is basically how applications are used today. The program runs on its own and does its thing independent of other running programs in the system.

Library mode is where the program is loaded up within the address space of another program and is used as a resource rather than an independent entity. Simple example: Imagine having a CD Player program. You can run it independently to play CDs. But it can also be loaded up as a library to another program, giving that program the ability to play CDs as well.

Kernel mode is basically the same as library mode, except that the program runs within kernel space. This is normally only used for 'drivers', programs that need to access hardware. There are many more requirements and restrictions for a program to run in kernel mode.

All programs are identified by a MIME type, similar to what is done in BeOS. This allows a program to be used regardless of where it is located and what its filename is.

Application Interfacing / GUI
All interaction with programs is controlled by the OS. Programs do not draw and manage their own interfaces, instead they import and export I/O plugs, which feed information back and forth between the program and it's interface. This is also how programs are able to be loaded as libraries, by mapping these I/O plugs to the parent program. The program interface itself is written in a markup language, possibly similar to HTML or XML. Because the program's appearance is controlled by the OS, all programs will have a unified look and are easily themeable. Some interface scripts may also be edited to incorporate I/O plugs from other programs, extending the system plugin idea. You can even create 'meta-programs', which are nothing more than hand-made interface scripts that combine multiple I/O plugs from multiple programs into a single interface, such as for monitoring.

By taking the interface out of the program, this should allow the individual programs to be very small and modularized.

The graphical interface itself will be totally vector-based, and resolution-independent.

Devices
Like programs, all devices are accessed by MIME types. These MIME types allow the devices to be categorized into classes, with a standard set of APIs for each class (beyond just open/close/read/write, to replace ioctl). For example, "storage/ide.0" might access the first IDE drive in the system, or "input/joystick.1" might access the second joystick in the system. The exact model of ide drive or joystick doesn't matter; the details are handled by the driver programs to provide a consistent interface.

sorry, unknown user, i just wiped out your "filesystem" tree. it was a bit off-topic here.

Whats bad about a High Flex Modular Operating System.

I read a bunch about people wanting to take the object oriented approach to the system, mainly this is great so i dont redefine many of my own ideas that stray very close to some of you guys own, but a major aspect in my operating system i am developing is speed. The modular glue for a modular system is the most important aspect when considering speed. For example:
If you are using a method of references objects though-out your system, mabye as a URL type deal.
/system1/board/agp/video1
/system1/sys/user/kevin
/system1/board/fdc/fd1
This glue is in reference to the code that resolves these references into actual address's of where the data or device is and what type of address it is. The problem, being quite relavent here in terms of speed is that..

A. Every time a program accesses a device using the URL like scheme the reference is resolved though a global table or code of some sort.
B. The references are resolved before run-time, excluding, the glue code during run-time.

B, seems harder but would shift the speed drag from run-time to load-time and i think anyone would rather have a load-time than run-time if they thought about it really hard.

Flexibile, Can the system run with the GUI stripped down to almost nothing or in full 32 bit brillant color.
Are you able to unmount/mount FS while processes and threads are operating from them. Causing them to freeze and then resume when it is remounted. Early, extended, and enhanced network support made possibly by the extreme modular approach allowing distributed processing and networking over a USB, SERIAL, and many other communication methods to a host computer providing the TCP/IP and/or ethernet layer. All made possible by the extreme orginizational and modular supported structor of the kernel.

Just for a example, and a look-inside at the pssiblity of making a vga driver work with a ethernet driver to provide native low-level remote displays..
Expand drivers into sub-modular levels, yet seperate from each other. (controller=driver)
-> Serial Ether Interface Controller
-> USB Ether Interface Controller
-> Remote Ether Interface Controller
-> Ne2000 Compatible Controller
-> Ethernet Controller
Remote Bus Interface Controller
Bus Interface Controller
Bus Controller
-> ISA Controller
-> PCI Controller
-> AGP Controller
-> VGA/SVGA Controller
-> VGA/SVGA Interface Controller
-> Remote VGA/SVGA Interface Controller
The system could mount up using the second best, since the choosen one "remote vga/svga" is not able to be loaded and use the normal vga/svga interface. Later, the system automaticly checks it pending controller list and configures the system to use the remote vga controller. Also, providing the ability to load a VGA/SVGA interface for multiple moniters. You could load a
VGA/SVGA Interface Controller
Remote VGA/SVGA Interface Controller
At the same time, since both of these run under the
VGA/SVGA Controller - providing some interesting results of being able to switch the system between them. Of course, problems could arise, so give the kernel is own native low-down vga driver internally to provide a ctrl+alt+del interface to reseting witch interface is being used if a problem occurs. This is called flexibility. Multiple mouse cursors on the screen, if you have two hooked up? Who would need that? but the point is does the system have the potential to do so.
Mabye using more than one USB and two serial connections to complete a distrubuted processing system between two or more computers. Also allowing one computer to crash and not crash or cause a reset to be forced between all the systems.

http://hf-mos.members.easyspace.com

Shameless advertising of third-party product: If you are using Windows, you might want to check out http://www.gpsoft.com.au - Directory Opus shows how it's done in GUI, and quite nicely if I might add.

It comes with an unlimited 30-days trial, so you might want to give it a try.

So, I'll list my key ideas here too. I have a devel-diary (kinda blog) where I write my ideas and reasons, in hope to reduce the amount of re-thinking stuff, but that's mostly lower level. Anyway, it can be found at http://ww.hut.fi/~tvoipio/diary.html

Goals
To build a modular system that makes it relatively easy to develop new modules. Provide clean semantics, so that writing simple and (hopefully) secure code becomes easier.
Try to make an architecture that makes it natural to write code that can be easily extended later.

Kernel
My kernel, Neon, is a microkernel. On lowest level it abstracts one (or hopefully later N) CPU to several virtual CPU's each running one thread. Basicly, that includes scheduler + exception mechanism.

The next level abstracts the physical memory into several user-level address spaces, contexts, that also include private namespace for references to objects.

On top of that lives my single system call, call(...) which is used to call methods of an object through the references. There are some kernel objects like memory objects and connections that provide the rest of the IPC/memory management support.

Any userlevel process can also export objects, which are handled by requesting a kernel level connection object, that acts as a kind of a proxy.

The reference the server holds allows it to request messages, while references any clients hold, only allow them to send message to the server. As far as a client is concerned, the connection object is transparent. Any userlevel server can also act as a proxy.

Filesystem
There will be no single filesystem in the traditional sense. Any filesystem seen by user is just a filesystem object provided by some server. There probably will be one filesystem private to each user, although they may share some common parts. Other thing is that the filesystem doesn't actually store files, but any other type of objects as well. The whole thing will be glue'd together with something like Hurd translators/QNX resource managers.

GUI
If I'll ever get that far, the main foundation of GUI is that users don't work with applications, but rather manipulate the objects directly.

The GUI is either just native graphical representation of an object, or a proxy object that provides such a representation. My plan is that there are no applications, just objects, and code that knows how to manipulate the objects.

A window is not bound to a specific process, but instead acts somewhat like the document window in a web browser: it displays whatever user opens there.

Language ?
Kernel's in C, rest can be anything that allows the implementation of the IPC interface, which is, pretty much anything. I'm also thinking of a special purpose LISP dialect.

Status
Kernel design going on. My first implementation of kernel is able to run several GRUB modules as (userlevel) processes (no IPC or userlevel memory allocation though), but I've started it over, mainly to have clearer semantics and simplier architecture. There also a little amount of code (mainly headers for interfaces) for the new kernel..

Oh oh, I think I am spreading closed info. HALfix is having many changes. Please apply the credits if they are needed, blah and blah. Ok.

The Gui scripting language will have 2 ways to code.
A lib, and a plugin.

Plugin:
<window id="0" caption="Look, a window" ontop="1">
<button id="0" caption="Click me!!" x="10" y="20" default="1" tabid="0">
</window>

Then you would compile this using a special compiler and send the data to the GUI. Then you listen to the messages. If someone clicks button 0. then the GUI sends "0x0005" Meaning that 05=BUTTON PRESSED, 00=BUTTON ID. It's a little bit confusing, but it sure is fun using HTML in a new way. XD

This looks similar to an XML-based scheme I'm playing with now (in fact, your markup would be XML if you changed > to /> in the second line).

A simple dialog box:

I'm not sure whether to link raw XML into EXE files, or to compile it into some binary format first. A binary format wouldn't require any parsing at load time.

Here is a method which is a little shortcut to terminal troubles. (Needs plugin system)

There are a few std system plugins, like text.putchar() etc.
So that means everyone will use them. That is great for compability. But here it goes:

A program is run in terminal mode.
The program asks if a text plugin exists.
The plugin manager says yes.
The program writes hello world and quits.
The user runs a GUI program.
(The GUI program needs to be run as root or it will mess up some things )
The GUI program is loaded into memory like normal. Since it is root, it is able to load it's own plugins. It loads the GUI.plug
The GUI.plug is a way for programs to communicate ;D
It also unloads the text plugin with the terminal functions
and loads one which uses the GUI to draw fonts on the screen.

You may not understand that, but the thing it is PLANNED to do, is switch the text plugin to write to a different location. The new location is the GUI screen.

That way, no need for terminal emulators.

Why? What is this 'root' thing? If you mean the Unix-style root, with unlimited access to everything, this is a bad idea from a security point of view.

There's no need for terminal emulators. Terminal emulation is a backwards-compatible Posix concept allowing for the possibility of connection different terminal devices to a computer. There doesn't need to be any emulation of anything.

For Developers, include this feature in your code:

keyboard:
v:
keytime //How fast a key is sent

f:
emukey
emuflag
getkey
getflag
setkeytime
getkeytime

This is a list of possible keyboard functions.
I just want to say to make it possible for a program to emulate keypresses.

Let's say you want to make a laptop remote control be able to execute ALT-TAB, you will need to make the keyboard run that key. Just a little usefull feature that should be added to every OS