While PROFILE_LEVEL is defined as 27 on x86, this does not match the vector for the profiling interrupt, which is 0xFD (see https://community.osr.com/t/odd-ioapic-output/45216), implying IRQL 31.
Fixes boot with x86 APIC hal (CORE-20093)
Write both high and low 32 bits of ICR in ApicRequestSelfInterrupt. In VMs we get away with only writing the low 32 bits, but actual hardware doesn't always accept that.
JIRA issue: CORE-18944
EDIT_EM_GetHandle unlocks the handle,
so the next EM_SETHANDLE handler
shouldn't unlock the unlocked text.
Don't unlock the handle when es->text
was NULL on EM_SETHANDLE
message handling.
CORE-18855
Add a call to _ChangeHotItem(NULL, -1, 0) in CMenuBand::OnSelect(MPOS_CANCELLEVEL) which causes to deselect currently selected item the moment the menu bands (including start menu) are closing.
Start Menu is not destroyed when it's closed so its allocated resources can be re-used next time user wants to open it, so to keep this behavior and still not having an item selected every time you open the start menu, you have to deselect the currently selected item.
Note: A bug in the classic button prevents it from sending CDDS_POSTPAINT if the button has no text, the button resource has a space in its text as a workaround.
Since the setuplib.dll isn't available after installing ReactOS, build
instead a static library that is then used for the dll, and linked into
the setuplib_unittest, so that it can be run in our test-suite.
Addendum to commit d7c1d220.
This header is not to be used outside of dhcpcsvc because it contains the data structures for the communication between the client and the server part within dhcpcsvc. That is why it is moved inside of dhcpcsvc and renamed to rosdhcp_pipe.h.
CORE-20107
Improve the minimal handling done in the fall-back KdSend/ReceivePacket()
routines when they are invoked by KD64 (in Release build).
Part of my `kdbg_tests_kdio_split` branch for splitting kd/kdio.c
into a separate KD dll.
KdSendPacket:
- Silently ignore PACKET_TYPE_KD_STATE_CHANGE32/64 DbgKdLoadSymbolsStateChange notification.
- Partially manage and log the unhandled PACKET_TYPE_KD_STATE_CHANGE DbgKdExceptionStateChange notification.
- Log other unhandled PACKET_TYPE_KD_STATE_CHANGE32/64 and PACKET_TYPE_KD_STATE_MANIPULATE notifications.
When KdSendPacket receives the DbgKdExceptionStateChange notification,
it cannot handle it (no debugger is there!). However, we need to claim
the debugger to be present, so that its KD64 caller: KdpSendWaitContinue(),
can call back KdReceivePacket(PACKET_TYPE_KD_STATE_MANIPULATE), which,
in turn, informs KD that the exception cannot be handled, by returning
a failure code in the ManipulateState's ContinueStatus.
During bugchecks, this allows KiBugCheckDebugBreak() to not loop infinitely,
but instead fall back into calling HalHaltSystem() to halt the computer.
When KDBG isn't included in the kernel (Release build), the fall-back
KdSend/ReceivePacket() routines are invoked by KD64. A minimal handling
of the basic packets needs to be done:
PACKET_TYPE_KD_STATE_CHANGE32/64 for KdSendPacket(),
and PACKET_TYPE_KD_POLL_BREAKIN, PACKET_TYPE_KD_STATE_MANIPULATE
for KdReceivePacket().
Addendum to commit 2046a17ef4
CORE-20107
RtlpBreakWithStatusInstruction is just a label for KD.
On machines that have register calling conventions (basically all except
x86), the `Status` parameter for `DbgBreakPointWithStatus` is stored in
the first argument register.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-dbgbreakpointwithstatus
On the x64 platform, `DbgBreakPointWithStatus` only uses the ECX register
and leaves EAX untouched. Verified on Windows.
Implements a couple of extra commands in IShellBrowser and adds support for the AppKeys fallback registry key (used when the foreground application does not handle the command).
They were introduced when MEMROY_AREAs and VAD still lived in different tables to synchronize between them. Since some time MEMORY_AREAs are special VADs and live in the same table as ARM³ VADs, but with flags to distinguish them. Since then the only reason that the fake MEMORY_AREAs still existed was to determine whether a VAD that is a MEMORY_AREA is still handled by ARM³ (which is the case for some kernel VADs, like for paged pool). This is no longer required as it is now determined by a 2nd flag in the VAD itself.
Additionally, we tried to insert the fake MEMORY_AREAs into the VAD table, which would fail, because it was already occupied by the ARM³ VAD, but the failure was ignored.
- Implement MiLocateVad and make MiLocateAddress call it
- Use MiLocateVad in MmAccessFault to get the VAD
- Check VadFlags for whether this is an ARM³ VAD/MEMORY_AREA
Use this instead of MmLocateMemoryAreaByRegion to determine whether we can inert a section at the requested base address. This will be required to get rid of fake memory areas allocated for each ARM³ VAD.
In MmCleanProcessAddressSpace we already delete VADs that are RosMm memory areas by calling MiRosCleanupMemoryArea, so we never reach the later check. This code path is from a time when VADs and memory areas lived in different tables, which is no longer the case.
