Why do I need the relocation information inside the exe file?

[Sergiu FUNIERU]

From the WLink manual:
The "NORELOCS" option specifies that no relocation information is to be written to the executable file. When the "NORELOCS" option is specified, the executable file can only be run in protected mode and will not run in real mode.

What's the problem if the exe will run only in protected mode? When I run a program under Windows 2000 or newer, do I use the real mode? If not, why do I need at all to save relocation information inside the exe file?

[dedndave]

you shouldn't need that option for flat model programs
but, the IAT is essentially a list of relocatables
it sounds like that option may be more meaningful for 16-bit code - i dunno

[clive]

You need relocation/fixups when the code shares a common address space with other components, and it's load address cannot be guaranteed. For example DLLs or device drivers. Even in protected mode, things that run within the same task share a common view of memory.

Removing relocations from an EXE makes the assumption about the environment in which it will run. This might be Ok in WinNT, it might be a problem if you are loading using a DOS extender, or an embedded platform using the PE file structure as a convenient container. The latter is often done to use off the shelf tools, which are typically cheaper and better supported. A lot of DOS extenders, and a PenOS, use OS/2 linear formats in this fashion.

-Clive

[clive]

the IAT is essentially a list of relocatables

The Import Address Table is more of a linkage structure for external fixups.

-Clive

[Sergiu FUNIERU]

This might be Ok in WinNT

It might or it will? That is, if I plan to develop only for Win 2000 or newer, it will be okay to remove the relocation information?

Is there any real advantage in removing that information in this case?

[japheth]

This might be Ok in WinNT

It might or it will? That is, if I plan to develop only for Win 2000 or newer, it will be okay to remove the relocation information?

Is there any real advantage in removing that information in this case?

For Windows the rule is: you can safely remove this info if your binary is an application, and you should not remove it if your binary is a dll.

[clive]

Depending on how far you go back Microsoft's LINK used to leave relocations in all files, at some point they stopped for EXE files. As indicated above DLL's and device drivers really do need relocations. Provided that the BASE address you link at matches that used by Microsoft you can safely remove the relocations. If you remove the relocations you will not be able to REBASE the file. Without the relocations someone examining the file will not be able to make automatic conclusions about if an arbitrary constant is just an immediate, and not an address reference.

Having the relocations adds a small burden in terms of file size, the loader will *only* use them if the load address *differs* from the BASE at which the file was linked at. Microsoft loads EXEs at 0x400000, the first section of a file typically loads at 0x401000 so the PE header can reside at 0x400000.

If you have multiple DLL's of your own you can define different base addresses so that they can load directly without causing the loader to fixup the addresses.

I'm sure there are plenty of books on this topic area.

-Clive

[clive]

This might be Ok in WinNT

It might or it will?

Depends on how/where it is run. I don't recall if NTLDR needs them for running code in the Native environment, ie pre-boot/pre-gui, for example AUTOCHK.EXE, but I suspect that it might.

-Clive

[clive]

Spiders can move with six legs, but it doesn't mean I want to cut off the others. The PE format has relocations to permit flexibility in its application, you can diminish that flexibility but it will limit the places the code can be used. Earlier you were asking about cross platform support, consider WinME, Wine, or ReactOS.

-Clive

[Sergiu FUNIERU]

The PE format has relocations to permit flexibility in its application, you can diminish that flexibility but it will limit the places the code can be used. Earlier you were asking about cross platform support, consider WinME, Wine, or ReactOS.

In a way, I thought that the relocation information is like the debugging information - it can be removed from the final exe file. I can use different settings for release and for debug.

[BlackVortex]

Relocation information is information about relocation  :dazzled:

Executable files "always" start at address 0x400000h , so no relocation is needed. Libraries (dlls) are relocated all the time, so reloc info is needed. Fixups are applied to all registered addresses (I'm oversimplifying probably)

[clive]

Executable files "always" start at address 0x400000h

Except where they don't, or course<G> For user space EXE it is probably safe (ie Microsoft does) to assume this and discard the relocations. I'm not sure it's a huge win to remove them, most address dependencies are self-relative, the ones in a PE file are inter-section references.

Typically Microsoft will try to reuse an existing instantiation of a DLL and map it into the new task at it's current address, it will however relocate (rebase) a new copy in if there is a clash in the address spaces.

-Clive

[BlackVortex]

If MS linker doesn't use relocations on exes, noone should.  Don't mud the waters with "probably"

Things are crystal clear.

[clive]

Things are crystal clear.

I will again cite Native applications, and specifically AUTOCHK.EXE as an example, where in fact the crystal is foggy.

-Clive

[BlackVortex]

What's that weird executable ? It's like some weird hybrid, I guess because it runs before windows is fully loaded ?

Some crossbreeding between exe and dll and subsystem=native

Also, on my OS it's x64 PE, but when I run it, it says "cannot be run in win32 mode"
What the ... ?

Burn the abomination !   :cheekygreen: