Use a KSEMAPHORE instead of a NotificationEvent to signal availability. This is to prevent satisfying the wait for multiple waiters, when only a single entry is on the list.
Fixes crashes on SMP builds.
IpReleaseAddress: Use DhcpReleaseParameters instead of DhcpReleaseIpAddressLease.
IpRenewAddress: Use DhcpAcquireParameters instead of DhcpRenewIpAddressLease.
Historical note:
Investigation shows that this functionality, introduced between builds
1902 and 1906 of Windows NT 5.0 (future 2000) Beta 3, has always been
"nop-ed" and has remained this way till Windows Server 2003.
The value read from the "SafeMode" registry value is unconditionally
overridden afterwards, causing the notification DLLs to always be loaded.
In ReactOS, this functionality is restored, and only the notifications
tagged as such are loaded in SafeMode.
Furthermore:
Analysis of strings in Win2000 and WinXP/2003 winlogon.exe, show that
the "Safe" registry value doesn't exist for notifications; instead,
it is named "SafeMode".
The "Safe" value appears only for the SensLogn (SENS Winlogon Event) handler
registry entry. My hypothesis is that the value name is a typo for the
"SafeMode" value. It has been introduced in the `\Winlogon\Notify\SensLogn`
registry entry for SensLogn around Windows NT 5.0 build 1946.
Analysis of strings in Win2000 and WinXP/2003 winlogon.exe, show that
the "Enabled" registry value doesn't exist for notifications.
This value is actually only used by the ScCertProp (Smart Card Certificate
Propagation) notifications, in wlnotify.dll, to enable or disable certificate
progagation.[^1]
Note that whatever the "Enabled" registry value is, the notification DLL
is still loaded within winlogon.exe.
We however keep the `bEnabled` internal flag, so as to be able to disable
at runtime notifications that could not be delay-loaded, or that behave
erratically, etc.
[WLNOTIFY] Add a comment about the "Enabled" value in scard.c!SCardStartCertProp()
[^1]: For more information, see:
https://www.microfocus.com/documentation/securelogin/9.0/administration_guide/blm54qb.html?view=printhttps://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/925884
Fix the shell32 apitests so that they pass on Windows Server 2003 - Windows 10. Many of these fixes are for Vista+, but the most important fixes are for ShellExecCmdLine and FindExecutable which had issues closing windows after tests and deleting test files. Failing to delete these files breaks the other test (i.e. running ShellExecCmdLine would break FindExecutable and vis-versa.)
- Move sdk\include\reactos\wine to sdk\include\wine
- Reorder the directories in include_directories() to be closer to alphabetical. This should make it easier to determine what global include directories can be removed in the future.
Windows uses the keyboard layout IDs of the Ristome, Ergo and Neo layouts for the German(IBM), German Extended 1 and German Extended 2 keyboard layouts.
GCC and Clang need to mark functions that use SSE/AVX etc, either with a function attribute or a pragma around the function. strlen uses a template function that either uses SSE2 or AVX2. Previously the template was surrounded with pragmas to allow both SSE2 and AVX2, but that makes GCC assume that it can use AVX2 instructions even in the SSE2 version. To fix this the template instances are now build in individual compilation units for SSE2 and AVX, separate from the "dispatcher" function.
Now ucrtbase doesn't crash anymore on GCC build.
Another issue was the namespace around strnlen_mode, which has confused clang so much, that it forgot to instantiate the template code.
GCC was optimizing away the xor with __security_cookie when passing nullptr_t, because the return value was also nullptr_t, assuming it must be nullptr.
CORE-13532
* Fix macros VCMPCLR and VCMPCLRS to correctly select between gradient color or solid color triangles.
* Remove hack from commit 1c0aedc and replace it with 'if' test before STEPCOL in 'while' test.
* Other assorted fixes for FILLLIINE macro starting position to completely fill triangles.
* Remove warning/FIXME: about IntEngGradientFillTriangle being broken.
* Precede some 'while' loops by 'if' tests to exclude possible loops.
Introduce and use a minimal testing framework (minitest.h) based on
an updated version of `wine/test.h`.
Each notification handler becomes its own test. Useful macro and
function helpers have been introduced to simplify the code that is
duplicated for each handler.
See commit 38d07d3a24 (PR #8234) for the details of how to install
and use the notification dll.
These tests can exercise the notifications in the four cases, where
asynchronous events and user impersonation can be independently
enabled or disabled. To do this, the `Asynchronous` and `Impersonate`
registry `REG_DWORD` values, inside the `WLNotifyTests` subkey of:
`HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify`
must be set to their intended values[^1].
----
[^1]: https://learn.microsoft.com/en-us/windows/win32/secauthn/registry-entries
----
Current test results:
- When each notification is emitted, the DLL is loaded then unloaded:
```
err:(modules\rostests\win32\winlogon\wlntfytests\wlntfytests.c:1307)
WLNOTIFY(ac.b0): Entering `DllMain`(hInst: 0x10000000, dwReason: 0x1, pReserved: 0x00000000)
...
err:(modules\rostests\win32\winlogon\wlntfytests\wlntfytests.c:1307)
WLNOTIFY(ac.b0): Entering `DllMain`(hInst: 0x10000000, dwReason: 0x0, pReserved: 0x00000000)
```
This doesn't happen on Windows. And indeed, it should _not_ happen,
because otherwise the DLL would loose any of its internal global state
between consecutive notification calls. This currently happens in
ReactOS, where we can observe the following:
```
modules\rostests\win32\winlogon\wlntfytests\wlntfytests.c:788: Test failed: **** WLEventLogon: ERROR: Wrong state NON-INITIALIZED, expected Startup or Logoff
...
err:(modules\rostests\win32\winlogon\wlntfytests\wlntfytests.c:1036) **** WLEventLogon: Changing state NON-INITIALIZED to Logon
```
and similar for every other notification.
- Test results for each notification:
```
WLEventStartup: 30 tests executed (0 marked as todo, 1 failure), 0 skipped.
WLEventLogon: 30 tests executed (0 marked as todo, 4 failures), 2 skipped.
WLEventStartShell: 30 tests executed (0 marked as todo, 4 failures), 2 skipped.
-- Note: missing WLEventPostShell --
WLEventLock: 30 tests executed (0 marked as todo, 4 failures), 2 skipped.
WLEventUnlock: 30 tests executed (0 marked as todo, 4 failures), 2 skipped.
WLEventStartScreenSaver: 30 tests executed (0 marked as todo, 10 failures), 0 skipped.
WLEventStopScreenSaver: 30 tests executed (0 marked as todo, 9 failures), 0 skipped.
WLEventLogoff: 30 tests executed (0 marked as todo, 5 failures), 2 skipped.
WLEventShutdown: 31 tests executed (0 marked as todo, 5 failures), 0 skipped.
```
- Add DeleteNotification() helper;
- Invoke it in failure path in AddNotificationDll(), and in
CleanupNotifications().
- Simplify iteration loops in CallNotificationDlls() and in
CleanupNotifications().
Side-note: When doing `Notification = CONTAINING_RECORD(ListEntry, ...);`
where `ListEntry` iterates over a well-formed linked-list, the `Notification`
pointer can **NEVER** be NULL!
Now the WinMain() message loop correctly exits and we get to perform
last-time cleanup. However, the main thread must not exit (except under
certain conditions, not yet implemented), so we Sleep for an infinite
amount of time.
Timo Kreuzer