Fix the issue of the changes of the environment values not being set sometimes through fancy dialog box:
Make sure the environment value buffer is always reallocated before taking the values.
Neither LiveCD nor BootCD 2nd stage are able to use new registry key for videoprt,
as they depend of some PnP entries which are unavailable.
This line was added in a7ebc6bd5c (r43711)
Note that it doesn't change much for ReactOS yet, as neither
videoprt.sys nor win32k.sys take care of this parameter.
This fixes CORE-15708 "PdfSam 3.3.5 setup can not decode bmp"
https://jira.reactos.org/browse/CORE-15708
Wine does not have this issue, but it did not have it back when last sync to
WineStaging-4.18 was done. This commit is as near as possible to actual
wine-7.0-rc3 version. This wine code uses reverse_bgr8 instead of own
convert_rgba_to_bgra, but it leads to wrong colors.
Also generate processor identifier properly based on this value
on the Configuration Manager machine-dependent initialization.
Update processor driver INF file accordingly.
CORE-17970 CORE-14922
- Split buffers on page to prevent non-contiguous memory being passed to driver.
- Protect CIrpQueue::GetMappingWithTag, ReleaseMappingWithTag with spinlock to prevent race conditions
(GetMapping, ReleaseMapping do not need spinlock, they are only called from a service routine).
- Remove ASSERT in CIrpQueue::ReleaseMappingWithTag, when mappings are released out of order. Just ignore
the tag argument and release the next one in the list. This is what windows does, confirmed by calling
PortWavePciStream::ReleaseMapping() with tag argument set to 0, absolutly no difference observed.
Allowing out of order release is essential given that a driver is not permitted to hold a spinlock when calling
ReleaseMapping().
- Remove IIrpQueue::HasLastMappingFailed(), it never worked and there is no way it could work.
CPortPinWavePci::HandleKsStream() call MappingAvailable() non-conditionally, this is what Windows does,
verified by debug prints in ac97 driver.
- Implement CIrpQueue::NumData().
- Remove incorrect interlocked operations/volatile variables and several (now unused) class fields.
- Call UserDereferenceObject function in UserCreateInputContext.
- Don't call UserDereferenceObject against input context at the other places.
CORE-11700
KVM and VBox tests was failing since d5deacd
- Check NULL at UserFreeInputContext and UserDestroyInputContext functions.
- Move UserMarkObjectDestroy into the UserDestroyInputContext function.
CORE-11700
- Modify NtUserCreateInputContext prototype.
- Add UserCreateInputContext helper function.
- Implement NtUserCreateInputContext function by using UserCreateInputContext.
- Call UserCreateInputContext(0) in InitThreadCallback function to create the default input context.
CORE-11700
- Don't store trailing newlines in the exception description text strings.
- Remove unused i386PrintChar().
- Display CR4 in x86.
- Use the "indentation" printf generation trick in order to get aligned
strings for (CF4 and) DR6 and DR7, without having to hardcode the tons
of alignment whitespaces (--> make the strings stored in freeldr shorter).
- Show the IP/ErrorCode/EFlags/GDTR/IDTR/LDTR values vertically aligned.
- Display the stack frames in both x86 and x64 modes.
- Adjust the instruction pointer when a BREAKPOINT or OVERFLOW exception
arises, so that the offending instruction can show up in the instruction
stream.
CORE-16748
- Display the correct TR register value.
- Ensure that the x86 segment register values displayed are really
2-byte long.
Segment registers are intrinsically 16 bits. Even if the x86
KTRAP_FRAME structure stores them as ULONG, only their lower 16 bits
are initialized. We thus cast them to USHORT before display.
These segment registers are saved in a stack-based KTRAP_FRAME by the
CPU trap mechanism (for SS), and by 'push CS' etc. instructions for
the others, and from Intel documentation, we know that:
"
If the source operand is a segment register (16 bits) and the operand
size is 64-bits, a zero-extended value is pushed on the stack; if the
operand size is 32-bits, either a zero-extended value is pushed on the
stack or the segment selector is written on the stack using a 16-bit
move. For the last case, all recent Core and Atom processors perform
a 16-bit move, leaving the upper portion of the stack location unmodified.
"
So it may happen, when using the push, that either they get zero-extended,
or garbage gets stored in the higher bits, and these need to be trimmed.
