overlays, shared libraries, and all that

Once upon a time you would link your program with everything it needed, and after that it stayed the same (unless the operating system calls changed behaviour).

But memory was insanely expensive so programs soon didn't fit. I well remember trying to get overlays to work.

So we invented virtual memory and shared libraries. Shared libraries had other advantages. Without changing your program you could get performance and security upgrades to the libraries which improved all the programs using that library. Sometimes there were also functionality improvements and we see that a lot in the smartphone/tablet world with google moving a lot of functionality out of the operating system and into a library.

So we've got stuck on shared libraries even though they bring up a big problem for the developer: version hell. This is where one library requires specific versions of another library. Then you want to use a different library as well, and it requires a different version of that 3rd library.

Memory is now cheap, so really it shouldn't be beyond the wit of man to design a system that incorporates the advantages of shared libraries without the problems. Or maybe allow old fashioned linking, but still allow updating without relinking main. At any rate it is obvious that different libraries should be able to grab stuff from other libraries without getting in each others way. It doesn't matter if there are multiple versions of the same subroutine in memory. It should be said that libraries should never use global memory: if they want global memory they should map a file with the particular level of granularity they want.

This post was inspired by this observation from the new Swift blog:

"Xcode embeds a small Swift runtime library within your app's bundle"

But this seems to be a temporary thing, not an attack on the problem.