Page 1 of 2

writing kernel in VS 2005

Posted: Fri Nov 07, 2008 8:19 pm
by Sam111
I have finally got all the error's out of my kernel.
It compiles in Visual Studio 2005.

How can I linking all these obj to a bin file with in VS2005.

Like make it into kernel.bin the final output.

In the compiler/linker settings of the project you can set it to compile as .exe ,.dll,.lib, make , or utility and I don't see anything in the linker setting's for it?

When I am on my linux machine I use the elf or aout format which produces .o object files.
Then I use a linker script

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
phys = 0x00100000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}


And issue
ld -T link.ld -o kernel.bin start.o main.o scrn.o gdt.o idt.o isrs.o irq.o .....etc etc.

I want to do the equivalent thru an IDE particularly vs2005.
I don't really under stand linker script's fully yet myself.

The many problem is I want the raw machine code (.bin) not the header and machine code (.exe) when I link I get these error's

Code: Select all

unresolved external symbol _irq6
I have _irq6 .. etc int an .asm file I don't think .asm files can be compiled in VS2005 ???

#-o #-o #-o #-o #-o

Re: writing kernel in VS 2005

Posted: Fri Nov 07, 2008 9:40 pm
by Troy Martin
You need to separately assemble the .asm files in something like NASM and then link them in appropriately.

Not sure about this, but you might have some luck with adding "extern"s in spots.

Re: writing kernel in VS 2005

Posted: Fri Nov 07, 2008 9:52 pm
by Sam111
Yes I can use nasm -f obj mystart.asm

But then is their away after I do that to link them using the microsoft link linker from with in
the IDE.
I am also unsure when using both nasm and microsoft's link what format I should use.
Should it be -f obj or -f coff.

Code: Select all

C:\Program Files\Microsoft Visual Studio 8\VC>link
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation.  All rights reserved.

 usage: LINK [options] [files] [@commandfile]

   options:

      /ALIGN:#
      /ALLOWBIND[:NO]
      /ALLOWISOLATION[:NO]
      /ASSEMBLYDEBUG[:DISABLE]
      /ASSEMBLYLINKRESOURCE:filename
      /ASSEMBLYMODULE:filename
      /ASSEMBLYRESOURCE:filename[,[name][,PRIVATE]]
      /BASE:{address[,size]|@filename,key}
      /CLRIMAGETYPE:{IJW|PURE|SAFE}
      /CLRSUPPORTLASTERROR[:{NO|SYSTEMDLL}]
      /CLRTHREADATTRIBUTE:{STA|MTA|NONE}
      /CLRUNMANAGEDCODECHECK[:NO]
      /DEBUG
      /DEF:filename
      /DEFAULTLIB:library
      /DELAY:{NOBIND|UNLOAD}
      /DELAYLOAD:dll
      /DELAYSIGN[:NO]
      /DLL
      /DRIVER[:{UPONLY|WDM}]
(press <return> to continue)
      /ENTRY:symbol
      /ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
      /EXPORT:symbol
      /FIXED[:NO]
      /FORCE[:{MULTIPLE|UNRESOLVED}]
      /FUNCTIONPADMIN[:size]
      /HEAP:reserve[,commit]
      /IDLOUT:filename
      /IGNOREIDL
      /IMPLIB:filename
      /INCLUDE:symbol
      /INCREMENTAL[:NO]
      /KEYCONTAINER:name
      /KEYFILE:filename
      /LARGEADDRESSAWARE[:NO]
      /LIBPATH:dir
      /LTCG[:{NOSTATUS|PGINSTRUMENT|PGOPTIMIZE|PGUPDATE|STATUS}]
      /MACHINE:{ARM|EBC|IA64|MIPS|MIPS16|MIPSFPU|MIPSFPU16|
                SH4|THUMB|X64|X86}
      /MANIFEST[:NO]
      /MANIFESTDEPENDENCY:manifest dependency
      /MANIFESTFILE:filename
      /MAP[:filename]
      /MAPINFO:{EXPORTS}
