So while the EXEs of most x86 OS:es including Windows appear very different from .COMs or OBJs they are still actually x86 machinecode (despite beeing called portable in the case of windows) if you exclude header information?
Does Windows replace any part of the EXEs contents when it's loaded into memory (such as memory addresses) with current conditions (where the app is loaded, where DLLs are loaded)?
Yes.Originally Posted by willkoh
Yes the import table is filled with addresses of imported functions.Does Windows replace any part of the EXEs contents when it's loaded into memory (such as memory addresses) with current conditions (where the app is loaded, where DLLs are loaded)?
...retrieved from the import libraries, right? But if these explain only where within the DLL-file the function entry points are, will windows replace the call-to-addresses in the ram-stored copy of our EXE with DLL_NowLoadedAtMemoryAdr + FunctionEntryPoint?
(assuming windows has loaded the DLL)
Am I trying to write a windows emulator?" - No, not yet at least. I just want to know things
I'm intrested in low-level stuff such as compiler and OS-creation, so it's important to know what-is-a-result-of-what.
If it hadn't already turned into a discussion, I would have no reason not to close this thread. Wilkoh, please review the forum guidelines (found as an announcement at the top of every foum), and do not bump old threads in the future.
I am fairly sure that windows gets the address of imported functions from the dll's export table and that the lib files contain the names of the functions.
Addresses in the dll's export table are RVAs (relative virtual addresses) an RVA + the image base of a file gives the actual address. So before loading the exe has no addresses for the imported functions after loading windows has filled in the import table of the loaded file with correct addresses.
