&gt; A file that is given as input to the linker is called **Object File**. 
The linker produces an **Image file**, which in turn is used as input by the loader. 

A blurb from &quot;**Microsoft Portable Executable and Common Object File Format Specification**&quot;

&gt; **RVA (relative virtual address)**. In an image file, the address of an item
&gt; after it is loaded into memory, with
&gt; the base address of the image file
&gt; subtracted from it. The RVA of an item
&gt; almost always differs from its
&gt; position within the file on disk (file
&gt; pointer).
&gt; 
&gt; In an object file, an RVA is less
&gt; meaningful because memory locations
&gt; are not assigned. In this case, an RVA
&gt; would be an address within a section
&gt; (described later in this table), to
&gt; which a relocation is later applied
&gt; during linking. For simplicity, a
&gt; compiler should just set the first RVA
&gt; in each section to zero.
&gt; 
&gt; **VA (virtual address)**. Same as RVA, except that the base address of the
&gt; image file is not subtracted. The
&gt; address is called a “VA” because
&gt; Windows creates a distinct VA space
&gt; for each process, independent of
&gt; physical memory. For almost all
&gt; purposes, a VA should be considered
&gt; just an address. A VA is not as
&gt; predictable as an RVA because the
&gt; loader might not load the image at its
&gt; preferred location.

Even after reading this, I still don&#39;t get it. I&#39;ve lot of questions. Can any one explain it in a practical way. Please stick to terminology of `Object File` &amp; `Image File` as stated. 

All I know about addresses, is that 

 - Neither in the Object File nor in the Image File, we don&#39;t know the exact memory locations so, 
 - Assembler while generating Object File computes addresses relative to sections `.data` &amp; `.text` (for function names).
 - Linker taking multiple object files as input generates one Image file. While generating, it first merges all the sections of each object file and while merging it recomputes the address offsets again relative to each section. And, there is nothing like global offsets. 

If there is some thing wrong in what I know, please correct me.

**EDIT:**

After reading answer given Francis, I&#39;m clear about whats Physical Address, VA &amp; RVA and what are the relation between them. 

RVAs of all variables&amp;methods must be computed by the Linker during relocation. So, **(the value of RVA of a method/variable) == (its offset from the beginning of the file)**? must been true. But surprisingly, its not. Why so?

I checked this by using [PEView][1]  on `c:\WINDOWS\system32\kernel32.dll` and found that:

 1. RVA &amp; FileOffset are same till the beginning of Sections.(`.text` is the first section in this dll). 
 2. From the beginning of `.text` through `.data`,`.rsrc` till the last byte of last section (`.reloc`) RVA &amp; FileOffset are different. &amp; also the RVA of first byte of the first section is &quot;always&quot; being shown as `0x1000`
 3. Interesting thing is that bytes of each section are continuous in FileOffset. I mean another section begins at the next byte of a section&#39;s last byte. But if I see the same thing in RVA, these is a huge gap in between RVAs of last byte of a section and first byte of next section. 

My Guess:

 1. All, the bytes of data that were
    before the first (`.text` here)
    section are &quot;not&quot; actually loaded
    into VA space of the process, these
    bytes of data are just used to
    locate &amp; describe these sections.
    They can be called, &quot;meta section
    data&quot;. 
    
    Since they are not loaded into VA
    space of process. the usage of the
    term RVA is also meaningless this is
    the reason why `RVA == FileOffset` for these bytes.
 
 2. Since, 
    
     - RVA term is valid for only those bytes which will be actually loaded
    into the VA space. 
     - the bytes of `.text`, `.data`, `.rsrc`, `.reloc` are such bytes.
     - Instead of starting from RVA `0x00000` PEView software is starting
    it from `0x1000`.

 3. I cannot understand why the 3rd observation. I cannot explain.

  [1]: http://www.magma.ca/~wjr/PEview.zip

All Portable Executable Solutions on Gang of Coders

Total of 1 Portable Executable Solutions

VA (Virtual Address) & RVA (Relative Virtual Address)