If you're running minikube on OSX or Linux, you can configure Docker to use the minikube environment by running

eval $(minikube docker-env)

When you do this, you don't need a separate Docker desktop application. You're still technically using both Docker and Kubernetes, but you won't be using the setup with the "whale" icon on OSX.

Fundamentally Kubernetes takes responsibility for launching and managing Docker containers. (Or potentially other things, but almost always Docker containers.) It's a more complicated and more powerful tool along the same lines as Docker Compose and Docker Swarm. Minikube is very small Kubernetes cluster that runs inside a virtual machine; if you run kubectl get nodes you will see the single VM node, and that includes a copy of Docker.

Technically, you need a container runtime which respects CRI (Container Runtime Interface).

That is why you have CRI-O, which provides an integration path between OCI conformant runtimes and the kubelet.
See "CRI-O, the Project to Run Containers without Docker, Reaches 1.0" by Susan Hall.

The project “opens the door for plugging alternative container runtimes in the kubelet more easily, instead of relying on the default docker runtime.

Those new runtimes may include virtual machines-based ones, such as runv and Clear Containers, or standard Linux containers runtimes like rkt,” Red Hat senior engineer Antonio Murdaca wrote on the Project Atomic blog.

But in your case, your issue is to make Minikube work with HyperV: see "Minikube on Windows 10 with Hyper-V" from Jock Reed.
The trick is to create a new (External) Virtual network switch, named "Primary Virtual Switch", and to start Minikube with:

minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch"

As mentioned above, you need any runtime container. Kubernetes and docker are part of ecosystem. Both have different responsibilities, kubernetes handle cluster health and docker run application containers.