Well, I read about flat file format questions and answers. I, too trying for multi tasking/threaded kernel. Right now, scanning though docs and other stuff and using NASM for current developement.
My question is for what DJGPP developes is COFF format. When I get my kernel, to load this 32 bit COFF file, loaded won't that execute directly? If yes, then what is need of "flat format"?
Still am not working that end, so is this question, but will like to get my doubt cleared well in advance.
Thanks,
Regards,
Aditya.
Is Flat file format sufficient?
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Is Flat file format sufficient?
flat file format only comes with raw .code and .data bytes... nothing more. This means the linker and the loader must agree on the target address, the size, etc. Moreover, the file must be standalone (not rely on anything else).
You could imagine to provide just a small header to your flat file saying "this is a KERNel, with <size> bytes to be loaded and which expects to have at least <bss_size> bytes after it zeroed for its "uninitialized" datas ... and, btw, please jmp to <entry_point> when done.
(this is exactly what the Small File System header i used in Clicker is about
When you have more complicated things to do, like supporting the load to any location (mandatory when you start playing with modules, plugins and other shared libraries ...), it is mandatory to say "i wish to be loaded at 0x12345678. If this is not possible, please update the following list of addresses in my code." (relocations), and also stuffes like "linker speaking: the symbol 'OpenFile' hasn't been found .. i expect it to be in library files.lib, please load that library with the program and update the following list of addresses with that symbol's address" (link importations).
Finally, if your file wants to be callable from outside, it will need something like "Hey, tell the other components that 'HelloWorld' is a function available at offset +200 from my text section" (link exportations)
Hope this clarifies the stuffes.
You could imagine to provide just a small header to your flat file saying "this is a KERNel, with <size> bytes to be loaded and which expects to have at least <bss_size> bytes after it zeroed for its "uninitialized" datas ... and, btw, please jmp to <entry_point> when done.
(this is exactly what the Small File System header i used in Clicker is about
When you have more complicated things to do, like supporting the load to any location (mandatory when you start playing with modules, plugins and other shared libraries ...), it is mandatory to say "i wish to be loaded at 0x12345678. If this is not possible, please update the following list of addresses in my code." (relocations), and also stuffes like "linker speaking: the symbol 'OpenFile' hasn't been found .. i expect it to be in library files.lib, please load that library with the program and update the following list of addresses with that symbol's address" (link importations).
Finally, if your file wants to be callable from outside, it will need something like "Hey, tell the other components that 'HelloWorld' is a function available at offset +200 from my text section" (link exportations)
Hope this clarifies the stuffes.