f4de5ceb9e
During an open or create procedure of a registry key, the registry parser grabs a key control block (KCB) from the parser object and uses its information to do the necessary work in order to obtain a pointer to the newly created or opened registry key. However, the registry parsers faces several issues. First, we don't do subkey cache cleaning information against gathered KCBs so whenever we do a registry parse we end up with KCBs that have cache inconsistencies. Moreover we don't do any locking of whatever KCB we are grabing during a parse procedure. === PROPOSED CHANGES === * Implement CmpComputeHashValue and CmpLookInCache functions. With CmpComputeHashValue we can compute the convkey hashes of each subkey in the path name of a key so we can lock them with CmpBuildAndLockKcbArray. CmpLookInCache is a function that searches for the suitable KCB in the cache. The factors that determine if a KCB is "suitable" are: -- the currently found KCB in the hash list has the same levels as that of the given KCB from the parse object; -- The key names from the computed hash values match with the block name of the KCB; -- The currently found KCB is not deleted. The KCB will be changed if the key path name points to a partial match name in the cache. The KCB from the parse object will be used if we have a full match of remaining levels. * Add missing CMP_LOCK_HASHES_FOR_KCB flags on CmpCreateKeyControlBlock calls that create KCBs during a parse procedure. Such lock has to be preserved until we're done with the registry parsing. * On CmpDoCreateChild, preserve the exclusive lock of the KCB when we are enlisting the key body. * On CmpDoCreate, make sure that the passed parent KCB is locked exclusively and lock the hiver flusher as we don't want the flusher to kick in during a key creation on the given hive. Cleanup the subkey info when we're creating a key object. Also implement missing cleanup path codes. Furthermore, avoid key object creation if the parent KCB is protected with a read-only switch. * Soft rewrite the CmpDoOpen function, namely how we manage a direct open vs create KCB on open scenario. When a KCB is found in cache avoid touching the key node. If the symbolic link has been resolved (aka found) then lock exclusively the symbolic KCB. Otherwise just give the cached KCB to the caller. If it were for the caller to request a KCB creation, we must check the passed KCB from the parser object is locked exclusively, unlike on the case above the caller doesn't want to create a KCB because there's already one in the cache. We don't want anybody to touch our KCB while we are still toying with it during its birth. Furthermore, enlist the key body but mind the kind of lock it's been used. * On CmpCreateLinkNode, avoid creating a key object if the parent KCB is protected with a read-only switch. In addition, add missing hive flusher locks for both the target hive and its child. Cleanup the subkey information of the KCB when creating a link node, this ensures our cached KCB data remains consistent. * Do a direct open on CmpParseKey if no remaining subkey levels have been found during hash computation and cache lookup, in this case the given KCB is the block that points to the exact key. This happens when for example someone tried to call RegOpenKeyExW but submitting NULL to the lpSubKey argument parameter. CORE-10581 ROSTESTS-198 |
||
|---|---|---|
| .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 | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.ARM | ||
| COPYING.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.