OSDev.org

has anyone tried lisp before ?

A few have, yes. Putting aside the LispMs (which had special firmware for Lisp primitives, hardware support for tagged memory and garbage collection, etc.), there have been a number if tries at writing a LispOS on stock hardware. Both Mystran and myself are looking into Lisp (or in my case, Scheme) based languages suitable for low-level programming; see the Sibilance thread in the General Programming forum for some of the work being done.

Indeed, the Lisp-dialect I'm currently developing and playing with is semantically very close to Scheme too. Proper tail-recursion, no explicit iteration (except macros), single namespace, call/cc if you like that...

I'm currently starting to develop a compiler which would compile directly to native x86 binary. It has a very thin frontend, which basicly expands lisp macros and generates "metacode" for function application. There is a single "special form", namely "metacode" which just passes whatever it get straight to the backend.

The backend will be really nothing but a high-level assembler, with just enough structuring to generate sane code for tail-recursion, lexical addressing, and whatever.

Whether the end-result will be good enough to actually write a kernel/os without any other languages remains to be seen, but I'm first trying to bootstrap the compiler and will then hopefully use it to write enough runtime support to provide interactive read-eval-print-loop on linux, without any C-support, not even glibc.

High live the gui *gg*

Well, I don't know about 'overlayed' gui design for I am selfeducated in most terms - with minix book and linux internals book as a thinking aid.

Even the GUI handling Task is split up in a driver (for the lowlevel agendas) and a gui service which is responsible for all the drawing and clipping and rendering of text and maybe pictures - to some extent. Finer grained stuff will be exposed to some library which is able to draw to a buffer and send it to the gui service for further processing.

For the window moving stuff, I use the following approach (it is quite fast on a decent machine - even a PIII 500 MHZ is able to handle it smoothly):

The active window is drawn directly to the screen by the driver. Only the active window can be moved (of course *lol*), and upon mouse up, the position of the window is updated in the gui service (it just gets a message). changing contents of underlying windows whilst moving is possible as well. Only keyboard stuff is blocked away - updating the window while moving would be kinda awkward, hm?

What will the future bring for my gui idea: Yes, threads: each application will have one thread which is responsible for the gui event handling. It will talk to the gui service event dispatcher thread, which will be responsible for sending events to the applications.

