Object Manager Patch. This patch continues the work done in the previous patch and...
authorAlex Ionescu <aionescu@gmail.com>
Wed, 18 May 2005 19:26:47 +0000 (19:26 +0000)
committerAlex Ionescu <aionescu@gmail.com>
Wed, 18 May 2005 19:26:47 +0000 (19:26 +0000)
commit00fe79ff10887a096149566a9d37845497dd7533
tree190649a5b03c4e23b1b96a5f3a322853c649280e
parentdfedb9967551c78e6b158018149adbeb7f6a0263
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

svn path=/trunk/; revision=15395
23 files changed:
reactos/include/ddk/obfuncs.h
reactos/ntoskrnl/cm/cm.h
reactos/ntoskrnl/cm/ntfunc.c
reactos/ntoskrnl/cm/registry.c
reactos/ntoskrnl/cm/regobj.c
reactos/ntoskrnl/include/internal/io.h
reactos/ntoskrnl/include/internal/ob.h
reactos/ntoskrnl/io/driver.c
reactos/ntoskrnl/io/file.c
reactos/ntoskrnl/mm/section.c
reactos/ntoskrnl/ntoskrnl.def
reactos/ntoskrnl/ob/dirobj.c
reactos/ntoskrnl/ob/handle.c
reactos/ntoskrnl/ob/namespc.c
reactos/ntoskrnl/ob/ntobj.c
reactos/ntoskrnl/ob/object.c
reactos/ntoskrnl/rtl/nls.c
reactos/ntoskrnl/se/sd.c
reactos/ntoskrnl/se/semgr.c
reactos/ntoskrnl/se/token.c
reactos/subsys/system/services/database.c
reactos/subsys/win32k/ntuser/csr.c
reactos/w32api/include/ddk/winddk.h