ffb05406e6
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 .) |
||
|---|---|---|
| .github | ||
| .theia | ||
| base | ||
| boot | ||
| dll | ||
| drivers | ||
| hal | ||
| media | ||
| modules | ||
| ntoskrnl | ||
| sdk | ||
| subsystems | ||
| win32ss | ||
| .clang-format | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmessage | ||
| .gitpod.Dockerfile | ||
| .gitpod.yml | ||
| apistatus.lst | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| configure.cmd | ||
| configure.sh | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| COPYING.ARM | ||
| COPYING.LIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| CREDITS | ||
| Doxyfile | ||
| INSTALL | ||
| overrides-gcc.cmake | ||
| overrides-msvc.cmake | ||
| PreLoad.cmake | ||
| PULL_REQUEST_MANAGEMENT.md | ||
| README.md | ||
| toolchain-clang.cmake | ||
| toolchain-gcc.cmake | ||
| toolchain-msvc.cmake | ||
Quick Links
Website • Official chat • Wiki • Forum • Community Discord • JIRA Bug Tracker • ReactOS Git mirror • Testman
What is ReactOS?
ReactOS™ is an Open Source effort to develop a quality operating system that is compatible with applications and drivers written for the Microsoft® Windows™ NT family of operating systems (NT4, 2000, XP, 2003, Vista, 7).
The ReactOS project, although currently focused on Windows Server 2003 compatibility, is always keeping an eye toward compatibility with Windows Vista and future Windows NT releases.
The code of ReactOS is licensed under GNU GPL 2.0.
Product quality warning
ReactOS is currently an Alpha quality operating system. This means that ReactOS is under heavy development and you have to be ready to encounter some problems. Different things may not work well and it can corrupt the data present on your hard disk. It is HIGHLY recommended to test ReactOS on a virtual machine or on a computer with no sensitive or critical data!
Building
To build the system it is strongly advised to use the ReactOS Build Environment (RosBE). Up-to-date versions for Windows and for Unix/GNU-Linux are available from our download page at: "Build Environment".
Alternatively one can use Microsoft Visual C++ (MSVC) version 2015+. Building with MSVC is covered here: "Visual Studio or Microsoft Visual C++".
See "Building ReactOS" article for more details.
Binaries
To build ReactOS you must run the configure script in the directory you want to have your build files. Choose configure.cmd or configure.sh depending on your system. Then run ninja <modulename> to build a module you want or just ninja to build all modules.
Bootable images
To build a bootable CD image run ninja bootcd from the build directory. This will create a CD image with a filename bootcd.iso.
You can always download fresh binary builds of bootable images from the "Daily builds" page.
Installing
By default, ReactOS currently can only be installed on a machine that has a FAT16 or FAT32 partition as the active (bootable) partition. The partition on which ReactOS is to be installed (which may or may not be the bootable partition) must also be formatted as FAT16 or FAT32. ReactOS Setup can format the partitions if needed.
Starting with 0.4.10, ReactOS can be installed using the BtrFS file system. But consider this as an experimental feature and thus regressions not triggered on FAT setup may be observed.
To install ReactOS from the bootable CD distribution, extract the archive contents. Then burn the CD image, boot from it, and follow the instructions.
See "Installing ReactOS" Wiki page or INSTALL for more details.
Testing
If you discover a bug in ReactOS search on JIRA first - it might be reported already. If not report the bug providing logs and as much information as possible.
See "File Bugs" for a guide.
NOTE: The bug tracker is not for discussions. Please use our official chat or our forum.
Contributing 
We are always looking for developers! Check how to contribute if you are willing to participate.
Legal notice: If you have seen proprietary Microsoft Windows source code (including but not limited to the leaked Windows NT 3.5, NT 4, 2000 source code and the Windows Research Kernel), your contribution won't be accepted because of potential copyright violation.
Try out cloud-based ReactOS development using Gitpod and Docker:
You can also support ReactOS by donating! We rely on our backers to maintain our servers and accelerate development by hiring full-time devs.
More information
ReactOS is a Free and Open Source operating system based on the Windows architecture, providing support for existing applications and drivers, and an alternative to the current dominant consumer operating system.
It is not another wrapper built on Linux, like WINE. It does not attempt or plan to compete with WINE; in fact, the user-mode part of ReactOS is almost entirely WINE-based and our two teams have cooperated closely in the past.
ReactOS is also not "yet another OS". It does not attempt to be a third player like any other alternative OS out there. People are not meant to uninstall Linux and use ReactOS instead; ReactOS is a replacement for Windows users who want a Windows replacement that behaves just like Windows.
More information is available at: reactos.org.
Also see the media/doc subdirectory for some sparse notes.
Who is responsible
Active devs are listed as members of GitHub organization. See also the CREDITS file for others.
Code mirrors
The main development is done on GitHub. We have an alternative mirror in case GitHub is down.
There is also an obsolete SVN archive repository that is kept for historical purposes.