QUOTE
but after compilation does your variable/function names "disappear" and be replaced by an offset address in the compled exe, dll ?
Yes. Names are high level concepts. Just like what a programming language is in the first place. It's a bridge between programmers and computers. Neither humans and computers directly know it. Humans expend time learning this language. For computers, a set of more programs convert that code in that language to something that the operating system and the processor understand.
Processors don't deal with names.
QUOTE
Also your executable is loaded to a different part or the memory so their physical address can be very different every time you load your exe, and I suppose that the function addresses are resolved using the address of the first byte of the executable, and the adding the offset, is that correct, at all?
It's more complicated, so neither a yes nor no answer makes sense. It's also OS and architecture dependent, actually. The best way to really understand these details is to look at the resources involved in learning Assembly (probably x86 assembly, Windows OS, for you), not because Assembly is the enlightening answer, but because at that limited level of abstraction, you are exposed to the relevant information.
QUOTE
Besides that, what happens exactly when your memory is fragmented, and say you don't have a single block of continuous memory where you can "fit" your executable into, does the executable become fragmented as well?
Again OS dependent. And part of learning Assembly or OS design is that you understand common strategies for memory handling. Overall, what you'll learn is that, yes, in physical memory, the program is commonly spread out in fragments.
QUOTE
If yes, how does the computer resolve function and/or variable addresses, since addig the offset will not give the correct address, it has to keep track of the fragments as well.
By doing additional bookkeeping. That expensive OS you buy has a system of managing memory. There's several abstractions going on here. There's what memory looks like in say, C, C++, Python, etc.. Then there's memory according to how the OS presents to various programs. And then there's physical memory. The OS will manage physical memory, and present it in a uniform manner to programs. In fact, your processor does some additional memory management too (caching).
I know the answer isn't useful, but this is a question that's resolved in a single forum post. You'll have to delve into books and a good bit of technical reading to really understand all that's going on behind the scenes.