The Model represents our application's domain model. The View presents this information and the controller manipulates business logic.
Indeed, the view presents the user interface that presents this information.
But the controller processes the input from the user. There's no business logic in an MVC controler: the business logic is packed together with the domain model.
The MVC litterature is full of variants and misunderstandings. A very close pattern is the Entity-Boundary-Control pattern. An EBC controller indeed provides for business logic. But not a traditional MVC controler.
I do not understand from any diagram that I saw, who knows about whom. Does the View know about the Controller? Does the Controller know about the View?
The controller knows them all: the controler receives user input, interprets it, and if requested, creates new views or sends commands to the model.
Each view knows very well the model since it can query the model to present the relevant information. But it doesn't have to know the controller.
The model knows a little about the views: the views can be observers of the model, and the model needs to notify them if there are changes.
All I know is the Model should not know anything about the view, because those two should be independent. As for the opposite I'm not sure.
The model shall indeed not depend on the view: many views can exist for a given model and the model should known nothing about their details. However, it shall know how to notify the view. So there is an interface dependency: the view shall implement the notification interface, whereas the model just needs to know the interface.