JIRA issue: CORE-14177
JIRA issue: CORE-17482
- Add SHELL_InvokePidl helper
function.
- Call SHParseDisplayName and
SHELL_InvokePidl in a specific
condition.
- Fix typos in the Release and Renew functions. The typo caused the functions to work on the first adapter only.
- Fix a typo in the german translation.
Refactoring. Optimize for speed.
JIRA issue: CORE-12619
- Update file headers.
- Make some parameter type LPITEMIDLIST
LPCITEMIDLIST (Add const).
- Add OnChangeNotify method.
- Use SHCNRF_NewDelivery method for speed.
- Add some SAL annotations.
In order for the NT power manager to interact with the Win32 subsystem (thus the whole rest of the system), the Win32 kernel-mode subsystem provides a mechanism that communicates with the kernel power manager via power callouts (aka power requests as per Windows' PDB symbols).
Such mechanism enters in action as soon as Win32 callout routines are estabilished with the PsEstablishWin32Callouts() function.
The NT power manager, the power policy manager respectively, invokes a power callout to denote an exceptional phenomena as a result of power policies or capabilities changes, turning ON/OFF the display, a system time change has occurred, etc.
Such scenarios are described as power events of which the NT power manager sends a WIN32_POWEREVENT_PARAMETERS packet to Win32k via the estabilished "PowerEventCallout" pointer function callout.
For other callouts that inform the Win32 subsystem of impeding power state changes across the system or devices, these are sent as WIN32_POWERSTATE_PARAMETERS packets with its own separate callout.
The purpose of such mechanism is to give Win32k the opportunity to do power related tasks and alert every application of such power events in accordance with what it gets notified by the NT power manager.
Currently this patch stubplements this mechanism in ROS, it is only just the barebones for now. The development of the Win32 power manager will go in parallel with the kernel power manager development (expand, improve, fix the code of issues that whatever may arise).
So far only the PsW32SystemTime power event is implemented for the moment being. This work was decoupled from PR #5719 to avoid clobbering it too much.
=== TODO ===
- Implement power states management communication with the kernel power manager
- Implement the rest of the power events in IntHandlePowerEventWorker
- Implement power event handling in CSRSS (or WinSrv?) which handles any of the events that could not be handled by Win32k otherwise
- Estabilish the power state callout in PsEstablishWin32Callouts() (currently there is no a pointer function that gets assigned to such callout)
CORE-18969
Don't free the linked font name if it's already NULL. Since it is allocated only once (when loading the font name from Registry), it should be freed only once too. All subsequent freeing attempts will result in invalid pool freeing.
This fixes the 0xC2 BAD_POOL_CALLER bugcheck when trying to resize window (and draw more text) from soundcloud.com in K-Meleon 76.5.4 Goanna engine and when switching between channels (during redrawing the text) in DiscordMessenger v1.06 Beta.
Addendum to 0f9e889736.
CORE-19681
CORE-18139
When a partition is created, PartMgr notifies the volume manager
(FTDisk on Windows <= 2003, VolMgr on Vista+) of its presence.
(Note that currently in ReactOS, our partmgr does the job of both
PartMgr *AND* VolMgr.)
The VolMgr then sends a `GUID_DEVINTERFACE_VOLUME` PnP notification,
which is handled by the mount manager (MountMgr) as part of a
`GUID_DEVICE_INTERFACE_ARRIVAL` notification:
```
MountMgr!MountMgrMountedDeviceNotification -> MountMgrMountedDeviceArrival
followed by
MountMgr!MountMgrTargetDeviceNotification
```
When a partition is deleted, via e.g. Disk Management or DiskPart,
it can be observed, on Windows, that the PartMgr gets notified by
the PnP manager, as part of QueryDeviceRelations. Before actually
removing the partition, it notifies the VolMgr. The latter invalidates
any volume mounted on that partition (`*PartitionRemoved*` functions
for basic volumes), then requests (`*DeleteMountPoints` function)
the MountMgr to delete all the mount points associated to the volume:
```
VolMgr!*DeleteMountPoints
-> MountMgr!MountMgrDeviceControl -> MountMgrDeletePoints
```
**** THIS is the new functionality that is implemented for ReactOS ****
**** in the present commit. ****
Following this, a subsequent PnP notification is sent, which calls
```
MountMgr!MountMgrTargetDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
(Note that this observation somewhat invalidates the modification
made in ReactOS commit 62a4f9d42b : our MountMgr placed in Windows
*WOULD* receive a `GUID_TARGET_DEVICE_REMOVE_COMPLETE` target-device
notification...)
Finally, a `GUID_DEVICE_INTERFACE_REMOVAL` PnP notification is sent
to the MountMgr:
```
MountMgr!MountMgrMountedDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
Fix font enumeration and AutoComplete on %WINDIR%\Fonts.
JIRA issue: CORE-9281
"Replace if (dwFlags ==
SHGDN_FORPARSING)" with
"if (dwFlags & SHGDN_FORPARSING)".
CORE-11569, CORE-19684
Addendum to commit 71bed0f5f8 (PR #7123).
The problem in uxtheme was introduced in commit 685084b63c (as part
of a fix for CORE-17203), because it was a copy-paste and adaptation
of the corresponding code in `ntuser/nonclient.c!NC_DoButton()`.
The bugs in `win32ss/user/ntuser/defwnd.c` (and `nonclient.c` as fixed by
the previous commit) were in turn introduced from the migration of menu
and related code from user32 to win32k, see commit 6dfa71c487 (r68904).
CORE-8002
The switch enables or disables file/path completion in a unique
CMD instance. The defaulted values for the completion characters
are those mentioned in CMD's help (see also MSDN[^1]):
File: Ctrl-F (0x06); Directory: Ctrl-D (0x04)
Manual tests show that only /F:OFF explicitly disables completion.
Otherwise, using /F(anything else following) always enables completion
with the specific values described above.
[^1]: For additional details, see also
https://technet.microsoft.com/en-us/library/cc978715.aspxhttps://technet.microsoft.com/en-us/library/cc940805.aspx
Unexpectedly remaining
AutoComplete list is annoying.
JIRA issue: CORE-19685
- Add CAutoComplete::
m_bEditHasFocus to watch
focus.
- Update m_bEditHasFocus on
WM_SETFOCUS and
WM_KILLFOCUS messages on
Edit window procedure.
- Don't open AutoComplete list
when m_bEditHasFocus was
FALSE.
