Where do I begin to get a program running in my OS?

[DavidBG]

Hello there:

First of all, I'll be honest: I am a HORRIBLE C/C++ coder. I know nothing about it other than the structure. So please don't answer me in C. I am an ASM coder, I make games, networking apps, libraries all in ASM. So I am skilled there. Now, I am making a hobby OS for fun and currently it can use a custom bootloader I made (that was hard, but I got it in the end when my kernel went over the 512 byte limit), and it has a command line kernel. I tried searching for an answer but couldn't find one so here goes my question:

Where do I start when it comes time to implementing a file system? Like how do I recognize files on the drive? (The DIR command in DOS) Then, where would I start in getting some kind of a simple application running?

I honestly hope this isn't asking the obvious, or that I am wasting all your time. But I got that OSDev bug and I am greatly enjoying this.

Thanks for any help!
David

[IanSeyler]

If you are an ASM coder then check out the code for BareMetal (The OS I am writing).

http://code.google.com/p/baremetal/sour ... #svn/trunk

Main things to look at would be init_hd.asm (grabing the specs, FS info), hdd.asm (reading and writing sectors), and fat16.asm (FAT16-related calls for reading files, directory list, etc).

-Ian

[AndrewAPrice]

Have you looked at the Wiki? Most of it is language independent. What have you reached already?

The basic principle of loading programs is you extract the executable code from inside the binary (be it an ELF, PE, flat binary or whatever), copy it to some part of memory, and jump to it. Look at any bootloader tutorial and that loads a simple "kernel.bin" from the root directory of a FAT12 floppy.

However it gets a lot more complicated for multitasking. Here are some of the typical requirements:
- Interrupts:
The hardware triggers interrupts when certain IO events occur (such as keyboard input, the floppy signalling it's done, the timer).
- Paging:
Each program lives in it's own virtual address space and cannot touch the memory of other programs.
- Memory management:
You'd need some way to dynamically allocate and release memory in your kernel for the various per-process structures that will be created and destroyed.
- System call:
A system call is typically a software generated input. These are effectively function calls into the kernel. You'll need them for a program to tell the kernel that it wants to run another program, allocate more memory, or finish running.
- Multi-tasking:
This is where interrupts come in. You configure the timer to fire an interrupt at a certain interval (for example, every 8 milliseconds) and when it occurs you switch the current running program (this is done by your timer interrupt handler so that a program stuck doing something processing intensive it won't hold up the entire system). This can also occur by a software interrupt too (e.g. a program handles a keyboard interrupt, does it's processing, then is put to sleep until another interrupt occurs). Switching context is as simple as pushing all the old registers onto the stack, update the page directory and stack pointer so they refer to the next process, then pop all the registers from the stack and return from the interrupt and you'll be running the next program.
- Inter-process-communication:
IPC is a very broad field and essential if you want your programs to communicate. At the most basic level, program's can communicate by files, but more advance ways include pipes between two processes, giving each process it's own inbox so they may send messages between each other (both asynchronous, and synchronous and wait for a reply), and shared memory.
- Virtual file system:
You'll need a consistent way to access your disks (much like the mount points in Linux or drive letters in Windows) regardless of the type of disk or file system. This is covered by the virtual file system. Underlying the VFS are the file system drivers (FAT and EXT2 are the most popular). File systems are just big structures stored on a disk that usually group files together by directories.

Everything you need to know is covered on the Wiki. Not knowing C is not a problem, though it may be a disadvantage if you can't fluently read C as a lot of reference code is in C. It may not be an issue starting out but when you're trying to read other source code to figure out how a piece of exotic hardware works it will be.

Good luck!

[DavidBG]

If you are an ASM coder then check out the code for BareMetal (The OS I am writing).

That seems to be a pretty good help. I like the coding style. (Easy to follow)

Not knowing C is not a problem, though it may be a disadvantage if you can't fluently read C as a lot of reference code is in C. It may not be an issue starting out but when you're trying to read other source code to figure out how a piece of exotic hardware works it will be.
Good luck!

As to not knowing C I am realizing that it would be good to have a working knowledge. The computer world seems to speak in it.

Thanks for the info though. I should be able to start from here.

David