OSDev.org

I tried to use C to code my kernel severel times somehow it didn't worked until now(I used MinGW which is probably the reason for the chrashes).
I would prefer MSVC++ 2005 anyhow. So is there any tutorial which describes how to link your code you produced with MSVC++?
I just search for a working Hello World Tutorial.

P.S.: I'm not in hurry. In the meantime I could try the other tutorials by using another compiler, which works better.

You are herewith found guilty of not having checked the forum sticky thread prominently named "Quick Links - read this before you post", which would have pointed you to the FAQ, which in turns contains a page on Visual C and a BareBones tutorial using a GCC Cross-Compiler.

Your penance will be to follow the aforementioned links.

I've seen docs floating around in osdev circles talking about building a cross-compiler but I've never seen any real reason to have to make one at this stage of OS development. Can someone explain why MiniGW/DJGPP/GCC won't work as installed? I've never come across a derivative of gcc that didn't support x86 and binary output.

The reason why I had to build a cross compiler (2 years ago now) is that I'm using Cygwin for OSdev, and the gcc that comes with Cygwin produces Win32 PE's by default. I wanted something that would emit ELF, not PE.

There are other more philosophical reasons as well, but I'll let our resident philosophers get into those.

1) It brings developers working under Windows (MingW / Cygwin / DJGPP) and Linux to an equal footing. Without a cross-compiler, the BareBones tutorial (for example) would have to come with a dedicated "Windows" chapter to teach you about how to force your toolchain into generating ELF binaries, avoiding alloca() references etc.. Questions about alloca() and "PE operations on non-PE files" have been numerous on this board a couple of years ago, and Linux users couldn't even reproduce the problems, let alone test their solutions before posting them. The cross-compiler tutorial effectively solved this.

2) If you want to specifically target a certain hardware - for example, i586 or i686 - your system compiler might not support that, and generate binaries for later platforms that won't run on older systems. Moreover, you are not as free to update / downgrade your system compiler to a specific version as you are in changing your cross-compiler version, especially under Linux and during the 2.95->3.3 transition during which that tutorial was written and established (GCC repeatedly broke its own ABI, so carelessly updating your system compiler could break your installation).

2b) Under certain Linux distros, your system compiler is compiled with native language support, resulting in error messages that are in German, Dutch, French, Spanish... which might be fine for you, but doesn't help the people on this board, and when you try to google for your problem, your chances are better with a toolchain that speaks English. (Thus, the cross-compiler tutorial encourages you to --disable-nls.)

3) It is the first step towards self-hosted development. Sooner or later you will do this step anyway, so why not right at the beginning?

4) A cross-compiler setup will scream bloody murder when you're doing stupid stuff like [tt]#include <stdio.h>[/tt], while your system compiler will silently drag in libraries that won't work in your kernel, leaving you clueless. You might not believe it, but that has been a recurring problem a couple of years ago on this board.

Each in itself not a too-strong reason for a cross-compiler, and of course you can make MingW / Cygwin / DJGPP / your Linux system compiler into doing what you want. But that will be your solution, people on this board will have problems recreating your solution and / or problem, and when you ask about alloca(), PE operations on non-PE files, or why printf() doesn't work, we'll point you back to the cross-compiler tutorial.

I've never come across a derivative of gcc that didn't support x86 and binary output.

True only for GCC's running on x86 systems. I wouldn't be so sure about the GCC running on PowerMacs, for example...