In many articles all over the web the terms Inversion of Control and Dependency Inversion Principle seem to be mixed up and used as synonyms (further confusion is enforced by the tools that are called "DI-Containers" and "IoC-Containers"). [A Wikipedia article][1] does a nice job trying to explain that IoC is not the same as DI:

> inversion of control (IoC) describes a design in which custom-written
> portions of a computer program receive the flow of control from a
> generic, reusable library

So DIP is about having your modules depend on abstractions rather than concrete
implementations. 

And IoC is about giving control over your program flow to a separate module. And one of the things you can have this module do is resolve the dependencies at runtime.

This difference does seem fair, but I've never seen anyone mention any other applications of the IoC principle other than dependency resolving. The Wikipedia definition is quite broad, and it seems like you could do so much more with a module that has that can make calls into your custom code based on its configuration and some internal logic.

So, here are some questions that I can't quite figure out yet:

* What is the actual relation between IoC and DIP? Does IoC always serve as the means of implementing DIP?
* Why are tools for dependency resolving called both DI- and IoC-containers? This implies that DI and IoC are the same thing.
* Why are these tools called "containers"? We don't call ORM tools "ORM-containers", so why use this word here?

  [1]: https://en.wikipedia.org/wiki/Inversion_of_control