Lets say in theory a programmer is trying to make a program for windows that will simulate mouse or keyboard input. Windows has functions written in C++ that when used together can do just that. If someone programed in C, Rust or another compiled language, that is not C++, what is a good way to make the desired program?
Does the programmer need learn C++ or are there other ways to make the program without learning the language the operating system was programmed in?
Is there a way to do part of the project in the language the programmer is used to and part in the other language? This way the programmer could learn just some of the other language.
I have heard windows is made using C and C++, that is why I thought the last option might be possible.
Side Note: I tried to use the tag "multiple-languages" but it kept being changed to "multilingual".
I think I'm interested in knowing how cross-language calls are done.
It depends on the languages involved and their respective runtimes:
Calling C from C++ is straightforward. In your C++ code you declare the C method as:
extern "C" void foo();
Calling Java from Kotlin or Groovy or another JVM based language is similarly straightforward, since these languages have a common runtime type system.
In other cases, it can be a lot more complicated:
Calling C or C++ code from Java (21 and earlier) entails using either JNI or JNA. They work a bit differently, but in both cases the programmer needs to deal with the incompatibility of the type systems; e.g. converting from one string representation to another, copying objects so that the Java GC doesn't move them.
Calling C from Python entails writing a ctypes
wrapper.
When bridging between a managed / garbage collected language (e.g. Python, Java) and a non-managed language (e.g. C, C++), you introduce the risk that something done on the non-managed side will break garbage collector invariants. It is ... complicated.
So what does this mean in practice?
Often people use cross-language calls because one language is (supposedly) "faster" than the other. But it often doesn't work out; i.e. they don't get the anticipated speedup because of overheads related to the calls. And then there's thread-safety ...