(press <return> to continue)
      /MERGE:from=to
      /MIDL:@commandfile
      /NOASSEMBLY
      /NODEFAULTLIB[:library]
      /NOENTRY
      /NOLOGO
      /NXCOMPAT[:NO]
      /OPT:{ICF[=iterations]|NOICF|NOREF|NOWIN98|REF|WIN98}
      /ORDER:@filename
      /OUT:filename
      /PDB:filename
      /PDBSTRIPPED:filename
      /PGD:filename
      /PROFILE
      /RELEASE
      /SAFESEH[:NO]
      /SECTION:name,[[!]{DEKPRSW}][,ALIGN=#]
      /STACK:reserve[,commit]
      /STUB:filename
      /SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER|
                  EFI_ROM|EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS|
                  WINDOWSCE}[,#[.##]]
      /SWAPRUN:{CD|NET}
      /TLBID:#
(press <return> to continue)
      /TLBOUT:filename
      /TSAWARE[:NO]
      /VERBOSE[:{ICF|LIB|REF|SAFESEH}]
      /VERSION:#[.#]
      /WINDOWSCE:{CONVERT|EMULATION}
      /WX[:NO]

That was command line but everything can probably be done thru the IDE once I get the switch's for the linker.
Wonder if you could issue nasm -f obj myasm.asm thru the IDE before linking.

Re: writing kernel in VS 2005

Posted: Fri Nov 07, 2008 10:48 pm
by Troy Martin
I suggest using obj.

Re: writing kernel in VS 2005

Posted: Sat Nov 08, 2008 11:54 am
by thooot
I don't think the microsoft linker can compile to a flat binary. You can try using some other linker though. Here is a list from the WIKI: http://wiki.osdev.org/Category:Linkers. I would try using JLoc since it was created to solve the problem you're having (note: I haven't used it myself).

Re: writing kernel in VS 2005

Posted: Sat Nov 08, 2008 3:42 pm
by Sam111
So VS 2005 cann't be used to write kernels in?

Can I use it to compile to obj and then use a different linker (other then microsofts link)

I have tlink but it bitches about coff/obj conversion stuff when linking it seems like it isn't reconizing the object format. Or maybe I am not using a correct switch ?

Code: Select all

Turbo Link  Version 7.1.30.1. Copyright (c) 1987, 1996 Borland International
Syntax: TLINK objfiles, exefile, mapfile, libfiles, deffile, resfiles
@xxxx indicates use response file xxxx
/x   No map                          /c  Case sensitive symbols
/m   Map including public names      /C  Case sensitive exports & imports
/M   Map with mangled public names   /ye Expanded memory swapping
/s   Map plus detailed segment map   /yx Extended memory swapping
/l   Map plus source line #s         /d  Warn if duplicate symbols in libraries
/i   Initialize all segments         /f  Inhibit optimizing far calls to near
/L   Specify library search paths    /Gx Goodies
/n   Ignore default libraries              n=discard Nonresident name table
/v   Full symbolic debug information       r=transfer Resident names to
/Tti Specify target & image type             nonresident names table
     t can be d = DOS (default)      /A=dd  Set segment alignment
              w = Windows            /R[mpekv]  Specify option to RLINK
              x = DPMI               /t  Create COM file (same as /Tdc)
     i can be e=EXE or d=DLL         /k  Suppress "No stack" warning msg
/3  Enable 32-bit processing         /Ox Optimizations
/o  Overlay switch                         c=chained fixups
/P[=dd]  Pack code segments                i=iterated data
/Vd.d Expected Windows version             a=minimum segment alignment
/j   Specify object search paths           r=minimum resource alignment
Can you create a bin file from tlink having all the obj files from VS2005?
I don't even know what switch allows me to compile to a bin.

I always used nasm -f bin ...etc for bootloaders but I don't know how to get obj files to
link to a bin format using a linker?

Re: writing kernel in VS 2005

Posted: Sat Nov 08, 2008 8:08 pm
by astrocrep
I use VS2005 (or 2008) for my developing...

I also have a CYGWIN Cross Compiler Setup.

My kernel has a SLN file for a VC++ project and everything looks good.
In the properties for the SLN, I changed the Build, Rebuild, and Clean commands to run .bat files that execute make in my CYGWIN enviornment.

Works perfectly, plus the VC++ ide works as expected too!

-Rich

Re: writing kernel in VS 2005

Posted: Sat Nov 08, 2008 9:33 pm
by neon
So VS 2005 cann't be used to write kernels in?
Of course it can :) Heck, my bootloader uses it (Native *.exe too ;) )

I dont know of any C or C++ compiler that outputs plain binary files. However, if you require a plain binary image, you might be able to output in obj format and strip the header information from it. (This can be done with GCCs or Cygwin's objcopy program, iirc) As well as setting the entry point to be the first in the program image (This can be set by VS's linker function order script). Keep in mind that I have never done this, but I believe it should work.

