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
- 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.
- 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.
- MSGINA: The `pMprNotifyInfo` and `pProfile` structures returned by
`WlxLoggedOutSAS()`, as well as all of their pointer fields, are
allocated by `LocalAlloc()`[^1][^2]. This is what Windows' Winlogon
expects (and ours too, for interoperability with GINA dlls written
for Windows), as it then frees them using `LocalFree()`.
- WINLOGON: In `HandleLogon()`, free the cached `MprNotifyInfo` and
`Profile` buffers (and all their members) obtained from a previous
call to `WlxLoggedOutSAS()`.
[^1]: https://learn.microsoft.com/en-us/windows/win32/api/winwlx/nf-winwlx-wlxloggedoutsas
[^2]: 3rd-party GINAs rely on this as well. One example can be found at:
https://www.codeproject.com/Articles/20656/Winlogon-using-Mobile-Disk
CORE-18351 CORE-18237 CORE-17137 CORE-16567
CORE-15360 CORE-5071 CORE-3804
Reset `LogonState` back to `STATE_LOGGED_OFF` before invoking
`WlxDisplaySASNotice()` when:
- in `STATE_LOGGED_OFF_SAS` state, `HandleLogon()` failed;
- or when an attempted shutdown operation failed.
This fixes the resulting inconsistent `LogonState` that happened if
any of these operations failed due to legitimate reasons. For example,
a corrupted user profile that caused the login attempt to abort, or,
an ongoing shutdown attempt being aborted as well.
One of the user-visible effects of this inconsistency, was the inability
to access the familiar Logged-Out SAS dialog by pressing Ctrl-Alt-Del at
the invite (SAS notice) dialog, because the `LogonState` was incorrectly
left into the `STATE_LOGGED_OFF_SAS` state, instead of being reset to
`STATE_LOGGED_OFF`.
----
Typical scenario:
The "Administrator" user, who is auto-logged-in by default after the
installation, gets a corrupted ntuser.dat profile registry hive if the
2nd-stage installation is aborted at the end by force-restarting ReactOS.
After reboot, ReactOS tries to log into the account, but fails, and goes
back to the Ctrl-Alt-Del invite dialog.
Before this fix, the user couldn't go into the Logged-Out SAS dialog to
enter new login credentials and attempt login to another account.
This is now fixed.
- Locking (`WLX_SAS_ACTION_LOCK_WKSTA`) is allowed only if `LogonState`
is either `STATE_LOGGED_ON` or `STATE_LOGGED_ON_SAS`, i.e., either the
user invokes the `user32:LockWorkStation()` API or presses Win-L, or,
opens the Logged-On SAS dialog then clicks on the "Lock Workstation" button.
- Unlocking (`WLX_SAS_ACTION_UNLOCK_WKSTA`) is allowed only if
`LogonState` is either `STATE_LOCKED` or `STATE_LOCKED_SAS`,
i.e., the workstation is locked and we are either on the Locked-
notice or on the SAS dialog that asks for the user credentials.
Additionally:
- Fix the invocation order of `LockHandler`/`UnlockHandler` notifications:
* the `LockHandler` is invoked on the Winlogon desktop, just before
displaying the Locked-notice dialog;
* the `UnlockHandler` is invoked on the Winlogon desktop, just before
switching back to the user's desktop.
- If we are on the Logged-On SAS dialog and the user presses Win-L to
lock the workstation (instead of pressing the corresponding dialog
button), the `DoGenericAction(WLX_SAS_ACTION_LOCK_WKSTA)` handler is
invoked asynchronously while the SAS dialog is still being displayed.
We thus need to ensure all the existing dialogs are closed before
displaying the Locked-notice dialog, in order to avoid stray dialogs
being shown concurrently.
CORE-13478
Addendum to commit 46dcab7ab.
The `WLX_SAS_ACTION_TASKLIST` action can be invoked in three scenarii to
open the Task-Manager:
1. from the logged-on state (`LogonState == STATE_LOGGED_ON`), when the
user presses Ctrl-Shift-Esc while being on its own desktop (usual case);
2. from the Logged-On SAS dialog (`LogonState == STATE_LOGGED_ON_SAS`),
when the user presses the "Task-Manager" button: here Winlogon should
switch back to the user's desktop, restoring `STATE_LOGGED_ON` and
start the TaskMgr;
3. or when the user presses Ctrl-Shift-Esc **while being on the Logged-On
SAS dialog**: in this case, the Task-Manager is started on the
currently-hidden user's desktop (and so, will be hidden), but the SAS
dialog stays open. The user will see the opened TaskMgr once (s)he
closes the SAS dialog and Winlogon switches back to the user's desktop.
In order to support these scenarii, the `WLX_SAS_ACTION_TASKLIST` action
handling is reworked:
- `SASWindowProc(WM_HOTKEY, IDHK_CTRL_SHIFT_ESC)` always invokes the
`DoGenericAction(WLX_SAS_ACTION_TASKLIST)`: this allows centralizing
inside `DoGenericAction()` the condition checks for starting TaskMgr.
- `DoGenericAction(WLX_SAS_ACTION_TASKLIST)` just starts the Task-Manager
only if the Winlogon's `LogonState` is either `STATE_LOGGED_ON` or
`STATE_LOGGED_ON_SAS`. It doesn't attempt there to switch desktops nor
change the `LogonState` value, in order to support scenarii 2 and 3.
- The switch from/to Winlogon/user's desktops when going to the
`LogonState: STATE_LOGGED_ON -> STATE_LOGGED_ON_SAS` change is done
in `DispatchSAS()`, just before invoking the GINA's `WlxLoggedOnSAS()`
(see below for more details) and just after it returns, only in the
necessary cases.
----
[MSGINA] The WlxLoggedOnSAS() dialog shouldn't switch the desktops itself.
This behaviour can be observed on Windows with Winlogon debugging + tracing
enabled. It is Winlogon instead that does the desktop switch itself, as for
all the other SAS dialogs, in addition to changing its internal `LogonState`.
Fix for commit 7aecedf79 (r58785).
- umpnpmgr.dll: Call I_ScSendPnPMessage to report pnp events to the service manager.
- adavpi32.dll: Implement I_ScSendPnPMessage which calls the service managers RI_ScSendPnPMessage function.
- services.exe: Add a debug message to RI_ScSendPnPMessage.
Re-trial of #7800. Deleting __WINESRC__
hacks.
JIRA issue: CORE-5743
- Add sdk/cmake/set_wine_module.cmake.
- Load set_wine_module.cmake at
top-level CMakeLists.txt.
- Use set_wine_module cmake function
and delete __WINESRC__ as possible.
- Delete many include_directories.
URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
They are redundant when these are already present in the given module's
root resource file, from which the language-specific resource files are
being included.
This function combines those that write a message to and read
a message from the specified pipe into a single operation.
Its usage helps in simplifying the code further.
In addition:
- Acquire ControlServiceCriticalSection just before doing the pipe
operations, and release it just after.
- SAL2-annotate ScmControlService().
- Re-order the ScmControlService() parameters in a more natural way
(image comm pipe, service name, control code; then: arguments for
the control command).
- Improve some DPRINTs.
Hermès Bélusca-Maïto