OSDev.org

Hello... I'm new to this forum, so please don't nail me down. I am a 9th grade student attending TJHSST.

This is my first OSDev.org forum post!

So I am working on this operating system called 'Arcrascent Operating System'. I've been working on it since June 22nd, 2013, in my 7th grade year. Its kernel, "ArcShell", is UNIX-compatible and supports a variety of necessary features, such as paging, memory management, virtual memory, vm8086 driver, real-mode emulator, full-fledged VFS layer, FAT12/16/32 Filesystem, EXT2 Filesystem, Device Filesystem, Read-only EXT3 Filesystem, PIT driver, RTC (real-time clock), ACPI shutdown & reboot, ELF execution, full-fledged UNIX-compatible syscall layer (installed to interrupt 0x40), serial console (codenamed "SerCon"), VGA mode 0x13, some VBE, and others... I've gotten through many obstacles through googling, but there seems to be a lot more I have to face. I hope (since all you guys are good people) you guys can help me out when I run into issues (especially heisenbugs)!

This is NOT meant to be a UNIX clone in any way. The only reason I have the UNIX syscalls is because I want to be able to port UNIX-based software easily. The OS actually has a more complex set of APIs of its own that exceeds the capabilities of UNIX.

Here is a screenshot of my serial console:


And this is a screenshot of me testing VGA mode 0x13:


I'll post updates if anything significant happens!

Please take a closer look at the forums first - we have an announcement category.

Screenshots of your OS go into the pinned topic for screenshots.

That sounds pretty awesome! Is there an image available? Is the source available?

Is it written completely from scratch?

Cool stuff. I'd like to see a binary download, and I would like to glance at your source code, it gives a good impression of your work.

Yes, it is written completely from scratch. I've been developing it since I was in 7th grade (2013). I am now working on the more "high-level" aspects of the operating system, like porting OS-Specific Toolchains (GCC, Binutils, etc.) and the GUI (I am planning not to use free libraries like LibPNG, LibGTK+, or Cairo for graphics management. I am sort of anti-GNU. I am developing my own graphics library called "iVGA" instead.).

you can visit http://arcrascent.wordpress.com to see screenshots of the OS.

But sorry, but no... The OS is closed-source at least as of now... And neither there is any public image releases yet... Plus, my 64-bit machine broke last week and is in the repair shop for now so I cannot produce any more new images for a couple of weeks... But once my machine comes back, I'll post an image as soon as possible. But you can still PM me to request private access to look at how I implemented things like:
- Realmode Emulator (Physically emulates Intel 80186 Microprocessor; Works with long mode )
- v8086 Monitor (but I'm sure there are other great implementations)
- Switching to VGA mode without BIOS interrupt calls (faster than traditional int 0x10 BIOS interrupt call mode-switching mechanism)
- Serial Console
- Process Management/Multitasking
Again, PM me if you would like to request access. (you are going to need a bitbucket account).

If you gain access and would like to build the OS, these are the steps: I am personally using Ubuntu 14.04.10 LTS on x86_64 arch, so I cannot guarantee success if using another platform. The OS requres MASSIVE resources to build.

1) Clone the repo at https://[email protected]/arcr ... os-rc.git/
2) "cd" into the directory
3) run

Make sure you type "bash" instead of "./", since the executable flag is not set yet (the script will automatically do that).
Once run, the script will:
----------------------------------------------------------------------------------
Install the following packages on your system:

- nasm (assembler)
- xorriso (el torito file system image creator)
- qemu (i386) (virtualization software I)
- bochs (virtualization software II)
- bochs-x (virtualization software patch I)
- bochs-sdl (virtualization software patch II)
- flex (lexic parser)
- automake (automake software; for building GNU software)
- autoconf (autoconf software; for building GNU software)
- texinfo (TeX support)
- sloccount (lines-of-code counter)
- virtualbox (virtualization software III)
- grub legacy (bootloader)

Then, the script will download the following packages to obtain old releases of software and libraries required for building several GNU utilities (e.g. GCC, Binutils)

- autoconf v2.64
- automake v2.64
- GCC v4.4
- GCC multilib v4.4

WARNING: The script will hard-link the old binaries to fit the up-to-date binary names, and preexisting binaries of software in the above list will be backed-up (e.g. gcc --> gcc.old), but overwritten and the up-to-date binaries WILL NOT BE INVOKED WHEN THE BINARY IS EXECUTED VIA COMMAND. (i.e. "gcc" after running the script will automatically run GCC v4.4 and NOT the preexisting gcc (probably v4.8.x or v4.9.x).) (e.g. /usr/bin/gcc-4.4 ==> /usr/bin/gcc)

