how does @code work?

when i write a simple program which contains the line

mov ax,@code

the line compiles to

B80000

in the executable, which is the same as

mov ax,0

yet when i open a debugger and look at the decompiled code at runtime, i find that the B80000 is replaced with

B8120E

which is the same as mov ax,0E12, which is the value in the cs register.

this completely mystifies me. how does the processor or dos or whatever makes the change know to change the 0000 to the value stored in the cs register? Is it stored in the executable's header or something?

Thanks!
-Lolth
Posted on 2002-01-17 11:31:42 by LOLTH
Modern executable formats allow relocation of code to an arbitrary place in memory, and for this to take place a list of offsets are kept in the executable for the loader to 'fix-up' addresses within the executable. That is how you can code:
pArray: dd OFFSET pArray
...at run-time there is no telling where this varible will be located and hence on way to tell what address to put into the dword. To solve this problem the dword is 'fixed' by the loader. Before this abstraction code ran only at one location in memory.
Posted on 2002-01-17 11:50:39 by bitRAKE
Thanks, thats really neat!
i found the place in the executable header where the offsets to the places that need fixing up are stored. They are stored as 32-bit offsets, explaining why a .exe can be greater than 2^16 bytes long. Since the header is only 512 bytes long, i thought that i might be able to create an error by having more than 120 commands that needed to be fixed up, but those clever microsoft guys programmed MASM so that the header just added another 512 bytes of space onto the end to store the extra offsets. Pretty neat.
Posted on 2002-01-17 12:55:16 by LOLTH