(sigh) Programming in C is seriously not easy for a total beginner. Especially one that has only known how to do things in BASIC. Take it from me, from the 1990's after I had to give up finding work as computer engineer or programmer.
Start with this page:
https://qb64phoenix.com/qb64wiki/index.php/C_Libraries
But please ignore "Fast Math" and below, that stuff should seriously be removed.
There are many things that could be done in QB64 only with "DECLARE LIBRARY" block and a few functions from C.
Coding in Python, Julia, Lua etc. requires a virtual machine(*) that goes between BASIC and the other language. In the very least, will need the library which holds the functions of the other language, and will need at least a header file that describes how to call those functions. I could only speak surely for Lua: on Linux this library is called "liblua.o" and the header file for C is "lua.h". Will have to replicate in "DECLARE LIBRARY" block in QB64 what is expected to be used from the header file. At least half the functions of the "main" library, and a few from the "auxiliary" library. Now I'm not sure if this is apart from "liblua.o". I'm only speaking about Lua.
Otherwise you will have to become more familiar with pointers than ever. A good comprehension of what goes on with _OFFSET in QB64 would help a bit. The C compiler DOES NO RANGE CHECKING and nothing else that catches the programmer making a mistake, while QB64 in almost all cases just throws an Illegal Function Call, or Out of Memory or other error message in a nice beautiful dialog box.
I'm not saying this to discourage anybody. But doing something in C should be seriously studied, to see if it could be done entirely in a BASIC dialect such as QB64.
(*) EDIT: To clarify, in the least there has to be a "chunk" which holds the state of the interpreter that is embedded into QB64. Without that, it's not possible to communicate directly between the interpreter and the underlying C++ program that a QB64 program is eventually converted into. First there is this chunk that has to be initialized, which usually makes sure the "main" library is loaded. This could be a "dot-a" file on Linux or "dot-DLL" on Windows. Not sure about this, because "dot-a" is supposed to be a static library, but the same thing but with "dot-so" suffix is supposed to be the shared version. On Windows respectively this is "LIB" and "DLL" (dynamic-link library). Anyway, all the other functions to call, summoning the interpreter to do stuff, have to go through this "chunk" so that the interpreter could update its own state and be always ready to answer further calls from the "client".
For example with Lua, it could be tedious to have to keep track of the C stack.
This is because the stack is where the helper functions expect to obtain arguments to work with, and if they return any values, they will push them through the stack. If the stack is messed up, in the very least, the program won't work properly expecting stuff from the interpreter. At worst, the program could crash because QB64 could only account for its own libraries and routines, not for an external object being introduced via "DECLARE LIBRARY".
I guess with anything that has to be done with C, must worry about a stack. If that is overrun the program crashes shamelessly because the programming language is one of the closest to assembly language: it was designed to give almost all control to the programmer without slowing it down and checking constantly where is the error, where is the overflow, why isn't this working etc.
TL;DR programming in C is not easy!
