There’s a lot of controversial discussion over the internet about achieving accurate sleep function on Windows platforms. The problem is most of them are very old and with the introduction of multicore processors many of the older functions break down but this is not the case in 2023.
Nowadays you can easily call the cross-platform C++ 11 chrono function and with the following source code, I could achieve one millisecond accuracy which is more than enough for my application.

#include <chrono>
#include <thread>
std::this_thread::sleep_for(std::chrono::microseconds(500));

Before I used the QThread::msleep function which had an accuracy of about 5ms to 15ms which was a lot more than what I imagined even when I used the QThread::usleep function.
There is an issue that is if you call the sleep function on a thread the OS scheduling system will put your application to sleep and it may take a while till the scheduler picks up your application again. To prevent this issue you need to specifically tell OS to treat your application differently than others and C++ 11 introduces chrono which uses QueryPerformanceCounter in the background Windows API to make sure Windows scheduler will pick your application up at the right time
You can go ahead and directly call the Windows API function but nowadays C++ 11 is nicely integrated into a lot of environments and it’s also a cross-platform solution so lucky you, you don’t need to get your hands dirty anymore.

1. YouTube – Test and Set Synchronization Primitive
2. RandomASCii: Windows Timer
3. Microsoft – Windows Performance Analyzer
4. YouTube – CppCon 2017: Fedor Pikus “C++ atomics, from basic to advanced.”

Previously, we learned we needed to put our callback function in a separate DLL and then load that DLL in another program. So you did that you create a separate dll, you put the callback there you call the SetWindowsHookEx function to set up the callback, But the callback doesn’t get called at all. So what’s wrong?

In order to figure this out, you need to notice that the SetWindowsHookEx function is actually a DLL injector. What does that mean? It means it first loads or injects your DLL inside the target application, And then it will hook your callback to the Windows messages queue or any other callback that you specified.

So for this to work, there are several conditions that need to be met otherwise several things can go wrong. And in my case, all of them went wrong. I’m going to list them here. So maybe it will help you. By any chance if you bump into any other issue and you finally got to solve it. Then please mention that in the comments, so other people and I can learn from your mistakes as well. Alright, let’s get to the problems.

1. Thread ID

The first problem that I had was the thread ID. So there are several ways to get the thread ID. First, don’t use the GetWindowThreadProcessId function

the best and most legitimate way to get the thread ID is by using the CreateToolhelp32Snapshot function which goes through all threads and checks if they are the main thread for an application. Actually, I found that the CreateToolhelp32Snapshot function is returning a different value than the GetWindowThreadProcessId, and it was actually the reason why my DLL doesn’t get floats. So that’s first.

2. DLL Dependency

Second, you have to be aware that your callback is going to inject your DLL into another program. So you have to make sure that the DLL that you wrote is not dependent on any other libraries other than the one that is already installed in the “System Path”.

so in my case, I was using the Qt library and the SetWindowsHookEx function was installing the hook successfully, But in reality, the dll never gets injected into the target program.

3. Printf

The last dilemma was, don’t use the printf function without taking extra care. So in my case, I was using this

To know why you got to understand that when you’re calling this function from your application and then you call AllocConsole function, it will open up a console that is hooked up to your application not to the DLL that is injected into the program so if you printf something in your callback, you won’t see anything because it’s running on a thread on your main application. If you want to see that you need to call the AllocConsole function inside your DLL main function.

Otherwise when you use the printf function that will write to the output of the console of the target processor instead of the console that you had opened

What do the letters W and L stand for in WPARAM and LPARAM?

Previously we discussed why it isn’t required to inject the DLL containing the callback to every application you need to set a hook on. In this post, we are going to see if it’s possible to create a hook or a global Hook with SetWindowsHookEx function without using any sort of DLL.
There is this cool trick in which you can use some known Dll to grab their handle and use that to legitimately install the hook with this function. Here is the code for doing that

HMODULE dll_handle = GetModuleHandle(L"user32.dll");
windows_exhook = SetWindowsHookExA(WH_GETMESSAGE, CallWndProcHook,
							dll_handle, tid); //0: System wide event
DWORD error = GetLastError();
if( windows_exhook==NULL )
{
	qDebug() << "Failed to set the hook. Error code: "
			 << error;
}
qDebug() << "hook was successfully installed="
         << windows_exhook << dll_handle
         << error << tid;

Although this code runs successfully and installs the hook if you install this globally by setting the thread id to 0, it will Instantly crash your whole explorer processor.
If you try that on a single application it also crashes the application.

I tried and spend some time to figure this out and it turns out that the callback will never get executed. I tried to simplify the callback do some sanity tests and it looks like the hook is installed without any problems and sometimes the callback called and most of the time it won’t but at the end in all test cases the targeted application were always crashes. Here is the simplified callback function that I used:

LRESULT CALLBACK CallWndProcHook(int nCode, WPARAM wParam,
                                 LPARAM lParam)
{
    // Call the next hook in the chain
    // The first argument is ignored so any value will work
    return CallNextHookEx(windows_exhook, nCode,
                          wParam, lParam);
}

I searched a bit about this and there were two comments around this issue

1. The first was that this is because you are skipping the phase which is putting your callback inside a Dll [link]
2. The second one is it’s because of some sort of aggressive security application that detects that this is not a legitimate behavior so it will instantly kill the effected affected application in order to prevent any data hijacking [link]

Conclusion

Although at the beginning it seems that you can get away using SetWindowsHookEx function without a Dll currently at least up to what I know there is no possible way to use SetWindowsHookEx function without having the callback inside another Dll

I starting to use WinRT with Qt today and now after long time with MinGW, I’m switching to MSVC in Windows. Here is why

1. MinGW is opensource but deep down if you are in Win32, MSVC compiler always offers better API compatibility
2. WinRT is available only on MSVC
3. MSVC is better with memory control access management using SEH which MinGW doesn’t offer
4. MSVC offers pdb files That can help you if your program crashes. Then you can generate the core dump and debug using WinDbg
5. If you ever get around to some dll that simply doesn’t work with your project, it’s because MinGW and MSVC ABI are not the same. and probably that DLL was compiled by MSVC not MinGW. Same OS and still a different ABI, sounds too Windowsy to me
6. Because you are on Windows, show some support to the closed-source community!

On the way to develop a driver for Scarlet Solo Gen3 to harness the power of Shure SM57 Dynamic Microphone.

Useful links to preserve:

1. Microsoft – Universal Audio Architecture: Guideline to for Sound Card Without Propriety Driver

2. Microsoft – Introduction to Port Class

3. Microsoft – AVStream Overview

4. Microsoft – WDM Audio Terminology

5. Microsoft – Kernel Streaming
6. Microsoft – KS Filters

Update 1: Finished developing! Here is the link to the released driver

GitHub – BijanBina/BAudio Windows 7 x64