[NTOS]: Improve a bit CmpDeepCopyKeyInternal():

- Normally getting the SrcNode and DestNode must succeed (checked with assert);

- Set the DestNode Flags member, in particular when this is the new root node of the saved registry hive;

- Copy the key class cell (OK), and the key security cell (currently done in a hackish way; proper way: call the CmpAssignSecurity* function);

- Add more clean-up on failure;

- Warn in code about the fact that CmpDeepCopyKeyInternal is recursive, and will easily exhaust kernel stack. This function will need to be reworked later...

CORE-10793 CORE-10796

    • -11
    • +81
    /trunk/reactos/ntoskrnl/config/cmapi.c
It is clear that, if this function needs to be again called with PreviousMode == KernelMode, such a handle conversion must be performed. And... the file handle must be converted anyways to kernel m...

It is clear that, if this function needs to be again called with PreviousMode == KernelMode, such a handle conversion must be performed.
And... the file handle must be converted anyways to kernel mode handle, because it is used as a hive file handle internally by the Cm function(s).
So this code (that is currently #if'ed 0 out) will have to be enabled (later, in v2 of this patch).

See the same comment in the other function.

See the same comment in the other function.

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode. I would like ...

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode.
I would like to hear you about that

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode. I would like ...

For NtSaveKeyEx and NtSaveMergedKeys, both of these functions call CmpInitializeHive, HvWriteHive, etc... and it looks to me they possibly want to run with PreviousMode == KernelMode.
I would like to hear you about that

These probe & capture functions were strongly inspired from the Obp* functions I mention below. If you think they can be useful elsewhere than in this module, please suggest me where-else to place ...

These probe & capture functions were strongly inspired from the Obp* functions I mention below.
If you think they can be useful elsewhere than in this module, please suggest me where-else to place them.

I hate this word: https://en.wikipedia.org/wiki/Quickie ; https://en.wiktionary.org/wiki/quickie
Was renamed to keep it "in sync" with the equivalents in NtLoadKeyEx.

Was renamed to keep it "in sync" with the equivalents in NtLoadKeyEx.

A DPRINT is better than an ASSERT(FALSE); in the kernel, especially when the unimplemented stuff is not vital for the rest of the code to run (we would just gracefully return an error status code)....

A DPRINT is better than an ASSERT(FALSE); in the kernel, especially when the unimplemented stuff is not vital for the rest of the code to run (we would just gracefully return an error status code).
I use SEH here because the object name (buffer) comes potentially from user-mode.

Let me guys now what you think about that.

Let me guys now what you think about that.

Flag added because, the RootDirectory is now a kernel handle, and CmLoadKey will call ObOpenObjectByName with accessmode == KernelMode (indeed, most, if not all Cm functions expect to be called wit...

Flag added because, the RootDirectory is now a kernel handle, and CmLoadKey will call ObOpenObjectByName with accessmode == KernelMode (indeed, most, if not all Cm functions expect to be called with kernel mode parameters).

Forget about this one https://code.reactos.org/static/olpro3/2static/images/wiki/icons/emoticons/smile.gif

Forget about this one

What do you think about the necessity of probing here? Is capturing needed too?

What do you think about the necessity of probing here? Is capturing needed too?

The post callback should be done inconditionally, similar to what is done elsewhere in this file.

The post callback should be done inconditionally, similar to what is done elsewhere in this file.

What you guys actually think about the necessity of that?

What you guys actually think about the necessity of that?

This one was missing (and for NtEnumerateKeyValues, I should add the **Align64 checks too).

This one was missing (and for NtEnumerateKeyValues, I should add the **Align64 checks too).

This is adapted from a private patch from Thomas Faber. I added the 'ObjectType' parameter, because so far I use it for both registry keys and file (IO) objects (aka as the replacement for IoConver...

This is adapted from a private patch from Thomas Faber.
I added the 'ObjectType' parameter, because so far I use it for both registry keys and file (IO) objects (aka as the replacement for IoConvertFileHandleToKernelHandle).

Improve parameters probing in Cm' NT apis
Improve parameters probing in Cm' NT apis
[WINTERNL.H]: Fix the value of OBJ_VALID_ATTRIBUTES, and add the definition for OBJ_FORCE_ACCESS_CHECK.
[SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based on code by Samuel Serapion & MSDN. What needs to be fixed here, is the client/server code to communicate the results back to the main test app being running. Work in progress.
    • -0
    • +14
    /branches/sspi-bringup/rostests/apitests/secur32/CMakeLists.txt
    • -0
    • +520
    /branches/sspi-bringup/rostests/apitests/secur32/client2_msdn.c
    • -0
    • +552
    /branches/sspi-bringup/rostests/apitests/secur32/server2_msdn.c
    • -0
    • +93
    /branches/sspi-bringup/rostests/apitests/secur32/client_server.h
    • -0
    • +334
    /branches/sspi-bringup/rostests/apitests/secur32/client_server.c
[NTOS]: Drastically reduce the hackish function CmpGetRegistryPath() for the text-mode setup case (it should ultimately completely disappear).
[USETUP]: Experiment more with updating/repairing the registry.

Currently partly blocked by CORE-13448.

[USETUP]: Mark some variables as 'static'.
[CMLIB]: Use the generic allocator functions, and fix build.
    • -3
    • +5
    /trunk/reactos/sdk/lib/cmlib/hivecell.c
[CMLIB]: Implement the dynamic array of the hive cell reference tracker.
    • -15
    • +93
    /trunk/reactos/sdk/lib/cmlib/hivecell.c
Sync to trunk r75154.
  1. … 1440 more files in changeset.
[USER.EXE]: Addendum to r75126: add a (dummy) version resource to USER.EXE so as to fix error 1812 "ERROR_RESOURCE_DATA_NOT_FOUND" encountered when starting the DirectX 9.0 installer. From patch by Stas'M, thanks!

CORE-13462

    • -0
    • +5
    /trunk/reactos/subsystems/mvdm/wow16/user/user.rc
[FILESYSTEMS]: Fix printf-like counted string specifiers.
[NTOS:CM]: Simplify code by using suitable assertion macro.
    • -4
    • +2
    /trunk/reactos/ntoskrnl/config/cmdelay.c