OSDev.org

rdos wrote:I always link the C runtime library (with BC 5.5), and it includes a whole set of Windows API functions, even if I set target to Win32 console and don't use any Windows API function explicitly. I haven't tried with more recent versions of M$ compilers, but with MSVC 6 (or something like that), it brought in lots of Windows API functions, many more than BC 5.5 did. Either you have written extremely simple code, or VS has been improved.

As I said previously, the solution is not to link in the C run-time library. MSVC as a compiler does not generate Windows-specific code (there are examples of replacing specific for loops with calls to memcpy, but that's another issue). It's just a compiler.

However, I don't use Visual Studio 6 (and have never use the Borland C compiler). After having using VS 2oo5 for years, VS6 was a pain to code in, when I had to use it on one occasion.

I agree you can write the kernel code in the VS2005 IDE. But you could never compile the .c files to obj files and link them into a bin file with another linker?

I never needed to as I just use the output *.exe program for my kernel and OSLoader (bootloader)

Doesn't VS's linker add thousands of Windows DLL-imports (most which you don't want to include at all)?

No. Just have your project not inherit from anything (Put $(NOINHERIT) in additional dependencies) and as ru2aqare said, simply dont link the CRT. With this, all extra dependencies are gone.

Only if you want to live with 16-bit segments and a maximum size of 64k - 100h bytes.

Ya , I realized my stupidity about com.

But I cann't seem to find a way to use c/c++ functions in my os.
If I use c functions they are going to be extern to the asm file.

And bin does not support extern -f bin.
So then what do I compile them to obj , coff , elf ,...what?
And after I have the object file how can I link them to a bin file.

Is linux os the only ones that have the power to do it.
They have gcc , ld ,...etc
I have just nasm , tasm , yasm , (link , cl and anything else that comes with the VS2005)

I have looked on the wiki for compilers/linker but their is not many that will do bin
at least for microsoft with out installing cygwin.

Could I download Dev C++ and use the IDE to compile to a .obj and link to a bin?

I just don't know how to do it.

Another thing somebody said VS2005 adds alot of extra library stuff and RTL but I think their is a switch or in the project properties compiler/linker settings to turn this all off so you don't have any RTL.... etc
I used an empty project and turned everything off these things.
If I can't use VS2005 to compile and link then is their another IDE that I could use.
I just find coding quicker in c then always doing all my functions in asm.
So I want to try putting c/c++ function into my kernel.

How on a windows machine. Would Dev C++ be a better enviorment to use?

Technically, any capable IDE will do. The trick is to get it to build what you want. In most cases that means having it execute a custom build script rather than using the built-in compiler commands (since that creates a binary for the running OS rather than your own).

But it seems that your problem is more fundamental in that you don't know how the linking process normally works, and therefore, where you should try manipulating it. Look at some tutorials and then explain to us how you think it should work.

neon wrote:

I agree you can write the kernel code in the VS2005 IDE. But you could never compile the .c files to obj files and link them into a bin file with another linker?

I never needed to as I just use the output *.exe program for my kernel and OSLoader (bootloader)

Doesn't VS's linker add thousands of Windows DLL-imports (most which you don't want to include at all)?

No. Just have your project not inherit from anything (Put $(NOINHERIT) in additional dependencies) and as ru2aqare said, simply dont link the CRT. With this, all extra dependencies are gone.

OK, I guess you are right. I haven't approached this problem from the standpoint of compiling a C/C++ based kernel, as I use assembler, but as a means to create usermode applications for my OS. In this context, I need to link the CRT, and every included Windows API function in the Win32 console app means I need to code some dummy of the function. That's why I choose Borland over M$. M$ simply included so much more garbage than Borland did. Although, the main issue actually was to support all the garbage that the debugger included. Codeview seemed totally impossible to support, while I succeeded with TD/TD32, at least mostly, as the current support cannot handle threads properly because Borland didn't believe that the DosExtender invocation of TD32 could have threads.