Edit: I stand corrected, I just checked the msvcp100.dll and there you can find both - "offset somefunc" and "rva somefunc", so this case isn't mentioned in the quote below. Did not know that.
Okay so if I understood you correctly, there's two possibilites for values you find in the EAT. Either it's an address to code, or an address to a pointer.
Now I may be wrong but neither should be the case (before being mapped, I guess the loader modifies the EAT just like the IAT?).
From the following link I got this:
http://msdn.microsoft.com/en-us/magazine/cc301808.aspx
A particularly slick feature of exports is the ability to "forward" an export to another DLL. For example, in Windows NT®, Windows® 2000, and Windows XP, the KERNEL32 HeapAlloc function is forwarded to the RtlAllocHeap function exported by NTDLL. Forwarding is performed at link time by a special syntax in the EXPORTS section of the .DEF file. Using HeapAlloc as an example, KERNEL32's DEF file would contain:
EXPORTS
•••
HeapAlloc = NTDLL.RtlAllocHeap
How can you tell if a function is forwarded rather than exported normally? It's somewhat tricky. Normally, the EAT contains the RVA of the exported symbol. However, if the function's RVA is inside the exports section (as given by the VirtualAddress and Size fields in the DataDirectory), the symbol is forwarded.
When a symbol is forwarded, its RVA obviously can't be a code or data address in the current module. Instead, the RVA points to an ASCII string of the DLL and symbol name to which it is forwarded. In the prior example, it would be NTDLL.RtlAllocHeap.
I just checked some msvcr71.dll for example. I don't see "offset xyz" in the EAT, I see "rva strlen" in the EAT. So I guess what your screenshots shows are forwarded exports, not actual exports for that file. In that case you can just use the logic described in my quote.