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?
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
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
Quote from: dedndave on February 26, 2010, 03:20:50 PM
the IAT is essentially a list of relocatables
The Import Address Table is more of a linkage structure for external fixups.
-Clive
Quote from: clive on February 26, 2010, 03:30:06 PMThis 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?
Quote from: Sergiu Funieru on February 26, 2010, 03:53:38 PM
Quote from: clive on February 26, 2010, 03:30:06 PMThis 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.
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
Quote from: Sergiu Funieru on February 26, 2010, 03:53:38 PM
Quote from: clive on February 26, 2010, 03:30:06 PMThis 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
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
Quote from: clive on February 26, 2010, 04:24:02 PMThe 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.
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)
Quote from: BlackVortex on February 26, 2010, 05:31:42 PM
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
If MS linker doesn't use relocations on exes, noone should. Don't mud the waters with "probably"
Things are crystal clear.
Quote from: BlackVortex on February 26, 2010, 06:34:13 PM
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
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:
Yes, time to grab the wooden stakes..
Other areas of consideration are EXE files that export functionality, or are otherwise co-loaded into the same address space as another EXE (ie not the same logical address, but in the same task context).
This is why I used "probably" and "maybe", sure 99.99% of all applications will not need relocations, but there are some specific situations where it maybe important/appropriate. I thought about the 0.01% and then considered the number of people out of the populous who user assembler to write Win32 apps.
Finally consider that Microsoft changes what it is doing from time to time, what they do today is not what they did in 1993, and 2GB of memory may look like a pitiful amount in 2013. 64K should be enough for anyone, right?
-Clive
That's why I used quotation marks when I said "always"
2gbs is a pitiful amount today
Quote from: BlackVortex on February 26, 2010, 08:34:17 PM
2gbs is a pitiful amount today
But hopefully your applications are still smaller than that, kind of half imagining a bloated Microsoft "Hello World!" app starting at 2GB. Grab the stakes quickly...
-Clive
Funny enough I have actually found a use for leaving the OS loader to resolve conflicting DLL load addresses in a test piece recently. Its relatively easy to set up a random order to load DLLs with LoadLibrary()/GetProcAddress() so if they all default to the same load address the OS loader plops each DLL where it best fits n the order that the caller makes the calls.
Its a technique to dynamically alter the load address of various bits of code that an application uses to add a bit more misery to the life of people who want to perform in memory patching.
very sneaky, Hutch
Skilled mem patchers do everything dynamically. getting the base of a module is easy.
Dll rebasing is also happening all the time in normal operation. In my trainers, I never miss ...
A better approach would be to make important code parts relocatable (delta offset etc etc) and then you can decrypt-load them where you want, use memory page protection to hinder writing and as soon as it's finished executing, deallocate the page used. And check important APIs for software breakpoints. Also, you can use the exception handler trick to check for hardware breakpoints.
You will need the relocation information if you wish to load and run PEs from memory.
You will also need relocations in executables for ASLR (Address Space Layout Randomization)