I am uncertain of what your design goals are so I cannot help you too much in deciding what you should do next.

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 3:48 am
by Sam111
I changed the Build, Rebuild, and Clean commands to run .bat files that execute make in my CYGWIN enviornment.
Ok but then really you are using another compiler and linker independent of the VS2005 IDE.


What I was wondering is if you could use VS2005 compiler to output the .obj's and then use it's linker to link it into a bin?

Or at least take the .obj files that microsofts compiler gave and use another linker to link to bin file?

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 4:32 am
by ru2aqare
Sam111 wrote:
I changed the Build, Rebuild, and Clean commands to run .bat files that execute make in my CYGWIN enviornment.
Ok but then really you are using another compiler and linker independent of the VS2005 IDE.


What I was wondering is if you could use VS2005 compiler to output the .obj's and then use it's linker to link it into a bin?

Or at least take the .obj files that microsofts compiler gave and use another linker to link to bin file?
Writing a kernel with VS2oo5 or VS2oo8 is possible, indeed. Even writing bootloaders is possible (I have one, for example). Generating flat binary files is not possible with the default MS linker. Since I have not yet found a method to replace the MS linker, I decided to write a custom linker which can output such files (replace the linker as in modify the MSBuild files to ignore the MS linker and invoke some other application instead). I created a little batch file that invokes my linker and specified it as a pre-link step. If you want to try my linker out, check this thread: linking 32/64 bit.

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 5:14 am
by Sam111
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?

Either way I don't know how to get my kernel to compile to a bin file with or without the IDE on a windows machine without using cywin...etc

I use nasm, yasm ,tasm alot for asm programs but now I am trying to write a kernel in c.
normal i just wrote the whole thing in asm and used nasm -f bin.
but now iwant to use c functions and i cann't make a bin file from things that have extern references. If i use .obj or coff .... i get header crap (i.e .exe) not the raw .bin file. And without a bin the kernel cann't exist. Does elf format give no headers when it links?

Even still I would be Ok if I could produce a .com since I think this is just a bin with .org 100h.
So all I would have to do is strip out the first 100h bytes and I would have a .bin

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 6:08 am
by rdos
Doesn't VS's linker add thousands of Windows DLL-imports (most which you don't want to include at all)? This was why I abandoned M$ tools 10 years ago. For each version, more useless imports were added without you ever using them. That's also why M$ tools cannot generate binaries. The Windows DLL-imports cannot be fixed in a binary image, because they are external and part of the Windows API.

It would certainly be possible to use the VS environment, but the libraries & linker must be replaced with something else.

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 6:10 am
by rdos
Sam111 wrote:Even still I would be Ok if I could produce a .com since I think this is just a bin with .org 100h.
So all I would have to do is strip out the first 100h bytes and I would have a .bin
Only if you want to live with 16-bit segments and a maximum size of 64k - 100h bytes. :D

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 6:18 am
by ru2aqare
Sam111 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?

Either way I don't know how to get my kernel to compile to a bin file with or without the IDE on a windows machine without using cywin...etc
Try my linker, which I mentioned previously. It can generate flat binary files, and it's mostly compatible with the MS linker.
rdos wrote:Doesn't VS's linker add thousands of Windows DLL-imports (most which you don't want to include at all)? This was why I abandoned M$ tools 10 years ago. For each version, more useless imports were added without you ever using them. That's also why M$ tools cannot generate binaries. The Windows DLL-imports cannot be fixed in a binary image, because they are external and part of the Windows API.

It would certainly be possible to use the VS environment, but the libraries & linker must be replaced with something else.
No, it doesn't if you don't use Windows-specific functions, and don't link in the C runtime library... Which you don't want anyway, since it's mostly Windows-specific, and cannot be used in kernel mode.

Actually, you can write Windows applications without using the C runtime library from MS. It's a bit difficult, but possible. For example, I once wrote a replacement for the runas command, which was about 4 kilobytes without the RTL.

Re: writing kernel in VS 2005

Posted: Sun Nov 09, 2008 7:28 am
by rdos
ru2aqare wrote: No, it doesn't if you don't use Windows-specific functions, and don't link in the C runtime library... Which you don't want anyway, since it's mostly Windows-specific, and cannot be used in kernel mode.
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.

Besides, BC 5.5 at least always needs to link the CRT0 module, which contains lots of Windows API specific stuff.

OTOH, we build 16-bit DOS applications only by changing the CRT0 module and providing memory allocation functions for our V25-based terminals, but this is not 32-bit code. I know this also worked with MSVC 1. The Win32 target is another thing altogether.