Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
From the recent dissasembly of "HelloWorld.exe" compiled by MSVC:
.text:00411279 call ds:__imp__printf
So, why base address is data segment, not a code segment (which would be a more logical thing to do?)
Project uses Multithreaded Debug Dll as runtime library.
__imp__printf is not the function's code; it's a pointer the function's code. Since it's a pointer (which is data, not code), it makes sense for the pointer value to be in a data segment, not in a code segment. More specifically, this pointer value is set at run-time by the loader, so the memory page needs to be writeable, which is even more of a reason for this to be in a data segment instead of in a code segment.
The ds: was added by IDA, not by the compiler. If you look at the raw opcode bytes, you will see that there is no DS override prefix in the instruction. It's silly that it does this.
IDA adds that ds: prefix because otherwise you wouldn't know that this is an indirect call--that is, that it's reading a 32-bit variable at an address named __imp__printf then calling the address stored in that variable. Without the ds:, it would be just be calling __imp__printf directly.
If IDA used a better assembly language syntax--namely, the nasm syntax--that instruction would look like simply this, using brackets to show that it is a memory read (and dword to distinguish from a few other weird types of call):
.text:00411279 call dword [__imp__printf]
Windows, like pretty much every other 32-bit OS, has a flat address space. CS, DS, ES and SS all have the same base address, 0, so it doesn't matter which segment you use as your base. (Except that you can't do a memory write if CS is your segment.) FS and GS have different bases, since the major OS's all use them for thread-local storage, but those will always have explicit prefix bytes in the instruction.
