Hi Tomasz,

I've moved this topic into it's own thread, because I don't want to pollute the Planned file format tutorials topic. Hope you don't mind. Thank you for your answer! I've read the link you sent me, and it is very interesting. It describes a different PE+ than the official docs, for example here. The latter explicitly states address size is not changed, and indeed the table in the doc has only 4 bytes sizes, offsets and addresses. Later there's a reference to an 'ImageBase' field which is expanded, but linking to higher half I got 32 bit address in it (*). Also there's absolutely nothing about the expansion of 'AddressOfEntryPoint', but that supposed to be an offset instead of and address in the first place, isn't that right? But for higher half kernel I got the truncated address there (*). If PE+ is as you say (and I think you've tested your code, so I'm willing to believe) that means there's definitely a bug in the GNU toolchain.

(*) I've used gcc and cross-binutils under Linux to generate, dump and check my PE+ files. I don't have Win, so I could test my boot loader with GNU toolchain generated PEs only, that's why this topic is so interesting to me. If anybody would be kind to compile this little C code under Win in PE32+ format for me, and send the binary back for further investigation and comparision, that would really made my day!

Thanks,
bzt

The capabilities of the format are one thing, and limitations of specific implementation another.

AFAIK, Windows is not able to load PE+ image at high base (above 4G), so if PE+ specifies a large 64-bit default base, Windows has to relocate it.

Nevertheless, the relocations in such case are processed correctly. Instruction like "mov eax,$" can contain a large 64-bit value in an image file and upon loading by Windows be fixed to contain a correct 32-bit address (corresponding to where Windows actually ends up loading the image).

Thanks for the answer!

So it seems I'm walking on thin ice here. I'm sure there are people writing higher half kernels in PE+ format, so it have to be possible to do so. Even though it's not supported by standard toolchains and Win won't load it at higher half normally (that's understandable, you should never load a kernel with Windows anyway).

I'm just guessing at this point, because I mostly use ELF, I know that format much better. Also I've used the GNU toolchain to create the test PE+ files for my loader, which introduced another possible source of error. But according what you've said, it seems you'll need that manual sign extension for PE+ kernels if you map them in higher half. Thanks! Good to know!

bzt