When I type ld -t link.ld -o kernel.bin ks.o kernel.o it gives me this: ks.o: File not recognized: File format not recognized. I'm using GCC, NASM and LD within CodeBlocks. Help me.

Moving to High Level Languages. Doesn't seem to be related to fasm or assembly.

Hi,
You need to use a cross-compiler. The one you download for Windows/Unix will produce executables for Windows/Unix which will ccompile PE32/PE64/ELF32/ELF64 along with Windows/Unix libraries. From your posts you seem to be developing an operating system, remember that at the OS level there is no such libraries/runtime/framework or whatever the only thing below you is the firmware, SMM (System Management Mode) there is one thing to note that even if the OS is running the SMM code will still run, it handles things like PS/2 Emulation etc. more on that later. You need to use a cross-compiler i.e. a compiler that runs on a specific platform but emits binaries for another platform. I would recommend i586 or i686. You can view the instructions on building a cross compiler here: http://wiki.osdev.org/GCC_Cross-Compiler
(It's assumed that you're on a Unix-like platform if not use Cygwin under Windows). As for using an IDE like CodeBlocks I am doubtful about that, I guess that you would need some experience with the command line,
However you may wish to edit the sources in the IDE.
-sid123

I tried doing that, it failed.

What message do you get?
If you can't even make a cross compiler, give up system programming </flamebait>

When I type ld -t link.ld -o kernel.bin ks.o kernel.o it gives me this: ks.o: File not recognized: File format not recognized.

I was using MinGW and Cygwin, they both failed. *facepalm*

What the ...? BUILD A CROSS COMPILER! And then compile your code with a cross compiler!

sid123: Somehow I think you are using the term "cross-assembler" in a way that is not the normal usage. Usually a cross-assembler assembles for a different CPU architecture and has nothing to do with the OS being used.

@revolution Ah, I see what you mean there maybe I should've made the meaning of platform more clear, by platform I meant the OS, not the architecture. Or Did I misunderstand your point?

I used all instructions from OSDev Wiki. Now I get this: kernel.o:kernel.c:(.text+0x16): undefined reference to `_outb'
kernel.o:kernel.c:(.text+0x2a): undefined reference to `_outb'
kernel.o:kernel.c:(.text+0x3d): undefined reference to `_outb'
kernel.o:kernel.c:(.text+0x50): undefined reference to `_outb'
kernel.o:kernel.c:(.text+0x64): undefined reference to `_outb'
kernel.o:kernel.c:(.text+0x78): more undefined references to `_outb' follow
kernel.o:kernel.c:(.text+0xf7): undefined reference to `_k_printf'
c:/djgpp/bin/ld.exe: kernel.bin(.eh_frame): relocation ".text+0x140 (type DISP32
)" goes out of range
c:/djgpp/bin/ld.exe: final link failed: Invalid operation.
Now I'm using DJGPP, other problems fixed.

This shows that you have NULL experience in C, and you're attempting to write a kernel.
They mean that, those functions are not being found when you're linking your kernel, you haven't written them and are trying to access or reference them.
And ALWAYS use a cross compiler! Will save you a lot of trouble. I recommend reading
some simple books that teach you about C, I myself learnt C from the book 'The C programming Language' by Dennis M Ritchie.

Thanks, I'm reading that on my tablet.

As this is a link stage error, I'm going to assume the compiler set up is correct and did something to produce the .o files. Those errors can still occur for a number of reasons:

- You have defined the function but not declared the function either in C (extern) or ASM (extrn/public[+as]) where it is used/defined
- You have have conflicting declarations due to architecture/call convention or type encoding e.g. cdecl might be '_outb' but fastcall might be 'outb' OR you have different architectures being linked [16/32/64]
- Missing C libraries (to be honest I never use ld directly and get gcc to do it for me but you might need add the C standard libraries for the printf reference or try gcc to see if helps)

I programmed the PIC, that's why it gives me this error.

But it won't help me. I made a cross-compiler but in the making it gives errors.

What error?
Programming the PICs are a crucial step for IRQs to work. If you can't get them working, you would never be able to write a keyboard or a floppy driver.

The same one. I think of trying, I watched a tutorial on Cygwin, it didn't work.

I use a virtual machine running Windows XP and I need tutorials on the cross-compiler for WINDOWS.

If you can post source code, command lines and compiler/OS details, it would be easier to work out the problem.