A: The short answer is: A framework is a set of related classes which you specialize and/or instantiate to implement an application or subsystem.
A: An object-oriented framework is a kind of class library. The distinguishing feature is that when the library is a framework the flow of control is bi-directional between the application and the library. This feature is achieved by the dynamic binding in object-oriented languages where an operation can be defined in a library class but implemented in a subclass in the application.
A: No. The first frameworks, such as Model/View/Controller, were developed for graphical user interfaces, but the technique is general and you can now find frameworks for many different domains.
A: Two main reasons. The framework is not just a collection of classes but also defines a generic design. When you use the framework your re-use that design and save time and effort. Secondly, because of the bidirectional flow of control the framework can contain much more functionality than a traditional library regradless if it is a procedural or class library. Having to write less code also saves you time and effort.
A: The main obstacle to frameworks is the learning curve. To reuse a design you have to learn and understand it. This is never easy if the domain is non-trivial. Furthermore, no one has yet come up with a real good way to document a framework.
A: Not easily, since frameworks rely heavily on dynamic binding. In C you would have to implement that by hand and combine it with strict programming conventions.
A:Before you even start to think about develop a framework you must learn how to use one. Get a commercially or publicly available frammework and start to develop applications from it.
A: That you have to turn the way you think about programming inside out. Frameworks follow the Hollywood principle: "Don't call us, we'll call you". The library code is in charge and as an application programmer you just provide various bits and pieces and is no longer in control. It is like programming event driven applications, but one step further.
A: Historically frameworks were monolithic and were not easy to combine. But the current trend is to make smaller frameworks, one framework for each part or aspect of an application rather than a single framework for the whole application.
A: None. All of the established methods build on the traditional one way flow of control. They support inheritance between classes but are very weak on dynamic binding. You can use the notation to describe different parts of the framework but the method itself can do more harm than good.
A: Frameworks are software whereas patterns are knowledge or information about software. Patterns can be used to describe frameworks and some part or aspect of a framework can be a realization of a pattern.
A: Developing a framework is somewhat like developing a scientific theory for some area. Developing a framework is hard and you should do that only for your own special area of competence.
A: Sure. The problem has to be cast into the generic template imposed by the framework. That may at first appear to be a limitation, but trying to express the problems in terms of a previously successful design is often the best way to understand the user's real needs.