OSDev.org

I'm creating a new OS in visual studio 2013 it boot from grub using stage2_eltorito, and since I'm using vs2013 have not how to use the variable end ld script, then how do you know the size of my kernel.

Visual Studio + ld? Either I don't understand the question or you're doing something odd or both.

What format is the executable that you are producing?

Good though Visual Studio is, I have to say that it is not the ideal platform to produce an OS that will boot using Grub. (You can do it, but you need to understand your toolset thoroughly and you are making life more difficult for yourself than is necessary.)

If you are using Visual Studio 2013 to compile your OS, then you don't need to use LD at all.

However, you may just want to use VS2013 as an editor. In this case, you can just save your files, and then run gcc and ld from a command window. In this scenario, you would use ld just like you would for any other program.

If you still have questions, then tell us which approach above that you are using, and we can help you from there.

I am creating a binary PE editing, compiling and linking with vs2013, however using the IDE can not create a variable "end" stating where is located the end of the kernel. So how am I going to know the kernel size?

I'm using google translator.
So sorry if the message does not make sense.

I'm not sure how you would get the size of your kernel, but I'm also not sure why you would need it.

The PE file (kernel.exe?) that Visual Studio creates during the build has all of that information in it, and the boot loader will have to read the PE file and put the executable bytes where they belong in memory.

Why do you need to know the kernel size?

SpyderTL wrote: Why do you need to know the kernel size?

There are several reasons.

The reason to know the kernel size is to implement paging.

Already decided and only two code lines.

Hello,

I never quite understood the logic behind this. Is the goal to obtain the size of the text or text and data segments? Do you want to include post-load time alignment and .bss? Why do you assume the base address of the kernel image in memory when it could have been relocated?

The better alternative to resulting to compiler specific hacks is to perform the check itself during run time in the first phase initialization prior to the memory manager services being started. This can be done by determining the image base address on a 4K boundary, and parsing your image header structures in memory for proper section alignment, sizes, and locations relative to the relocation. This solution can be adopted as needed for any image format and does not yield to compiler specific hacks and will work for any case.

If the goal is for use with paging, you should calculate the section locations and sizes as needed to properly page them as kernel segments and apply the necessary attributes on those specific pages once mapped. It is also important to allocate some methods and data structures in separate sections that can be paged out later or for one time routines that can be paged out after initialization.