After that, the script will change default GNOME configurations (if existent) to fix automount bugs and set executable flags (+x) for shell scripts in the source code library.

Finally, the script will automatically download the i386-elf-gcc cross compiler and install it to ~/cross/ (the directory will be created automatically by the script) and add it to the $PATH automatically.

----------------------------------------------------------------------------------

4) The script will automatically setup everything (so you don't have to !), so no worries about dependency issues
5) Now, I am very lazy, so I wrote a bunch of stuffs to do different things. The one you are going to use is "makeos.sh", the script to automatically compile, link, and a build a floppy or HDD image based on the arguments supplied, it will automatically take care of the version management and build number management (automatic incrementation).
The script will also "cp" the contents of the directory "Additional/" into the ROOT of the image... so if you would like to add additional files to the image, simply add that image to the directory.

This is the synopsis:
- The script takes 2 arguments, the cleaner and image type
- The "cleaner" argument is either "--true" or "--false"; "--false" will automatically clean-up temporary files generated by the script (NOT the object files) -- this option increases because some other scripts that call this script need the temporary files to read version info about the current build. "--true" will keep those temporary files.
You will almost always use the "--false" option.
- The "image type" argument is either "--fd" or "--hd"; obviously, "--fd" builds a floppy image and "--hd" builds a HDD image
So:

Will build a floppy image and clean-up script temporary files

And

Will build a HDD image and clean-up script temporary files

If you build a floppy disk the image will be called "Floppy.img" and hdd image will be called "hdd.img".
Just in case you haven't figured out, the code is in the "SYSTEM/" directory!

6) Now to the testing...
run the "test.sh script". It takes 2 optional arguments
- "--hd" or "--fd" depending on your image type
- "--bochs" or "--qemu" to choose emulators
If no arguments are given, the script will use the hdd image by default, and if it is not there, it will look for the floppy image.
ON THE OTHER HAND, if the second argument is missing, it will simply use QEMU by default:
So

Will use hdd.img if existent or Floppy.img if not and use QEMU

And

Will use Floppy.img with Bochs emulator

Got it??

Anyways, +muazzam, the forum tells me that you are 12 years old. Are you actually 12 years old and in 10th grade and doing OSDev?? That's pretty darn intense. You beat me by a lot! And i also saw your post about you favoring asm over c because you feel more comfortable in asm. Wow... I personally love assembly but cannot replace C for it because asm, it is so "simple" (everything looks the same once you write/read asm for hours) that you forget what you were writing...

I wrote a whole .Net Framework in Assembly alone, later ported parts to C# for use in my operating system, the whole foundation for my Kernel was written in Assembly and then drivers and such was written in C#. Osdev is fun!

Uh. You say it is closed source but still post build instructions.

Also that script sounds incredibly dangerous. DO NOT MESS IN /usr!

I really recommend you make it harder to build your OS. Mega scripts like this are too fragile, not flexible enough, and not portable enough. Just tell the user what to install in a README and let them do it and build their own cross compiler.

I mean, the /usr is modified just for symlinking binaries (like /usr/bin/gcc)...
But you are right about the portability... because my fat script uses apt utilities and hacks that only work on ubuntu.
Hmm... Would it work if I just list the instructions to buliding it (dependencies, makefile synopsis, etc.) and optionally provide the "megascript" for people who work on Ubuntu?
I mean, I created the script in the first place because I am ultra-lazy, like really lazy...
I am too lazy to do
make all
make ArcShell
make ARCLDR.SYS
make fdimage
so I condensed it originally down to ./makeos-fd.sh
but then i was too lazy again so i started adding argument support like
./makeos.sh --false --fd
So the build tool automatically takes care of the version management, buliding, releasing, and all those things... Right now the build chain is very massive and complex, but as you have said, no, they are not portable... But i mean, once I move into self-hosting, i'm going to rewrite the whole build chain again, so I don't think it matters that much right now.

P.S. I can grant you access if you just PM me...

Hi, 0fb1d8.

Have you implemented userspace tasks (or processes, or whatever)?

Yo:

@OP: nice project -- keep at it~

--Peace out,
gravaera

Thanks! Your cheers really help me!
Have a nice day

Yes, I have a full-fledged process-management system
- multitasking
- v8086 tasks
- kernel tasks
- user tasks
- automatic stack management
- process prioritization
- process forking (i call it replicate())
- mutexes

I should add multithreading actually, now as i look at it.....

Hi 0fb1d8, Actually I am 13 years old and it is true that I love assembly. By writing code in assembly, I feel that I am writing code in a turing machine or big calculator. And I am actually doing OSDev.

I think it would be better if you installed the compiler to a directory like /opt/my-toolchain and then added it to the PATH.