In my intention, the gui service will know about how the elements will look like. an application just says f. ex. Button (x, y,handler); and the event handling thread registers the handler and sends a message to the gui service (make a button at pos x,y in the window #123).

the application itself will not need to say 'redraw' or 'repaint' for these things shall be handled by the gui service.

This will of course require semaphores (oh yes, some extra calls besides send,receive: sem_init,sem_up,sem_down,sem_props)

stay safe

Litheos is not really in official development now due to forces in my life. However my hope is that I will one day have the time to pursue it. Really I would like Litheos to be completed because I admire many major operating systems in several regards but belive that if while they excel in several area's they all plumet in others.

LitheOS will feature a monolithic/microkernel hybred. Memory/Device/VFS/LitheAPI will be functions of the kernel. Drivers will run as seperate programs. LitheOS is also designed to be interface independant so different users can use different GUI's/CLI's and run any program on the computer under there favorite environment (ex: Mozilla under bash). Also LitheOS will automatically load the latest driver in the \kernel\drivers folder for each peripheral unless otherwise specified in the configuration.

There will be three levels permission.
High: Kernel & LitheAPI
Med: Interface & Utillity Programs
Low: Programs

~ Litheos Filesystem:LitheFS ~
The filesystem is a virtual filesystem that is implemented in the kernel. Actual devices are then mounted to mountpoints in the filesystem. The goal of Litheos Filesystem is to provide a configurable, secure, reliable, and fast filesystem.

Configurable: Each folder in LitheFS will support public and private variables thus eliminating the need for a registry. When someone deletes a folder they will also be deleting all files and configurations associated with that program.
Also each folder will have certain universal variables that are used by the operating system if available such as the autolaunch variable. The autolaunch variable create the illusion that the folder is the whole executible for novice users while more advanced users can open the folder and view the entire applications including all libraries and saved games (things that might confuse novice users.

Secure: Each program when executed will only have access to the LitheAPI, files in the program directory, and files registered to it (similar to mime) in the users home directory ... goodbye spyware! Each program must be approved by admin to gain additional access for things such as Filesystem Repair and Defragmentation.

Reliable: LitheFS will be a journaled FS with next and previous pointers and file id as well as software raid.

Fast: LitheFS will support native raid-0 (on the boot partition) & excelent caching ... darnit it's going to be fast.

~ LitheOS Application Interface: LitheAPI ~
LitheAPI will load into the kernel on startup. It will exist as a seperate file on the FS only so it's easy to upgrade.
Distributed Computing Interface:
This will interface kernel's across a network allowing someone to add remote resources to a machine.
Graphics:
Any program can be run from any CLI or GUI (graphical or consol).
Sound: Blablabla
Mouse: Blablabadiblabla
(More on this stuff later but just your standard stuff ... doesn't take a whole lot of imagination ... it's an API used for everything from graphics to sound to networking to RPC to calling the filesystem)

Litheos:
-Pro's
--Easy to use/maintain
*Singoe configuration for os loading. (see Litheos Filesystem for how configuration is managed)
--Programs Independant of Interface (GUI/CLI)
--No dependancies
*LitheAPI -> Single API for everything (no linux consol/xwindows, Directx/OpenGL/Win32 Libraries).
--No Registry ... all variables are stored in the program folder
*Filesystem implementation like we have never seen (see Litheos Filesystem)
-Con's
--No spyware, viruses, or trojans unless user is stupid enough to install them, log into admin, then grant them medium security.
--Everyone isn't tied to the defualt interface so your friend's computer be cooler than yours :(

Hope you liked my idea's,
--Jem

the '"CLI/GUI" independance seems hard to achive ... When you say "running mozilla in BASH", are you talking about launching mozilla from a shell and than have it executing in its own window or do you really believe you'll be able to translate requests for scrollbars, icons, truetype'd text and GIFs into ANSI characters ?

CLI doesn't necisarily have to be text mode graphics. There are some things one can do often faster when experianced using CLI. More than likely everything would be done atleast 640x480x16 or some vesa resolution.

That said a GUI or Hybred would be the weapon of choice for most people. However the idea is to make it as easy as possible for someone to write there own Interface be it CLI or GUI and map there comands to system calls (ex: dir, ls, or the LitheProbe File Manager click ... all same call).

Some more stuff from earlier doc:
Filesystem
The LitheFS will be a high performance journaled file system. Each LitheFS Partition will be a single partition that can be divided into parts (similar to FreeBSD). The first three values on the partition will be the preloader starting point, the preloader ending point, and the LitheFS partition table. The LitheFS Preloader is installed when the partition is created. The LitheFS Partition Table lists the different virtual partitions inside the main LitheFS partition.

The LitheFS Preloader loads the kernel, mounts the OS Partition to \OS, and loads the appropriate drivers for the kernel. After the previous steps are taken it then jumps to pmode and hands control over to the kernel which now has a filesystem and can read the configuration. The kernel then mounts other mount points and asks for user login followed by mounting the users home directory to \home.

/os   This Mount point is where all they OS files reside.
/os/drivers   All the drivers for the computer are located here.
/os/config   This is where system configuration files are stored.
/home   This is where the user?s personal files reside.
/programs   This mount point may be a directory or consists of paths and/or partitions specified by the admin.
/devices   This is where the currently loaded devices show.
/local   Local drives and mapped network drives are mounted here.
/network   This is where networks devices are listed.

LitheShell GUI (see attachment)
While LitheOS is designed to be completely shell independent an intuitive shell must still be supplied. With built-in support for drag?n?drop, favorite linking, and variable monitoring everything needed is included.

The LitheShell GUI is designed to be as fast, efficient, and user friendly as possible while loosing nothing in functionality. Due to the unique file system litheos implements the launch button actually displays the filesystem. (See illustration below)

Folders in LitheOS will be able to point to a file to launch. When a launchable folder is displayed on the menu a right click will launch while a left click will expand so the contents can be explored.

LitheProbe: Defualt Litheos File Manager
LitheTuner: Defualt Litheos Configuration Tool

Thanks,
--Jem
PS: \Kernel from previous post is actually \OS ... didn't consult my documentation.

[attachment deleted by admin]

Because I'm pretty new here , I would like to "restart" with the topic.
Because I like programming (yep, a true programming geek ), my OS is designed to run in PL 3 (much operating systems do) (edit: kernel works in pl 0, this wasn't mentioned ), and it is designed to work fast, because I want to start programming, immediatly.
And my OS is designed for another thing, the internet.
Because internet is the media of the future
So my goal is to implent nic support and TCP/UDP/IP support in the kernel.
But unlike many other people, portabilaty is not #1 goal of my OS design.
Why ?
Because I'm going to use it only on intel based processors.
And another reason is that I program my OS entirely in assembler (is this a good reason ? ;D )
And another design of my OS is: user friendly ness (or something like that, damn English! ::) )
So any other user (who's a programmer) could work with it.

I told my OS design, I hereby say to you all: "discussions about my OS design may begin now "

I don't set that high goals..
My goals with BOS is:

that i should be 32-bit. (maybe 64 aswell)
have a simple command line.
be able to run small programs/games.

thats it..
when it's ready i can start dreaming about security, gui, fs and all other things..

/ Christoffer

Errhm. If every user was a programmer life would be better ... But "user-friendly" usually targets Joe Average, Toni Admistrati, Mrs TypeRight and the others, not only Sarah Progrmatzki and Frank Freebytes ;D

Uhm, I meant, that you don't have to read 1000 manuals to work with it

];-> *hehe*

Is it true, that the members of the holy church of St. Gnucius consider everything outside the realms of the Book of Stallman as heresy? *waaah, up on them with roar and away wi'em bloody sinners 'thou' they are, blimey!*

uhhuh yep. To be proper gnu software it needs to "do one thing and do it well" - so each program gets really huge having all sorts of features nobody uses (do it well) whereas you need to establish links between each program to make it work half-decently.

PS: typing with one hand reminds of tapdancing . Hit by a car yesterday so Im a lot less present the next 4 weeks...

Neither am I trying to set up high goals... I think. Just a simplified non-optimised exokernel.

Drivers pushed out of the kernel just like almost all interrupt/exception services. I'll try to make everything possible application managed just as long as I can maintain system security.

This effectively means that the kernel decides on who can use a page of physical memory,a raw disk block, a packet coming from the network (a separate handler for redirecting packets unfortunately needed here but it won't be in the kernel itself) or a device in general... I'm just going to maintain a few simple kernel data structures like tables and the primitives necessary to manipulate them.

And the kernel takes care of storing user and group information together with information about access rights of those users and groups to system resources. The kernel does now know about any abstractions so it doesn't protect anything else than the raw hardware resources and users and their processes from each other.

So the kernel does not for example know what a file or a filesystem is. It only has tables which map access rights to users for each raw disk block (or sector). This way there can be many filesystems (either concrete or abstract) on the same drive and partitioning becomes almost pointless although possibly with some no so difficult changes to the kernel it could be well-supported.

And of course the kernel includes a system initialization process which turns into a login process when the initialisation is complete and runs in the background all the time so that people can log into the system. Device drivers are loaded as add-on modules with the kernel so that hardware can actually be used. Of course adding and removing modules later at runtime will be possible (at least I hope that I can implement this).

The actual OS functionality is placed in libraries. I'm dreaming of building a Lisp libOS on top of this exokernel when it's complete.

And oh yeah... I'll probably write this in C++. If that doesn't work I'll use C. Not because I like these languages but because better ones don't seem to be available...

A stupid kernel might be simpler after all... at least that is what I'm hoping for!

Cheers! Any comments?

<moderator> the resulting discussion about emacs and text editors has been forked to a thread of its own </moderator>