Dynamic Linking RAM usage?

On windows, dynamic linking is typically done with dll files. When the os loads a program into RAM, it loads a copy of each dll the program uses, right? When two programs use the same dll, do they both get a separate copy of the dll? I don't know why, but I was thinking about it, and it seems like it'd be a huge memory waster if each program had copies of the same libraries loading into RAM simultaneously. Do modern operating systems like windows
take care of this, or do they really waste that much memory? It seems like they could make the os set up an area of RAM for this purpose when the os boots up, right?
Meh.
/Discuss

It's not really a waste.

You know that every program on a protected mode x86 operating system can access 4gigs of memory, so the amount of memory that windows will have to reserve in it's page file or in ram is the same with or without dlls loaded. Of course not all of this memory has to be allocated when the program starts, but chances are very high that a program that runs on windows will need to access it's api's and that's why they load them anyway.

So... having a copy of each dll in memory doesn't fill the memory up too much? Why is this, because of the page file on the hard disk acting as RAM? Maybe I don't really understand how the page file thing works; It's basically reserved space on the HDD that acts like RAM, but slower, right? So what if we had a small embedded system with limited ROM or flash memory(like... 120kb-ish), a page file wouldn't really work as well, right? Would there be a need for a "shared library" type of thing? I dunno, I'm pretty intoxicated right now. Tell me more. I need to learn this shit.

That's exactly how a page file works and it wouldn't working on a system with very limited resources, but then windows wouldn't run there either. Such a system would run on either a custom operating system (graphical calculators for example) which don't even need to support multitasking and a virtual address space, or a modified linux distro which doesn't use page files (those used by digital forensics so that they don't destroy any evidence on the suspects' computer)

Windows loads only two dll's into a programs memory when it starts: kernel32.dll and ntdll.dll. They are needed during PE program startup and the first code executed in a new program is located in ntdll.dll!ldrloaddll(). All other dll's your program loads itself. Now apart form the fact that windows does not know how much memory it has to reserve for a program beforehand, and that programs are likely to need the windows api. There are also security reasons involved, if I changed code in the library then all other applications would have the same change, this leaves an enormous security gap. Read-only memory is not really an option, since large portions of memory would be blocked for the application eg. Even if I don't have any libraries loaded at 0x5000000 I still could not use this memory because a shared library is located here (even if it isn't loaded right now)

In windows Kernel memory is shared, so it's not that inefficient.

Originally Posted by .::SCHiM::.

Pretty much sums it up. Consider having all applications using a single d3d9.dll module instance, if you were to modify the VTable entries aiming to make a hack for CA, any program running at that time using d3d9.dll would have the same effect mirrored. Not having proprietorship over the modules your program needs to run would make it very difficult to detect security risks and hacks, it'd be as simple as loading the dll from your own process (which is actually just granting you access to the shared module), then fuck around with it. The target you wish to hack would have no idea it's running a corrupt module now, unless it actually went out and scanned the shared module for corruption, which is a very shaky security effort.

Dynamic Linking RAM usage?

Post a Reply

Similar Threads

Tags for this Thread