[NTOS:KE/x64] Implement Kd processor switching

[NTOS:KD64] Format string of KdpDprintf can be const.

[NTOS:KD64] Implement KdLogDbgPrint() for the WinDbg !dbgprint command.

See this command's documentation:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-dbgprint
and the section

[NTOS:KD64] Implement KdLogDbgPrint() for the WinDbg !dbgprint command.

See this command's documentation:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-dbgprint
and the section "DbgPrint buffer and the debugger"
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/reading-and-filtering-debugging-messages#dbgprint-buffer-and-the-debugger
for more details.

- Loosely implement the function, based on our existing circular printout
buffers in kdio.c.
- Enable its usage in the KdpPrint() and KdpPrompt() functions.

Notice that this function will *only* capture the strings being sent **to**
the debugger, and not the strings the debugger itself produce. (This means
that we cannot use the KdPrintCircularBuffer as a replacement for our
KDBG dmesg one, for example...)

How to test:
Run ReactOS under WinDbg, and use the !dbgprint command to view the
buffer. You can also use the Memory Window, place yourself at the
address pointed by KdPrintCircularBuffer and KdPrintWritePointer, and
read its contents.

What you should observe:
Prior notice: The circular buffer in debug builds of ReactOS and Windows
is 0x8000 bytes large. In release builds, its size is down to 0x1000.
1- When you start e.g. the 2nd-stage GUI installation of ReactOS, going
past the initial "devices installation" and letting it stabilize on
the Welcome page, break into WinDbg and run the !dbgprint command. You
should notice that the end of its output is weirdly truncated, compared
to what has been actually emitted to the debug output. Comparing this
with the actual contents of the circular buffer (via Memory Window),
shows that the buffer contents is actually correct.
2- Copy all the text that has been output by the !dbgprint command and
paste it in an editor; count the number of all characters appearing +
newlines (only CR or LF), and observe that this number is "mysteriously"
equal to 16384 == 0x4000.
3- Continue running ReactOS installation for a little while, breaking back
back into WinDbg and looking at !dbgprint again. Its output seems to be
still stopping at the same place as before (but the actual buffer memory
contents shows otherwise). Continue running ROS installation, and break
into the debugger when ROS is about to restart. You should now observe
that the dbgprint buffer rolled over:
dd nt!KdPrintRolloverCount shows 1.
Carefully analysing the output of !dbgprint, however, you will notice
that it looks a bit garbage-y: the first part of the output is actually
truncated after 16384 characters, then you get a second part of the
buffer showing what ReactOS was printing while shutting down. Then
you get again what was shown at the top of the !dbgprint output.
(Of course, comparing with the actual contents of the circular buffer
in memory shows that its contents are fine...)

