OSDev.org

I recommend using GRUB2 and Multiboot to load your kernel. You really don't want to muck around in real mode because it's a piece of **** and will only distract you from the actual goal: making an operating system.

If you want to get a minimal C kernel up and running, just follow the recommended http://wiki.osdev.org/Bare_Bones tutorial. In that you use a GRUB to load a C kernel. There is no shame in using GRUB or doing a 32-bit kernel first - I can assure you there is plenty of very interesting things to deal with in a kernel.

Making an OS from absolutely nothing is a very big load of work. I know it because that's the way I decided to make things that way, for both the OS and its build system. If you try, then you will realise that making up a bootloader that is flexible enough is the same as writing a simple Operating System, and GRUB is a right example of that.
To help out, I suggest that you download the GRUB source code anyways... Not to use it, but just to look how certain things can be done, or organized, or just find some help...

Then, can you tell me why exactly do you want a 64-bit OS ? I personnally preferred to start with 32-bit protected mode, which is a bit simpler (As far as I heard) and also much more documented in tutorials.

Also, if assembly is "just too much for you", then OSdev is "just too much for you". I mean, you can't do OSDev without to know assembly, and you'll face situations that only assembly can solve, and copy-and-paste of somebody else's code is not an option, and will only lead you to code that doesn't work and you can't find why, because you won't understand that code.
So it is necessary that you know assembly before to even try to code your OS.

Also, always remember that: don't underestimate the complexity of OSDev. That is because you are COMPLETELY on your own. It's not like in user-space applications, where you can take a framework/library that will do it for you. Remember that in OSDev, there's NOBODY and NOTHING who can do things for you. The only exception is the boot loader, where you can use a pre-made one, but you rejected that option.

To the one who said that writing a bootloader is writing an entire program in assembly, I'd answer that GRUB is a very popular bootloader, and its code is mostly C code. The trick (for the x86) is to enable protected mode early, and then return to real mode when you need to call upon the BIOS or any other 16-bit program (in case you are booting from DOS or another 16-bit OS. For example, I have already written a program running under Mike Shaunders' MikeOS and bootstrapping my OS Loader (bootloader), which helped me out at the early stage, since there still were a platform under myself to handle things such as loading files, or managing keyboard input.

Also, you seem to favor VirtualBox, but I suggest that you use Bochs instead, which has a very powerful debugger. For example, you can enable an option that allows your OS code to write to the debugger's console, which is very useful when debugging your screen driver, or just making the debugger break when your code asks for it.

Anyways, if you ever need help that you don't find in making a bootloader, know that I am making one too, so if you've got any questions, just tell me

Xcode wrote:I spent two hours here (not exactly the best resource, but good enough for me to get a good grasp on certain concepts) and I now have my own OS, which prints the name on startup and uses a multistage bootloader to put me into 64-bit mode. This is what I thought would take up my entire summer.

Good to see that you found that out - many things that look impossibly hard can become trivially easy when you happen upon the right guide to take you through them. You can now develop the simple code that you already have to do anything important that a fancy bootloader would do for you and without getting bogged down in all the unnecessary complexity caused by having to wrestle with someone else's bloated bootloader. Don't worry about being able to boot from all the different kinds of obsolete media either: just stick to one simple way of booting and loading from something like a flash drive (but be aware that you will want to switch to using EFI for booting at some point in order to be able to use the many future machines which will have no BIOS - it is vital that everything you do should be written with this in mind so that you don't find your operating system being restricted to machines that would be most at home in a museum).

Status update, for anyone interested.

I have my own multi-boot system setup, which boots me into 64-bit mode with a (very) basic UI. It doesn't exactly function, but it is looking like it will once I get mouse and keyboard integration. I am a bit worried that I may be going too fast and missing the important things, but I suppose that is what the first time does - put things into perspective. I only have a few questions that I cannot answer, but those seem to be very important.

Is there any way to make my own filesystem? FAT just doesn't seem to very good for a system like the one I am trying to create.

How do I turn my .raw into a .iso file?

Xcode wrote:Status update, for anyone interested.

I have my own multi-boot system setup, which boots me into 64-bit mode with a (very) basic UI. It doesn't exactly function, but it is looking like it will once I get mouse and keyboard integration. I am a bit worried that I may be going too fast and missing the important things, but I suppose that is what the first time does - put things into perspective. I only have a few questions that I cannot answer, but those seem to be very important.

Is there any way to make my own filesystem? FAT just doesn't seem to very good for a system like the one I am trying to create.

How do I turn my .raw into a .iso file?

http://wiki.osdev.org/File_Systems#Rolling_your_own
Please don't create your own file system there are way too many out there already. If you don't like FAT there's always EXT2/3/4 or even SFS. If you are using a CD you will have to use ISO-9660 anyway unless you are planning on using floppy disk emulation.
To create a CD image on Linux/BSD/OSX I suggest you read up on the mkisofs utility. On Windows you'll need to find something else.

On OS X you have to install xcode and from xcode preferences enable cli tools. I downloaded sources for gcc, gnu linker and other tools and all the libraries needed and compiled gnu versions of the tools since the ones on OS X does not support all features (linker scripts for example). It's been awhile since I have done any osdev so I'm sorry that I can't give more accurate help.

OS development is quite hard to without experience. That is why I recommend not to start making an OS at first. It is easier to start creating "low-level-freestanding" programs. For example, creating a boot loader that starts a program that does one thing. These are not literally programs but you all know what I mean. Grab keyboard codes and print them on the screen, for example.

This is quite a natural way of staring to explore the field. What I am after is that perhaps the word OS should be reserved for actual OSs. This does not apply to this topic only. These things are low-level experiments or something like that. I do not know any suitable word describing this. However, it is not important anyway. The advantage of all this is that a developer can have a reachable goal and have that project finished. "Typewriter for PC", for example.

Xcode wrote:Yes, but I understand how C works. Looking at Assembly is like looking at Greek or Russian. C just looks like English to me, even with the code you see in the OS X kernel.

OSDev isn't all about knowing the language. Sure, you need to know the language, but you need to know how to work with the hardware.

Antti wrote:...creating "low-level-freestanding" programs. For example, creating a boot loader that starts a program that does one thing. These are not literally programs but you all know what I mean. Grab keyboard codes and print them on the screen, for example.

...What I am after is that perhaps the word OS should be reserved for actual OSs. This does not apply to this topic only. These things are low-level experiments or something like that. I do not know any suitable word describing this. However, it is not important anyway. The advantage of all this is that a developer can have a reachable goal and have that project finished. "Typewriter for PC", for example.

Yo:

I call those "bootable applications", and share this view pretty strongly myself.

--Peace out,
gravaera

Antti wrote:OS development is quite hard to without experience. That is why I recommend not to start making an OS at first. It is easier to start creating "low-level-freestanding" programs. For example, creating a boot loader that starts a program that does one thing. These are not literally programs but you all know what I mean. Grab keyboard codes and print them on the screen, for example.

Writing DOS applications used to be my recommendation - mostly for the same reasons.