For each device we must first try to read its AllocConfig resource list. If its AllocConfig resource list is not available, try to read its BootConfig resource list.
* [NTDLL_WINETEST] `test_query_process_debug_object_handle()`: one WINESYNC
Cherry-pick WineTest part of:
52d733b5c4
server: Implement retrieving the debug object of a process.
by: Alexandre Julliard <julliard@winehq.org>
* [NTOS:PS] Fix `NtQueryInformationProcess(ProcessDebugObjectHandle)`
Close the retrieved `DebugPort` on failure.
Addendum to commit 1e172203a (r55734).
* [NTOS:PS] Optimize `NtQueryInformationProcess(ProcessWow64Information)` on 32-bit.
No need to do the ExAcquire/ReleaseRundownProtection rigamarole since
we aren't retrieving the `Process->Wow64Process` on 32-bit builds.
Addendum to commit 1e172203a (r55734).
* [NTOS:PS] Fix `NtQueryInformationProcess(ProcessExecuteFlags)`
s/return/break/ on a failure case.
Addendum to commit 1e172203a (r55734).
* [NTOS:PS] NtQueryInformationProcess(): Optimize `*ReturnLength` assignment
Enter the SEH block only if we know we'll have to set `*ReturnLength` on return.
Addendum to commit 2278c2914 (r23175).
This feature is used to report errors when `LoadUserProfile()` fails.
It is also meant to be used by other functions in the future.
The error dialog is shown only when the `PI_NOUI` flag is _NOT_ set
in `PROFILEINFO::dwFlags`.
- Add support for retrieving USERENV-specific registry policies,
in a systematic way.
- Add support for "timed" dialogs that automatically close after
a given timeout has elapsed.
The default timeout is controlled by the `"ProfileDlgTimeOut"` policy:
https://www.visualautomation.com/comprod/secure6/profile_.htmhttps://www.infania.net/misc/kbarchive/kb/196/Q196284/index.html
- TODO for the future: report the error in the event log.
- `LoadUserProfileW()`: Reset `ret` to `FALSE` after the call to
`CreateUserProfileW()`; this allows to return failure in case
any other function calls down the line fails. (`ret` is set to
`TRUE` only when everything has succeeded.)
This PR resolves a bug of #8094. #8094
correctly validates the flags. TPM_SYSTEM_MENU is an internal flag
and not a valid flag for TrackPopupMenu.
Thus, calling TrackPopupMenu.TPM_SYSTEM_MENU
in User32DefWindowProc was wrong.
This caused failure of taskbar context
menu.
JIRA issue: CORE-20238
- Move WM_POPUPSYSTEMMENU
message handling of user32 into
win32k.sys!IntDefWindowProc.
- Use win32k.sys!IntTrackPopupMenuEx
instead of user32!TrackPopupMenu
in handling of WM_POPUPSYSTEMMENU.
* Disable most apphelp:env and some apphelp:db tests on x64 due to structure differences breaking these tests.
* Add new tag lists for Windows 8.1 and Windows 10 in apphelp:apphelp test.
* Make a few changes to accept either Windows 10 or Windows 8.1 and older behavior in apphelp:apphelp test.
* Create new shimdata structures for Windows 8 and Windows Vista.
* Add attribute size definitions for Vista, 8.1, and 10.
* Create new shim data validation functions for Vista and 8.1.
* Use local time instead of UTC time for shim db version. This fixes test failures when the day in local time and the day in UTC are different.
- Replace WH_KEYBOARD_LL hook and
handler with WH_KEYBOARD and
adapted KeyboardProc.
- Update key-state checks to use
HIWORD(lParam) flags and
GetKeyState.
Implementing missing features...
JIRA issue: CORE-19361
- Delete documentmgr.c and add
documentmgr.cpp.
- Make ITfDocumentMgr and
IEnumTfContexts C++ code.
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).
