Cxbx-reloaded: Slim our executable by reserving 128 MB via other means

[PatrickvL]

In issue #202 Cxbx was brought back to one single executable.
This was possible by reserving the lowest 128 MB of address space using a placeholder variable.
(See https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/master/src/Common/ReservedMemory.h#L55)
This variable however, enlarges our executable by 128 MB, which is not desirable (although we could live with it if no other method is found).

For this issue however, research if it's possible to reserve the 0x0001000-0x08001000 address range occupied by emulated_memory_placeholder by other means, so that our executable can loose 128 MB of fat. Do this without breaking anything!

EDIT : One remark : If we would temporarily drop Chihiro-support, the 128 MB could be reduced to 64 MB halving the strain.

[LukeUsher]

The latest version of UPX reduces our executable size to ~500KB, however it breaks the allocation of our memory region at 0x10000.

I'm not sure if it's even possible but perhaps we can create a modified version that doesn't mess with the memory map?

[PatrickvL]

UPX post-processes an executable. If we were to go that way, I'd rather create our own post-build event tool that does two things:
1: insert an empty segment at virtual address 0x00010000 up to 0x08000000 - this takes only the storage needed for one extra segment (or we could already reserve a segment for this, that we could just update)
2: lower the compiled-in image base from 0x08000000 to 0x00010000.

The second step does require relocation information - I'm not all that fond of it, as it could lead to undeterministic addresses when Windows loads our executable image into memory.

So, all in all it would be better if we discover a method to reserve the lowest 128 MB of virtual memory without actually linking 128 MB into our executable.

[LukeUsher]

Hmm, yeah this is not going to work unless we can force a non text section to link first. I think MSVC's compiler doesn't support that.

[PatrickvL]

Perhaps we can use a pragma comment, as documented here : https://msdn.microsoft.com/en-us/library/7f0aews7(v=vs.140).aspx
and with that, specify a new section, like documented here : https://docs.microsoft.com/en-us/cpp/build/reference/section-specify-section-attributes

[PatrickvL]

Another option might be to link in a small piece of assembly that introduces a section at a specific address, like this :

    test_segment SEGMENT PUBLIC, COMMON, MEMORY, AT 0x00010000 FLAT READ, WRITE, EXECUTE ALIAS('.cxbx_seg')
        test_asm_segment_data DB 65536 DUP(? )
    test_segment ENDS

Edit : Inline assembly cannot be used for this, at that only allows opcodes, no data or other keywords.

[PatrickvL]

Status update : Using a #pragma directive, an empty section can be inserted, reserving just as much virtual address space as we want. However, I haven't found any way to move this section in front of the .text section and still get the executable to load; When the required modifications to the section table (including an update to ImageBase, EntryPoint and other RVA's which must move alongside), the executable is no longer "a valid win32 application", according to Windows.

[PatrickvL]

This issue can be closed as 'no longer relevant' if the following succeeds : https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/issues/769#issuecomment-343651310

[PatrickvL]

No longer relevant, now that PR #1872 has been merged!