+ Improve related comments.
Registry hives are opened in shared read access when NT is loaded in PE
mode (MININT) or from network (the hives residing on a network share).
This is true in particular for the main system hives (SYSTEM, SOFTWARE,
DEFAULT, ...).
However, in PE mode, we can allow other hives, e.g. those loaded by the
user (with NtLoadKey) to be loaded with full read/write access, since we
boot from a local computer.
In particular remove some extra-parentheses around single code tokens,
and replace few "DPRINT1 + while (TRUE);" by UNIMPLEMENTED_DBGBREAK.
+ Improve some comments.
Add a basic IOpenControlPanel implementation that supports Vista canonical registry names.
Implements `control.exe /name company.name [/page id]` and `IOpenControlPanel`
handling of Vista-style canonical registry names.
The documented `Microsoft.*` names don't work because they are simply not
in our registry but "[Executable Control Panel Items](https://learn.microsoft.com/en-us/windows/win32/shell/how-to-register-an-executable-control-panel-item-registration-)" registered by 3rd-party ISVs
will function correctly in control.exe and the COM API.
Notes:
- `IOpenControlPanel` is implemented in CControlPanelFolder.cpp because
it is supposed to have tighter integration with that shell folder than
it does in this PR.
- `IOpenControlPanel` is also supposed to handle .cpl files with canonical
names registered under [`Extended Properties`](https://learn.microsoft.com/en-us/windows/win32/shell/how-to-register-dll-control-panel-item-registration-#step-3) but the control panel folder
does not implement `IShellFolder2::GetDetailsEx` yet, so it will have to wait.
- These "Executable Control Panel Items" are also supposed to be displayed
in the control panel itself but this PR does not address that. The
`ITEMIDLIST` format for those needs investigation...
- The Wow64 handling is perhaps not correct but it does not matter,
`ShellExecuteEx` gets to deal with whatever is in the `...\shell\open\command` key.
`CControlPanelFolder` would have to take more care when it starts
reading those keys so it knows when to append "(32-bit)" to the display name.
- `%s%s` because .cpl canonical names don't have the `::` prefix according
to Geoff Chappell.
- Always returns `CPVIEW_CLASSIC` because our `CControlPanelFolder` does
not support the category view.
GCC 8.4 and Clang 13.0.1:
`cc1: note: unrecognized command-line option ‘-Wno-deprecated-non-prototype’ may have been intended to silence earlier diagnostics`
Addendum to commit 4e3bf252d
* [SDK][VIRTIO][NETKVM] Make VirtIO a separate library
This is to avoid code duplication when more VirtIO drivers are brought in. This will also be used on development of a VirtIO XDDM GPU Driver.
* [VIRTIO] Sync with upstream
This is needed, because Wine code expects RtlUnwind to restore the non-volatile registers, before returning, but ours / the native one doesn't do that.
Should fix CORE-19392 and CORE-19397
Supporting TIPs...
JIRA issue: CORE-19360
- Fix some mistakes of
CUIFButton::OnMouseIn and
CUIFButton::OnMouseOut.
- Fix some mistakes of CUIFObject
and CUIFWindow.
Improve readability and reduce code.
JIRA issue: CORE-19268
- Delete cicSetLayout function and
use gdi32!SetLayout function directly.
- Don't use ::SetRect and ::SetRectEmpty.
- s/CUIFButton::m_dwUnknown10/CUIFButton::m_bPressed/.
- Reduce lines.
Supporting TIPs...
JIRA issue: CORE-19360
- Implement cicInitUIFLib and cicDoneUIFLib functions.
- Use them in msctfime and msutb.
- Add CUIFSystemInfo class in <cicero/cicuif.h>.
Supporting TIPs... UIComposition class requires a caret class.
JIRA issue: CORE-19360
- Add <cicero/ciccaret.h> header.
- Add CicCaret class for displaying a caret.
Use new(cicNoThrow) instead of plain operator new.
JIRA issue: CORE-19360
- Define CicNoThrow structure and
cicNoThrow macro in <cicero/cicbase.h>.
- Use new(cicNoThrow) instead of
plain operator new.
This is actually a Vista+ function, but we need it enable umpnpmgr.dll to notify services of device events. Up until WinXP it was possible to make direct calls to the service manager by umpnpmgr.dll because umpnpmgr.dll was loaded into the service manager process. From Vista onwards umpnpmgr.dll is run as a separate service host process. And since ReactOS always ran umpnpmgr.dll as a separate process, we have to use the Vista RPC functions to notify services.
