Alex Ionescu da2029d89e - Final fixes to ObpCreateHandle that I can think of before splitting Create/Increment (might be lacking some security checks or trace/database functionality, but I haven't found any info on the latter, while the former I will stub, but I don't have the skills to imlement (ObAssignObjectSecurity)):
* Honour ObjectType passed to the function and fail if it doesn't match.
  * Use table-based logic instead of process-based logic for Kernel vs User-mode handles (same change that's been done all over the place, since it requires only one dereference of the process object).
  * Do the GENERIC/MAXIMUM_ALLOWED logic directly inside the ACCESS_STATE structure.
  * This is where we should call the OpenProcedure (acc. to Gl00my), but this kills win32k -- investigate, #ifed out for now.
  * Increase the object type's number of handles as well.
  * Set the handle table entry's ObAttributes correctly; the old code seems to have been messing that up.
  * Honour the AdditionalReferences parameter and do referencing bias if requested.
  * Honour the ReturnedObject parameter to return the object pointer back to the caller.
  * Add OBTRACEing to the function.
  * If we failed because a handle couldn't be allocated, use the distinguied STATUS_INSUFFICIENT_RESOURCES error code instead of the generic STATUS_UNSCUCESFFUL, and backout all the changes we made by calling ObpDecrementHandleCount.

svn path=/trunk/; revision=22267
2006-06-07 06:15:59 +00:00
2005-12-13 18:56:49 +00:00
2004-02-06 08:21:52 +00:00
2005-10-02 19:31:30 +00:00
S
Description
A free Windows-compatible Operating System
528 MiB
Languages
C 86.9%
C++ 10.7%
Python 0.7%
Assembly 0.5%
CMake 0.5%
Other 0.4%