Using static numbers was a bad idea in the first place, since we already deal with x64, which has different ordinals. Also @ will automatically do the same thing! It does not mean "no ordinal", it only means automatically apply incrementing numbers.
- "warning: comparison of unsigned expression < 0 is always false [-Wtautological-unsigned-zero-compare]"
- "warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]"
CORE-14306
CORE-11637, CORE-12269
- Implement support for remote connections to NT computers to view their
event logs (and the event logs settings). For the moment the remote
computer name specification is is only available via the command-line.
Note that the paths to the event log files need also to be translated
to network-share format.
- Implement loading and saving the settings of the event viewer.
- Implement showing/hiding the events description pane, the ListView
grid, and whether or not to save the EventViewer settings.
- Handle hypertext link click handling for the RichEdit edit box of the
events description dialog.
This has have several benefits for ReactOS Cc:
- It helps reducing potential deadlocks situations in Cc
- It speeds up ReactOS by reducing locks
- It gets us a bit closer to Windows VACB
CORE-14349
The avoids race conditions where attempts to read from disk to
not fully initialized VACB were performed.
Also, added more debug prints in such situations.
CORE-14349
Doing this is not only wrong because it acquires the same spinlock twice,
it also completely breaks the TLB flushing logic in MiMapPageInHyperSpace.
If the PTE with Offset 1 is still valid when a wrap-around to 0 happens,
the TLB flush on wrap-around will not clear the entry for this previous page.
After another loop around all hyperspace pages, page 1 is re-used but its
TLB entry has not been flushed, which may result into incorrect translation.
This makes the function return the error instead of continuing and
performing use-after-frees operations.
This is likely to be a forgotten return!
CID 1434254, 1434268
Because we can encounter pending interrupts repeatedly,
HalpEndSoftwareInterrupt and HalEndSystemInterrupt already clean up the stack
space for their arguments (done for CORE-11123/CORE-14076).
However these functions are called from C functions such as KiInterruptDispatch
and HalpDispatchInterrupt2[ndEntry]. These callers also use up stack space,
and it is unknown how much.
To fix this, we simply reset the stack pointer to the location of the trap
frame, which is where it points during a first-level dispatch. This cleans
up the stack usage of any callers higher up, and is okay because a return
will happen through the trap frame anyway.
Dedicated to Pierre.
- Don't hardcode a buffer length in ExpandEnvironmentStringsW() call.
- If no file name is associated to a log (ErrorLog->FileName == NULL),
don't try to attempt looking at its file properties. This also allows
avoiding a crash in the FindFirstFileW() call under certain conditions
on Windows.
