0ad65796bb
CORE-12149 VIDEOPRT: ========= Improve interfacing with INBV, so as to detect when an external module acquired INBV display ownership, and whether ownership is being released later on. (This does NOT rely on hooking!) For this purpose we improve the IntVideoPortResetDisplayParameters(Ex) callback that gets registered with an InbvNotifyDisplayOwnershipLost() call during initialization, and we add a monitoring thread. The callback is called whenever an external module calls InbvAcquireDisplayOwnership(), for example the bugcheck code or the KDBG debugger in SCREEN mode. When this happens, a flag that tells the monitoring thread to start monitoring INBV is set (ReactOS-specific), and the display adapters get reset with HwResetHw() (as done on Windows). Due to the fact that this INBV callback can be called at *ANY* IRQL, we cannot use dispatcher synchronization mechanisms such as events to tell the INBV monitoring thread to start its operations, so we need to rely instead on a flag to be set. And, since INBV doesn't provide with any proper callback/notification system either, we need to actively monitor its state by pooling. To reduce the load on the system the monitoring thread performs 1-second waits between each check for the flag set by the INBV callback, and during checking the INBV ownership status. When the INBV ownership is detected to be released by an external module, the INBV callback is re-registered (this is *MANDATORY* since the external module has called InbvNotifyDisplayOwnershipLost() with a different callback parameter!), and then we callout to Win32k for re-enabling the display. This has the virtue of correctly resetting the display once the KDBG debugger in SCREEN mode is being exited, and fixes CORE-12149 . The following additional fixes were needed: VIDEOPRT & WIN32K: ================== Remove the registration with INBV that was previously done in a ReactOS- specific hacked IRP_MJ_WRITE call; it is now done correctly during the video device opening done by EngpRegisterGraphicsDevice() in the VIDEOPRT's IRP_MJ_CREATE handler, as done on Windows. WIN32K: ======= - Stub the VideoPortCallout() support, for VIDEOPRT -> WIN32 callbacks. This function gets registered with VIDEOPRT through an IOCTL_VIDEO_INIT_WIN32K_CALLBACKS call in EngpRegisterGraphicsDevice(). - Only partially implement the 'VideoFindAdapterCallout' case, that just re-enables the primary display by refreshing it (using the new function UserRefreshDisplay()). VIDEOPRT: ========= - PVIDEO_WIN32K_CALLOUT is an NTAPI (stdcall) callback. - In the IntVideoPortResetDisplayParameters(Ex) callback, reset all the "resettable" adapters registered in the HwResetAdaptersList list. We thus get rid of the global ResetDisplayParametersDeviceExtension. - Make the IntVideoPortResetDisplayParameters(Ex) callback slightly more robust (using SEH) against potential HwResetListEntry list corruption or invalid DriverExtension->InitializationData.HwResetHw() that would otherwise trigger a BSOD, and this would be disastrous since that callback is precisely called when INBV is acquired, typically when the BSOD code initializes the display for displaying its information... Extras: - Validate the IrpStack->MajorFunction in IntVideoPortDispatchDeviceControl() and implement IRP_MJ_SHUTDOWN handling. Stub out the other IOCTLs that are handled by VIDEOPRT only (and not by the miniports). - VIDEOPRT doesn't require IRP_MJ_INTERNAL_DEVICE_CONTROL (unused). - Implement IOCTL_VIDEO_PREPARE_FOR_EARECOVERY that just resets the display to standard VGA 80x25 text mode. |
||
|---|---|---|
| .github | ||
| base | ||
| boot | ||
| dll | ||
| drivers | ||
| hal | ||
| media | ||
| modules | ||
| ntoskrnl | ||
| sdk | ||
| subsystems | ||
| win32ss | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmessage | ||
| .travis.yml | ||
| apistatus.lst | ||
| appveyor.yml | ||
| 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 • 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, Seven).
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.
ReactOS is currently an Alpha quality operating system. This means that ReactOS is under heavy development, things may not work well and it can corrupt the data present on your hard disk. It is 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 2010+. Building with MSVC is covered here: "Visual Studio or Microsoft Visual C++".
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.
See "Building ReactOS" for more details.
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 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 #reactos Freenode IRC channel or our forum.
Contributing 
We are always looking for developers! Check how to contribute if you are willing to participate.
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.