Have you heard about DLL relocations?

In the old days, people would save Ram like crazy. Recent bump ups in Ram prices may result in similar outcomes...

Whenever you open a process in Windows, it loads to a specific memory address. This address is usually 0x4000000. All exe processes share the same address.

If you think of it, you see that all processes should not be able to share the same address. Yet, it is possible, thanks to the virtual memory. Each process sees memory differently.

In the old days, memory was expensive. Therefore, to the rescue came shared libraries or Dynamically Linked Libraries. A library is loaded by the application when it is needed. Since code in a library is useful for more than one application. When a library is loaded, it is loaded under some address.

When a library is loaded in a specific address, more than one application is able to use it by referring its memory address.

If however two applications were to share the same code, there was a possibility of a very unusual condition. While application was loading a DLL code, another one might already have loaded a different DLL library at the same address.

This condition could result in DLL relocation. An application might want to choose to load the DLL once again resulting in memory waste.

Bonus babbling

Their primary purpose was to share executable code and data between processes, like for example Shell32.DLL. If a DLL file was loaded once, more than one application could use code and data from that library.

Nowadays it is hard to find this level of optimization on modern Windows. An application consists of entire runtime, which weights more than Windows 95 itself, because apart from Visual Studio runtimes, it contains an entire web browser bundled.