Visual C++ IDE Kernel Development - Flat Binary

[bluemoon]

You can convert the format with objcopy, which comes with the gcc.

[trinopoty]

Listen carefully to what I say. I use VC++ IDE for all OS development.
You will need external tools to produce flat binaries. Either, use a complete external tool-chain, GCC and Binutils.
Or, use the Microsoft compiler, instruct the IDE to skip link process and add a Post-Build event that will invoke Binutils linker.
The latter option is neater if you are used to MSVC syntax.

Regards,
Trinopoty

[mutex]

Visual C++ ide + MS compiler does everything you want if you are a little pragmatic and take advantage of the options the linker gives.

I'm not sure what the motivation of "flat" binary is. Compile to a PE-exe without relocations and just think of it as a flat binary with some additional data in the begining (and the end). You will have a completly "flat" code, data and bss section in the file that is 100% continous if you configure the linker correctly. See "section alignment" in the microsoft linker.

You can even write yourself a tool that takes the output EXE and stripping the PE/EXE headers outputing a "flat" object file.

I myself use mingw compiler collection and use both PE and ELF for my os. Gcc-mingw gives you the best of both worlds, and you can use it on Windows, MacOs, Linux..

Good luck and happy new year!

[OdinVex]

Or, use the Microsoft compiler, instruct the IDE to skip link process and add a Post-Build event that will invoke binutils linker.
The latter option is neater if you are used to MSVC syntax.

You can even write yourself a tool that takes the output EXE and stripping the PE/EXE headers outputing a "flat" object file. I myself use mingw compiler collection and use both PE and ELF for my os. Gcc-mingw gives you the best of both worlds, and you can use it on Windows, MacOs, Linux..Good luck and happy new year!

Well I followed the OSDev tutorial for producing DLLs, and yeah I can compile etc (of course if I turn on /OPT:NOREF, there is no code (but there is data section!?)) but I might consider sticking to ASM with NASM because x64 compilers in Visual C++ don't allow inline ASM anymore. Compilation in Linux is...a mess. I really would prefer to stay away from Linux tools, even if they're ported...cross-compiles typically bring baggage and dependencies in my experiences. Maybe I'm just biased. I thought about stripping PE headers and the DOS stub, splitting my code and data section up and just allocating a kernel code and data section but I've no idea how addresses etc would be 'converted' to flat unless binutils would do that. I've been writing a side-project modem firmware in Linux, specifically ARM, and it is just a giant mess to build the toolchain, even compile half the time. Well that might be due to the toolchain's dependencies being 2007-2009 and 99% of those tools had to be fetched manually and compiled to specific dirs, vendor suppositories wouldn't carry them. I'm not trying to come off ignorant or just dickish, I just don't want to be one of those wasting 80% of development time on trying to compile and deploy a solution. :/ All been there before in some way right? Think I should just write something to strip the PE header, stub etc and just go back to back padded to 512-byte aligned sections (code then data)? How would I reach my data? X_x; I'm not the most familiar with linkers with this depth.

*Edit* I did try to /merge:.rdata=.text and that didn't work, silently succeeds build but eh. A simple hello world builds but eh:

Code: Select all

#include "HelloWorld.h"

int main() //Ignore int, visual studio complains
{
	char *string = "Hello World!", *ch;
	unsigned short *vidmem = (unsigned short *) 0xB8000;
	int i;

	for(ch = string, i = 0; *ch; ch++, i++)
		vidmem[i] = (unsigned char) *ch | 0x0700;
	return 0; //Ignore, visual studio complains no return
}

This results in the attached .bin, quite large for something so small. (/OPT:NOREF result in second .bin ???) (Hex Editor)

[mutex]

This post will get you up and running. It will make a fully blown PE-exe file, but that does not really matter. Grub will be perfectly able to boot ut.

With this you can focus on the programming and not the boilerplate, though i suggest looking into that as well since writing an OS pretty much requires you to understand alot of lowlevel stuff.

[OdinVex]

Interesting, I'm reading it through and I'll test tonight, although I'm not exactly a Grub fan. Too much bulk, but necessary being what it is.

*Edit* Just occurred to me, unique filesystem. I'd have to write a driver, sigh.