AtlantisOS

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Post Reply
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

AtlantisOS

Post by Candy »

I'm working on AtlantisOS. It's currently a one-man project.

The project page should be www.atlantisos.org, but I haven't come around to putting anything on it. I'm choosing to be a project with an OS and without a good-looking website, rather than the other way around.

I'm working on it quite actively again, as opposed to a short while ago when it was about dead. The subversion archive is at http://svn.sourceforge.net/viewvc/atlantisos/ and atm receives between 0 and 4 commits per day.

The current status of build process assumes you have a host compiler installed as gcc / ld / g++, an i586 cross compiler as i586-pc-elf-* and an amd64 cross compiler as x86_64-pc-elf-*. It also assumes yasm being present.

You need all crosscompilers irrelevant of the target you're trying to hit. That is mainly because the boot block for x86 needs to have ELF loaders for all the types your computer might be able to run, so you need at least i586 and x86_64. You need a host compiler to compile the compression program so you can create compressed ELFs (which are used by the compile process itself).

Generic design is:

Bootsector is loaded, it loads the rest of the bootblock of 32kbyte using a fixed unsigned int in the boot sector of itself. It then presents a menu of choices. Each menu choice has three strings and a flags word attached to it. The strings tell it how to call the entry, what file to load, what auxiliary file to load and the flags tell it what to decompress using what algorithm and whether it likes a built-in bootloader for whichever format the executable is in. At the moment there are bootloaders for ELF files on x86-64 and i586. Hello world-files are included that just display "hello xxx-mode world!" in whichever mode they run and two ELF loaders are included that'll load any ELF file you can throw at them (as soon as I actually add the code that calls them, that is).

The kernel consists of a core, a lot of library code, a trampoline and a lot of drivers. The core interfaces between a bunch of functions and a few modules and the actual hardware, the trampoline interfaces between the userland code and a bunch of modules, the library is just present with functions and the drivers actually use and release objects into kernel space. Objects added are dynamically probed against all modules and passed to those that wish to open it. This mechanism in the end resolves all module linkage to dynamic links between them. The objects are objects in a C++-sense with virtual functions but implemented in C, to keep track of every byte in the kernel space.

The userland libraries consist of the OS library (libos.so), the C library (libc.so), the C++ library (libstdc++) and the AOS library (libaos.so). The first and the last would initially have merged but this presented a mixing of responsibilities. In particular, the C library depends on the OS library (for system calls), C++ depends on C (for only malloc at the moment, but this will increase) and the AOS library requires a full C++ environment, so it depends on libstdc++.

The OS library contains only simple functions that just forward responsibilities to the kernel. I'm hoping to rewrite this with variadic templates or variadic macros, but that'll be in some bit of future.

The AOS library contains module handling for userspace, in which you request a module for a given operation in normal description after which you're either given a matching module or a null pointer. The module can be registered after the programs have started without negating their applicability. This makes it possible for programs to be written on generic types that can be specialized to fit reality. In particular, the text-editor includes the unicode-module and can read all unicode at runtime, without even knowing about utf-7 in code.

The OS is based on a new filesystem, that has functionality that is required for proper operation of this mechanism. It most of all includes a mandatory, system-set type of file that other than the extension includes information people didn't find mentionable in the past, such as charsets for text files or generic image information for images.

Oh, and I work full days, have a girlfriend, used to moderate the MT forum and I'm going for a masters. I'll complete this in two days.
Post Reply