Re: [ros-diffs] [ion] 15395: Object Manager Patch. This patch continues the work done in the previous patch and makes the following changes in order to support OB 2.0 (it basically temporarily fixes a highly incorrect implementation so that caller code will be ready to work with the OB 2.0 without change):

[Hartmut Birr]

ion(a)svn.reactos.com wrote:

>  Object Manager Patch. This patch continues the work
> done in the previous patch and makes the following changes in order to support OB 2.0 (it
> basically temporarily fixes a highly incorrect implementation so that caller code will be
> ready to work with the OB 2.0 without change):
>
> 1) The documented Object Create Information Structure and semantics implemented. All
> Object Attributes and passed data from user-mode is now probed and saved into this object
> create structure when ObCreateObject is called.
> 2) ObCreateObject does NOT PERFORM ANY OTHER OPERATION EXCEPT CREATING THE OBJECT ANYMORE.
> ObCreateObject will NOT insert the Object into the tree and other operations. These are
> now done correctly by ObInsertObject. Therefore, the biggest hurdle was changing pieces of
> code which assumed ObCreateObject would be enough.
> 3) ObInsertObject uses the captured create info for all operations isntead of the Object
> Attributes.
> 4) ObFindObject now uses the captured info as well.
> 5) The OBject name and directory are now stored in the documented Object Name Information,
> always allocated and freed from non paged pool.
>
> HACKS:
> 5) Because the registry code is horribly broken and doesn't use ObFindObjectByName,
> the old ObFindObject had to be temporarily duplicated into CmpFindObject.
> 7) Win32k used ObInsertObject in CsrInsertObject as a way to create a handle inside csrss.
> However, OBInsertObject now does more then this. As a temporary hack, ObpCreateHandle is
> exported from the kernel and called from win32k. A fix needs to be done for this, but I
> don't know the design of win32k+csrss well enough to find a solution.
> 8) SEH has been commented out in some places of the new probing code because it breaks
> smss and explorer. These need to be investigated (seh did not exist in the previous code,
> so this is not really a hack)
> 9) Named objects with a parent directory are NOT allowed. However because of bugs in
> kernel32, the new check has been temporarily disabled. (this check did not exist in the
> previous code, so this is not really a hack)
>
> The next patch will add a proper ObFindObject which will support a more complete Parse
> Procedure with context and security information. This is needed for proper registry access
> (requested by Eric Kohl) and for proper functionality of the Desktop/File creation, which
> should use the Parse routine, and not the Create Handle Routine. This will also make it
> possible to remove some previous hacks and pave the way for a fixed Iop/IoCreateFile
>  
--- trunk/reactos/subsys/system/services/database.c	2005/05/08 04:07:56	15111
+++ trunk/reactos/subsys/system/services/database.c	2005/05/18 19:26:47	15395
@@ -702,12 +702,13 @@
   ResumeThread(ProcessInformation.hThread);
 
   /* Connect control pipe */
+  DPRINT1("Connect named pipe\n")
   if (ConnectNamedPipe(Service->ControlPipeHandle, NULL))
     {
       DWORD dwProcessId = 0;
       DWORD dwRead = 0;

The missing ';' after the DPRINT1 breaks compiling for me.

- Hartmut