Dynamic linking seems to be broken for x86_windows

*Describe the bug
I'm trying to compile a simple dynamic linking example implemented in C language with MinGW and run it with qiling.

In my main.c I have:

#include <stdio.h>
void print_hello();

int main() {
   print_hello();
   return 0;
}

In my library.c I have:

#include <stdio.h>
void print_hello() {
   printf("Hello World!\n");
}

When I compile both and dynamically link they with each other, the resulting executable seems to be working under Wine without any problems:

$ i686-w64-mingw32-gcc library.c -shared -o hello.dll -static-libgcc -static-libstdc++
$ i686-w64-mingw32-gcc main.c hello.dll -o hello.exe  -static-libgcc -static-libstdc++
$ wine hello.exe
Hello World!

But, when I give it a run with Qiling it complains about unimplemented APIs in hello.dll:

# /root/qiling/qltool run --filename rootfs/x86_windows/bin/hello.exe --rootfs rootfs/x86_windows
<...>
[!]     api print_hello (hello) is not implemented
[!]     api _lock (msvcrt) is not implemented

I'm pretty sure there's no problems with hello.dll location, as when I remove it it starts printing an error message of a quite different kind.
Hooking print_hello() with ql.os.set_api() won't be a solution as it gives no chances to perform some instrumentation inside hello.dll real code.
I've also tried performing the same test with x8664_linux target, and unlike for x86_windows, it worked without any problems.
Is there anything I'm missing?

Expected behavior
I expect "Hello World!" to be printed just as under Wine, with print_hello() function from hello.dll being in use

P. S. I've attached my prebuild binaries just in case if you need it. Of course, I'm using the dev branch of Qiling just as suggested in your tutorial.

hello.zip