somehow its pretty sucky that i can't find information which answers this question:
each shared library consists of code (.text) and data (.data, .bss) . thus whenever some process requires such library, the code and data of that library are loaded to some physical memory locations (if not loaded already), and are then mapped to the virtual address space of the process.
so, question 1: when multiple processes require the same shared library, and that library has global variables (.bss), do all processes work on the SAME variables (so that if process A sets some global variable to foo, does another process B also read foo then?) or does each application get its own copy of the variables (the .bss section) of the dll?
question 2: where does the dll exist in the virtual address space of the process?
does some dll exist on the SAME address in ALL address spaces of the processes? or can e.g. process P1 have the dll on address foo and P2 has the same dll mapped to address bar?
question3: so if a process does not need some dll, but that dll is loaded, could it still access it?
i would say no, because if a process does not load some dll, there is no reason for it to be mapped into its address space (thus there is no need creating those segments)
would be glad if someone could give me a link to where i can find the answers :/
answer 1: each process gets a different mapping of the dll in memory. Its' the same as spawning different processes from the same exe. To share memory, you'll have to explicitly create a shared memory region.
answer 2: you can't tell. when a process is spawned some default OS dlls are mapped somewhere in memory. For a given OS usually those dlls are in the same memory position because they're constantly mapped in memory like kernel32.dll. But you shouldn't consider a fixed memory adress. For program specific dlls which have to be loaded explicitly with LoadLibrary, those are too mapped somewhere which rarely is the same place. Basicly they're loaded on some free space on the memory of your program. Imagine you did a malloc and place the contents there. The memory address is variable
answer 3: yes it can. lots of OS dlls are mapped directly when your program starts but probably you don't use half of them. If you map a dll but don't use it that's ok, although a bit inefficient. It keeps loaded in memory. Later you can at will acess some entity in it.
thx for your reply, but certain points are still not clear to me:
1) well the code section of some dll exists in ONE physical location (thats the point of an dll).
thus: all processes which have that dll loaded into their virtual address spaces and access it, actually refer to the same physical location.
but: what about the data section? is there ONE PHYSICAL COPY of it for EACH process, or is it the same as with the code section, so ONE PHSYICAL data section for ALL processes?
2) consider this example:
.) a process P1 loads the (edit: NON-SYSTEM) library L
.) later, a second process P2 loads the library L (P1 is still running)
in P1, the library exists at virtual address foo
does in P2 the library also exist at virtual address foo?
in case that P1 and P2 terminate, L is unloaded and after that another process reloads L its obvious that L does not have to exists at virtual address foo anymore
3) well, kernel.dll, gdi.dll and some others ALWAYS exist at the same virtual address in every process
but on the other hand system dlls dont get unloaded (unless the system terminates) ok, it makes sense having all system stuff in the same place all the time.
but that still leaves the question (2): as soon as a (user) dll is loaded, is it mapped to the same VIRTUAL address in all future processes? (unless the dll gets unloaded)
hm... but that would mean that processes which do NOT require a LOADED dll still must have that region reserved in their address space. thus that would waste space for processes that dont need that dll.
so the same dll can be in different virtual addresses for different processes - right?
Most modern OSs do what is called 'copy on write' so the actual data pages are shared UNTIL a change is made, then each process gets its own unique copy of the data page.
thx for the reply, finally i know what happens to the data of dlls
now i only need to know what happens to the virtual addresses
The 'actual' virtual address is essentially irrelevant and is not even required to be the same for each process using the same shared DLL pages. For any give process, the OS tracks which actual pages are allocated exclusively for that process and which are shared (and who is sharing), so when a process terminates all the exclusive pages are reclaimed and the shared pages remain. If there are no other processes using shared pages, those are also reclaimed.
There is a lot of 'wasted' space in the range of the virtual address space (4 GB). I have read reports that the top GB of addresses are all 'owned' by the OS when it maps a process trimming the space available to the process to a max of 3 GB (I am talking about 32 bit OSs here), then there is the stack, which typically grows toward the advancing heap, so the base address of the stack is often at the 3 GB boundary, so in many cases the heap is limited to the lower 2 GB. All this is moot if you have a machine with less than 2 GB of physical RAM (physical pages are located willy-nilly when compared with virtual addresses), but can become problematical when you have physical RAM greater than that (i.e., the lack of virtual address space becomes an issue as the OS has nowhere to map the physical memory addresses). This was of interest only to high-end server developers on 32 bit OSs (64 bit OSs are a very long way away from worrying about this) until the price of RAM dropped to the point where it is practical to load your machine up to have more than 2 GB; you fail to see a performance gain or may even a program abort when you try to create a heap larger than 2 GB. There are supposed to be some fixes to make more efficient utilization of the virtual address space (the stack should never routinely need a GB of space, for instance, and it is also unlikely the OS really needs a full GB of space for all of its user-process linked bookkeeping), but just like how DOS had that silly segmented memory model long after the hardware could support 32 bit memory, most 32 bit OSs have this carry over from the early days when there was no one wealthy enough to have more than 2 GB of RAM.