OSDev.org

This might be a dumb question, but I cant seem to grasp the principle on how to make my asm loader load up a play C binary file. Have not found anny in-depth enough documents on it.

Well, first you need access to the hard drive, i.e. driver and file system. (Or, you need the binary in a fixed, known location instead of "knowing" the file system. You still need the driver though.)

Then you have to copy the executable into physical memory, and jmp to the entry point of the executable. Beware that the executable must either be loaded to the address it was compiled for, or you have to do relocation (which you probably don't want to do).

Or you could use GRUB to load and start your ELF binary... (I know, shameless plug... )

Ok, that actualy cleared things up a bit Re there anny file system tutorials around. Im actualy interested in creating my own file system anny good docs on that?

hmm, before you design your own filesystem, i suggest you do the following:

• make sure you fully understand FAT filesystems, for it has virtually all the flaws you could want to avoid. Information about FAT filesystems are available on Operating System Resource Center (see .:QuickLinkz:.)
• get a look at how Unix file systems are organized, especially make sure you fully understand the concepts of inode, indirect block index, double indirect, etc.
• Check Andrew Tannenbaum's paper on NTFS. "Knowing yourself without knowing your enemy only gives you half a chance to win". Imho, NTFS is very interresting because it uses files even to implement files. This means it's very straightforward to read an NTFS partition and that the same FS organization can be kept while the algorithms that perform allocation, fragmentation reduction, data locality etc. can be upgraded transparently from one release to another... However, as these algorithms are usually not divulged to the unauthorized ones (us), it's hard to write a good read/write NTFS driver if you're not at MS research center
• Get a look at journalized file systems. Make sure you get the principle. I also suggest you get a look at Reiser's internal structure, which uses B+Tree for storing files in a very smart way ...

When this will be done, i suggest you address the File System in a layered approach: First there is blocks allocation, on top of which you create 'sequence of blocks' for different purposes, and one of those purpose is to create files. Then, when you'll be able to read and write at some specific position in a 'sequence of block', you can start deciding how you'll deal with metadatas like file name, access right, timestamps, etc.

some resource:
http://search.barnesandnoble.com/bookse ... 1558604979

some related threads:
FileSystems
'How do i create a filesystem'
Filesystem Loading/read in
FileSystem Design
Brainstorming: "What would you put in a FileSystem?"

Once you do get to point of needing a loader (after you've implemented your file system), try looking into the book Linkers and Loaders by John Levine. It gives a detailed explanation of the loading process, including issues of relocation, Position Independent Code, etc.