the HakwareOS project

[unknown user]

hi. i'm working on an os called HakwareOS, which i think will be pretty cool. here are what i want in it:
-vfs which supports fat, fat32, and ext2
-support for dos .exe and linux elf executable formats
-int21 api (dos)
-int80 api (posix)
-pmode/paged mode
-tcp/ip support
i have plans and partial code for a lot of the stuff, but i need some volunteers for helping develop all this. i wish i could say i did all this stuff by myself, but i don't think i could. if there are any of you out there who aren't tied to a project and would like to help out officially, please respond to this post or email me at [email protected] .
flames: [email protected]

btw, i already have my beginning code up online, just so you guys can see how little i got done (i did it in 4 days, between finals). you can download it here: http://hakware.cjb.net/downloads/hakwareOS-1.1.zip

[unknown user]

what? no one? :-\

[unknown user]

ok, i found some people. currently, there are 8 of us. if anyone wants to join, go ahead and join EFnet #hakwareos (irc).
people currently in project:
-Jag3k: vfs
-Napta: shell
-ToreSB: gui/mui and svga drivers
-zid_: keyboard drivers (and eventually other drivers)
-m0lted: beta testing
-lilpyro: command line utils
-hakware: the main kernel code and mouse driver
-enforcer: command line utils
-Two9A: bootloader

[Tim]

Wow, what a lot of people.

unknown user: I hope your management skills are pretty good, because that's a lot of programmers who'll each have their own idea about how everyone else should write their code -- either that, or they won't even have a clue how to write their own code.

[Pype.Clicker]

wow! so much people in so little time ... congrats.
btw, who's gonna write down string manipulation and memory management code that everyone else will need ?

[unknown user]

i have someone working on my memory management strategy right now. currently, all the code is in asm, but we're working on a vfs in c++ also.
our dev chan is EFnet #hakwareos if anyone wants to drop by.

[unknown user]

we may need another kernel coder (fluent in i386 asm please), but we can do without him if no one volunteers. we could use a few more people, though, in case anyone wants to join ^^;.

[unknown user]

it's now officially called Jenova/Hakware (hakware is the kernel, jenova is the environment), and it has gotten a large amount of new stuff put into the project, so much that i haven't had time to fit it into the main kernel. we have vga/svga, keyboard, and ide drivers, and the gui/mui, vfs, hd bootloader, and api are in the works. the manefesto is attached under hakware.txt .
if you'd like to support the project but don't have the time to code anything for it, you can buy some (*sic*) merchandise at http://cafepress.com/hakwareOS ^^;.

[attachment deleted by admin]

[Pype.Clicker]

appealing .txt file, but i'm afraid you underestimate the difficulty to reach all those nice goals you tell.

few things:
- i'm not sure "programs/office-mate/1.2" is such a user-friendly name
- mixed GUI/CLI seems to be on the mood for start-up OSes, especially the tool i like to call the "foobar(c)" (kind of toolbar for fools , giving immediate access to everything. However, think about it: the Foobar is just but a shell that can grab the cursor with a magic key, if the rest is designed correctly (for instance if you can program getRunningInstance("webBrowser").gotoUrl("http://"+userdata)
- and he already has "merchandize" stuff too bad there aren't black shirts, the logo would have been more deZign on it

[unknown user]

actually, the mui is a pretty cool concept. tore didn't talk about it in there (i didn't write the .txt), but it actually parses english sentinces, like a mini Project MAC (!!!). if there's a word it doesn't know, it guesses and asks if the guess is correct. the mui interpreter also supports command lines (command mode can be entered, and for one command one just puts a ! at the front) and quick gui control (#button presses a button, and %textbox moves the cursor to the text box that has the specified label).
most of the user-friendly stuff i'm not really in on. i'm mostly the "kernel man", aside from my job of writing the mui interpreter and making a skin, so you can't really ask me the original reasons for various design flaws^H^H^H^H^Hdecisions ^^;.
luckily, the os is gpl'd, and we are releasing all the pieces when we feel we have something useable, before we finish up and start selling it, at which point you can still download it, etc.

[Tux]

Why Jenova as the name? It sounds funny. No offense or anything. Probably try putting Hakware and Jenova in one secret name. How about HakenOS?
I can just imagine friends in school:

Friend: "So what were you doing?"
Me: "Oh, I was just on Hakin " (Just changed one later to make it easier to realize the irony)

But, a name is just a name. It's your OS and you can decide what you want to call it.

[unknown user]

system design doc (taken from OS Design thread):

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. The file structure is organized like this:
/system
->/devices
-->/$device
--->/communication
--->/description
->/drivers
-->/$device
->/source
-->/$program
/programs
->/$program
-->/$version
--->/$executable
/userdata
->/$user
-->/documents
--->/$documentfile
-->/settings
--->/$program
---->/settings

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.

[Pype.Clicker]

Code: Select all

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.

sorry, but this one seems simply unpractical to me. Correct me if i'm wrong, what you plan to do is in some way insert the code of the called module in the caller one ...
In addition to the fact that it is technically hard to achieve, you seem to miss some important points about caching efficiency. repeated call to a function can be way faster than inlining the function if the repetition is done many time, as there are chances that the function is always present in the instruction cache. Therefore, it will require very less cycles to fetch it from memory.

Thus, unless your function is small enough so that it's body's cost is roughly equal to the call/leave code cost, forcing the inline doesn't worth the effort...

[unknown user]

it's not an inline. i'm just eliminating far calls. currently, my concept of the kernel would be initialization, task switching, and ISRs. i'm including the binary in through nasm's INCBIN metacommand.

[Tim]

Why not include the binaries using the linker?

Or, better still, write a dynamic loader?