The reason of these strange observations, is because there is an intrinsic
bug in the !dbgprint command implementation (in kdexts.dll). Essentially,
it displays the contents of the circular buffer in two single dprintf()
calls: one for the "older" (bottom) part of the buffer:
[WritePointer, EndOfBuffer]
and one for the "newer" (upper) part of the buffer:
[CircularBuffer, WritePointer[ .
The first aspect of the bug (causing observation 3), is that those two
parts are not necessarily NULL-terminated strings (especially after
rollover), so for example, displaying the upper part of the buffer, will
potentially also display part of the buffer's bottom part.
The second aspect of the bug (explaining observations 1 and 2), is due
to the implementation of the dprintf() function (callback in dbgenv.dll).
There, it uses a fixed-sized buffer of size 0x4000 == 16384 characters.
Since the output of the circular buffer is not done by little chunks,
but by the two large parts, if any of those are larger than 0x4000 they
get truncated on display.
(This last observation is confirmed in a completely different context by
https://community.osr.com/discussion/112439/dprintf-s-max-string-length .)

show more ...

[NTOS:KD64] Correctly initialize the KdPrint buffer data in KdDebuggerDataBlock so as to fix the WinDbg !dbgprint command.

Now, !dbgprint just shows an empty log (since we don't fill it), instead
of

[NTOS:KD64] Correctly initialize the KdPrint buffer data in KdDebuggerDataBlock so as to fix the WinDbg !dbgprint command.

Now, !dbgprint just shows an empty log (since we don't fill it), instead
of showing the following error:

kd> !dbgprint
Can't find DbgPrint buffer

show more ...

[NTOS:KD] Annotate KdInitSystem and remove redundant declaration in kd.h

[NTOS:KD][NTOS:KD64][NTOS:KDBG] Fix IRQL & spinlock use

KD64: Raise to HIGH_LEVEL when entering trap
KDBG: lower to DISPATCH_LEVEL when applying IRQL hack & use a worker thread to load symbols
KD&KD

[NTOS:KD][NTOS:KD64][NTOS:KDBG] Fix IRQL & spinlock use

KD64: Raise to HIGH_LEVEL when entering trap
KDBG: lower to DISPATCH_LEVEL when applying IRQL hack & use a worker thread to load symbols
KD&KDBG: Actually unload symbols when required

show more ...

[NTOS:KD] Merge KdpReportExceptionStateChange() with kd64 version

[NTOS:KD] Merge KdpReport() with kd64 version

[NTOS:KD64] Fix 'MAX_KD_COMPONENT_TABLE_ENTRIES' value (#2992)

Addendum to ceb58c8.

[NTOS][SDK] Add new kernel debug filters that have been added in Win8 and Win10; they can be useful for us.

[NTOS:KD64] Some code formatting + add SAL2 annotations to the functions that are going to be involved in the next commit.

+ s/ReturnStatus/Status/ , and get rid of Win32 LPSTR and replace by
PCHA

[NTOS:KD64] Some code formatting + add SAL2 annotations to the functions that are going to be involved in the next commit.

+ s/ReturnStatus/Status/ , and get rid of Win32 LPSTR and replace by
PCHAR (since the concerned code deals with counted strings).

show more ...

[NTOS] Complete the support of Debug Filters. CORE-13529

- KD64: Update the list of supported Debug Filter Masks (KdComponentTable)
with the more up-to-date one from KDBG, that includes some compo

[NTOS] Complete the support of Debug Filters. CORE-13529

- KD64: Update the list of supported Debug Filter Masks (KdComponentTable)
with the more up-to-date one from KDBG, that includes some components
that have been added in Vista+, but some of which we also use in ReactOS.

- NtQueryDebugFilterState(), NtSetDebugFilterState() and KdpPrint():
Add the Vista+ behaviour or falling back to the DEFAULT component ID
settings for unknown Components (compiled in only wheen NTDDI_VERSION >= NTDDI_VISTA).
+ Remove redundant comments and update these functions with SAL2 annotations.

- KDBG: Add extra documentation for the debug filter components list.

- CONFIG: Load all the supported Debug Filter Masks settings from the
registry.

show more ...

[NTOS] Add some header guards.

Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys.

Create the AHCI branch for Aman's work

svn path=/branches/GSoC_2016/AHCI/; revision=71203

Create a branch for console restructuration work.

svn path=/branches/condrv_restructure/; revision=63104

[SHELL/EXPERIMENTS]
* Create a branch for some evul shell experiments.

svn path=/branches/shell-experiments/; revision=61927

Create a branch for Aleksandar Andrejevic for his work on NTVDM. See http://jira.reactos.org/browse/CORE-7250 for more details.

svn path=/branches/ntvdm/; revision=59241

Create this branch to work on loading of different Kernel-Debugger DLL providers, and see whether it is possible to move KDBG from ntoskrnl to a new DLL called, say, KDROSDBG.DLL.

The idea then woul

Create this branch to work on loading of different Kernel-Debugger DLL providers, and see whether it is possible to move KDBG from ntoskrnl to a new DLL called, say, KDROSDBG.DLL.

The idea then would be to have the following behaviour (when specifying the following options in the kernel command line):

/DEBUGPORT=COMi --> load KDCOM.DLL and use COMi port (i == 1,2,3,4) if possible.
/DEBUGPORT=FOO --> load KDFOO.DLL (useful for KDUSB.DLL, KD1394.DLL, KDBAZIS.DLL for VirtualKD, etc...)
/DEBUGPORT=ROSDBG:[COMi|SCREEN|FILE|GDB|...] --> load KDROSDBG.DLL which contains the ROS kernel debugger, and use COMi or SCREEN or... as output port.

svn path=/branches/kd++/; revision=58883

show more ...

Branching for 0.3.15 release after two days of no response from a certain sphere of plasma.

svn path=/branches/ReactOS-0.3.15/; revision=58636

Create a branch for working on csrss and co.

svn path=/branches/ros-csrss/; revision=57561

[USB-BRINGUP-TRUNK]
- Create a branch to do a proper merge of USB work from a trunk base instead of from cmake-bringup
- In the future, DO NOT under any circumstances branch another branch. This lead

[USB-BRINGUP-TRUNK]
- Create a branch to do a proper merge of USB work from a trunk base instead of from cmake-bringup
- In the future, DO NOT under any circumstances branch another branch. This leads to merge problems!

svn path=/branches/usb-bringup-trunk/; revision=55018

show more ...

* Branch for the 0.3.14 release.

svn path=/branches/ros-branch-0_3_14/; revision=55011

[WLAN-BRINGUP]
- Create a branch to drop my ndisuio work

svn path=/branches/wlan-bringup/; revision=54809

This really needs to go in a branch. It needs heavy testing and can't coincide with the current shell32 due to PSDK interface changes

svn path=/branches/shell32_new-bringup/; revision=51893