[WIN32KNT_APITEST] Add NtUserSetTimer API tests

[turican0]

Purpose

Addition of apitests for NtUserSetTimer

JIRA issue: CORE-9141

Proposed changes

Test 1 - test of creating/canceling 20 timers and comparing the raw number of returned messages - without parent window
Test 2 - test of creating/cancelling 20 timers and comparing the raw number of returned messages - with parent window
Test 3 - test creation/cancellation of 40000 timers - without parent window
Test 4 - test of creation/cancellation of 40000 timers - with parent window
Test 5 - test creation/cancellation of 2 timers and compare their index to see if they differ - without parent window

[HBelusca]

SLEEP_TIME and TEST1_INTERVAL are integers; 1 is also integer but TIME_TOLERANCE is a float; I wonder whether you correctly get what you want here.
Namely, your 1 - TIME_TOLERANCE going to be zero and 1 + TIME_TOLERANCE going to be 1... 🤔 🤔

[turican0]

HBelusca I have modified the code based on your suggestions.

[turican0]

HBelusca The number of messages is highly indicative, as it takes several milliseconds to initialize, etc. That's why there is a 50% tolerance to received messages count. It worked for me without overwriting, but I understand that if we change the values, it could lead to miscalculation. Anyway, we'll see how it behaves on the server, maybe we need to give the tolerance even higher.

[turican0]

I'll separate the tests without and with the window.

[binarymaster]

Helped with review comments, please recheck.

[Doug-Lyons]

LGTM.

[HBelusca]

Last suggestions:

• static-ize functions that are used only within this file;
• add a comment explaining for what they are used.
• MessageLoop() function seems to be unused.

[turican0]

I'm still wondering if it would be safer to have a timer count of 32767 instead of 32768 if some application used INT instead of UINT for SetTimer. Are we sure that windows has 32768?

[HBelusca]

I'm still wondering if it would be safer to have a timer count of 32767 instead of 32768 if some application used INT instead of UINT for SetTimer. Are we sure that windows has 32768?

You mean, for the 2nd parameter nIDEventof SetTimer(), which is an UINT_PTR ? If so, this is a parameter that has to be different to zero in order to describe a timer ID, that's it. And note that because its type is UINT_PTR, this means that in 64-bit builds, its value can go up to 2^64-1.

---

Sorry to ask, in case this has been already addressed and discussed: in the SetTimer() msdn page, it's written:

SetTimer can reuse timer IDs in the case where hWnd is NULL.

Is this correctly handled?

[HBelusca]

Using explicitly unicode window class & functions:

Suggested change

	WNDCLASS wc = { 0 };
	WNDCLASSW wc = { 0 };

[HBelusca]

Suggested change

	wc.lpszClassName = "TimerWindowClass";
	RegisterClass(&wc);
	wc.lpszClassName = L"TimerWindowClass";
	RegisterClassW(&wc);

I wonder whether we should check the returned value from RegisterClass ...

[HBelusca]

Suggested change

	HWND hwnd = CreateWindowEx(0, "TimerWindowClass", "Timer Window", 0,
	HWND hwnd = CreateWindowExW(0, L"TimerWindowClass", L"Timer Window", 0,

[HBelusca]

hInstance comment:

Suggested change

	UnregisterClass("TimerWindowClass", GetModuleHandle(NULL));
	UnregisterClassW(L"TimerWindowClass", NULL);

2nd parameter is optional and when giving NULL it does the same thing as GetModuleHandle(NULL)

Alternatively if you want to keep GetModuleHandle explicit, I would suggest you add a

HINSTANCE hInstance = GetModuleHandle(NULL);

at the beginning of the START_TEST(...) function, and then use that hInstance variable in all these places where you need it.

[HBelusca]

See other hInstance comment.

[HBelusca]

See other hInstance comment.