OSDev.org

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

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

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!

trinopoty wrote: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.

mutex wrote: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:
This results in the attached .bin, quite large for something so small. (/OPT:NOREF result in second .bin ???) (Hex Editor)

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.

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.