adding doc for how DdCreateDirectDrawObject (GdiEntry1) and DdDeleteDirectDrawObject (GdiEntry3) works in reactos. doc by request by some devlopers

svn path=/trunk/; revision=21852
This commit is contained in:
Magnus Olsen 2006-05-08 16:48:10 +00:00
parent 5a74450800
commit f11806f4f0
6 changed files with 259 additions and 211 deletions

View file

@ -0,0 +1,32 @@
DdCreateDirectDrawObject
When IN HDC is not NULL
1. we need check the IN HDC is NULL or not
2. if it not null we need create a directdraw handler
and store it to pDirectDrawGlobal->hDD
3. if the directdraw handle is null return false
we did fail to create directdraw HAL
4. if the directdraw handle was not null we return true
we did susses to create directdraw HAL
When IN HDC is NULL
Now we come to if IN HDC is null basic we need create
a hdc and cashe some data
1. if internal cache of directdraw handle is not null (pDirectDrawGlobalInternal->hDD)
we take it and fill to the public directdraw handler (pDirectDrawGlobal->hDD)
and return susses.
2. if no internal cache of directdraw handle is found we need create it
by using CreateDC for tempary HDC that will be cache in the win32k later
3. we need check see if we got a tempary HDC or not, if we fail getting tempary
HDC return FALSE
4. Now we trying create directdraw handler it being cache to (pDirectDrawGlobalInternal->hDD)
and it also set same handler to the public (pDirectDrawGlobal->hDD)
5. if it fails to create directdraw handle return false
we did fail to create directdraw HAL
6. if it susses create directdraw handle return true
we did susses to create directdraw HAL
To create a directdraw handler you need call the NtGdiDdCreateDirectDrawObject with a hdc

View file

@ -0,0 +1,16 @@
DdDeleteDirectDrawObject
we need release directdraw handler the cache or not cache handler
1. check see if DirectDrawGlobal->hDD is NULL or not
2. if both cache directdraw handler and public handler is NULL
then we need return false, fail to release it or it was already release
3. if public directdraw handler is not null we need release it
and return if we susses or not.
4. we need check if we need rest the internal cache if public being release
use NtGdiDdDeleteDirectDrawObject((HANDLE)DirectDrawGlobal->hDD);
to release a directdraw handler.

View file

@ -1,53 +1,53 @@
==============================================================
= =
= NOTES FROM THE UNDERGROUND =
= =
==============================================================
Below are some of Alex's notes on the mysterious LPC Subsystem
=========================
1. Sizes, sizes, sizes...
=========================
There are four imporant LPC Sizes to keep in mind. Try to understand them:
/*
* This determines the absolute maximum message size (0x100 bytes). For
* larger values, use a section-backed message.
*/
#define PORT_MAXIMUM_MESSAGE_LENGTH 256
/*
* This determines the maximum length of an LPC request. It is the largest
* amount of bytes that an LPC request can take. To calculate this, assume
* that this is a CONNECTION_REQUEST message, which includes the additionnal
* LPCP_CONNECTION_MESSAGE structure as well. Therefore, we add the kernel LPC,
* header, the maximum port size and the size of the connection request
* structure. This gives a value of 0x15C. However, one must note that NT
* allocates the Lookaside List using a 16-byte aligned value, making this
* number 0x160.
*/
#define LPCP_MAX_MESSAGE_SIZE ROUND_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \
sizeof(LPCP_MESSAGE) + \
sizeof(LPCP_CONNECTION_MESSAGE), 16)
/*
* Now, for an actual LPC Request size, we remove the kernel LPC header, which
* yields the size of the actual LPC Data that follows the Header, making this
* number 0x148.
*/
#define LPC_MAX_MESSAGE_LENGTH (LPCP_MAX_MESSAGE_SIZE - \
FIELD_OFFSET(LPCP_MESSAGE, Request))
/*
* Finally, we'll calculate the maximum size of the Connection Info, giving us
* 0x104
*/
#define LPC_MAX_DATA_LENGTH (LPC_MAX_MESSAGE_LENGTH - \
sizeof(PORT_MESSAGE) - \
sizeof(LPCP_CONNECTION_MESSAGE))
==========================
2. Structures
==========================
==============================================================
= =
= NOTES FROM THE UNDERGROUND =
= =
==============================================================
Below are some of Alex's notes on the mysterious LPC Subsystem
=========================
1. Sizes, sizes, sizes...
=========================
There are four imporant LPC Sizes to keep in mind. Try to understand them:
/*
* This determines the absolute maximum message size (0x100 bytes). For
* larger values, use a section-backed message.
*/
#define PORT_MAXIMUM_MESSAGE_LENGTH 256
/*
* This determines the maximum length of an LPC request. It is the largest
* amount of bytes that an LPC request can take. To calculate this, assume
* that this is a CONNECTION_REQUEST message, which includes the additionnal
* LPCP_CONNECTION_MESSAGE structure as well. Therefore, we add the kernel LPC,
* header, the maximum port size and the size of the connection request
* structure. This gives a value of 0x15C. However, one must note that NT
* allocates the Lookaside List using a 16-byte aligned value, making this
* number 0x160.
*/
#define LPCP_MAX_MESSAGE_SIZE ROUND_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \
sizeof(LPCP_MESSAGE) + \
sizeof(LPCP_CONNECTION_MESSAGE), 16)
/*
* Now, for an actual LPC Request size, we remove the kernel LPC header, which
* yields the size of the actual LPC Data that follows the Header, making this
* number 0x148.
*/
#define LPC_MAX_MESSAGE_LENGTH (LPCP_MAX_MESSAGE_SIZE - \
FIELD_OFFSET(LPCP_MESSAGE, Request))
/*
* Finally, we'll calculate the maximum size of the Connection Info, giving us
* 0x104
*/
#define LPC_MAX_DATA_LENGTH (LPC_MAX_MESSAGE_LENGTH - \
sizeof(PORT_MESSAGE) - \
sizeof(LPCP_CONNECTION_MESSAGE))
==========================
2. Structures
==========================
SOON. TODO.

View file

@ -1,18 +1,18 @@
References (Rex's at least)
Baker, Art. The Windows NT Device Driver Book. Prentice Hall, 1997.
Borate, Dabak & Phadke. Undocumented Windows NT. M&T Books, 1999.
Brain, Marshall. Win32 System Services. Prentice Hall, 1996.
Cant, Chris. Writing Windows WDM Device Drivers. R&D Books, 1999.
Canton & Sanchez. IBM Microcomputers: A Programmer's Handbook. McGraw Hill, 1990.
Davis & Wallace. Windows Undocumented File Formats. R&D Books, 1997.
Mason & Viscarola. Windows NT Device Driver Development. Macmillan, 1999.
Mitchell, Stan. Inside the Windows 95 File System. O'Reilly, 1997.
Murray, James D. Windows NT Event Logging. O'Reilly, 1998.
Nagar, Rajeev. Windows NT File System Internals. O'Reilly, 1997.
Osbourne, Sandra. Windows NT Registry: A Settings Reference. New Riders, 1998.
Pietrek, Matt. Windows 95 System Programming Secrets. IDG, 1995.
Richter, Jeffery. Advanced Windows, 3rd ed. Microsoft, 1997.
Simon, Richard J. Windows NT Win32 API Superbible. Waite Group, 1996.
Solomon, David A. Inside Windows NT, 2nd Ed. Microsoft, 1998.
"The NT Insider." Open Systems Resources, 1999-2000.
References (Rex's at least)
Baker, Art. The Windows NT Device Driver Book. Prentice Hall, 1997.
Borate, Dabak & Phadke. Undocumented Windows NT. M&T Books, 1999.
Brain, Marshall. Win32 System Services. Prentice Hall, 1996.
Cant, Chris. Writing Windows WDM Device Drivers. R&D Books, 1999.
Canton & Sanchez. IBM Microcomputers: A Programmer's Handbook. McGraw Hill, 1990.
Davis & Wallace. Windows Undocumented File Formats. R&D Books, 1997.
Mason & Viscarola. Windows NT Device Driver Development. Macmillan, 1999.
Mitchell, Stan. Inside the Windows 95 File System. O'Reilly, 1997.
Murray, James D. Windows NT Event Logging. O'Reilly, 1998.
Nagar, Rajeev. Windows NT File System Internals. O'Reilly, 1997.
Osbourne, Sandra. Windows NT Registry: A Settings Reference. New Riders, 1998.
Pietrek, Matt. Windows 95 System Programming Secrets. IDG, 1995.
Richter, Jeffery. Advanced Windows, 3rd ed. Microsoft, 1997.
Simon, Richard J. Windows NT Win32 API Superbible. Waite Group, 1996.
Solomon, David A. Inside Windows NT, 2nd Ed. Microsoft, 1998.
"The NT Insider." Open Systems Resources, 1999-2000.

View file

@ -1,103 +1,103 @@
/*
Boiler plate for irp cancelation, for irp queues you manage yourself
-Gunnar
*/
CancelRoutine(
DEV_OBJ Dev,
Irp
)
{
//don't need this since we have our own sync. protecting irp cancellation
IoReleaseCancelSpinLock(Irp->CancelIrql);
theLock = Irp->Tail.Overlay.DriverContext[3];
Lock(theLock);
RemoveEntryList(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}
QUEUE_BOLIERPLATE
{
Lock(theLock);
Irp->Tail.Overlay.DriverContext[3] = &theLock;
IoSetCancelRoutine(Irp, CancelRoutine);
if (Irp->Cancel && IoSetCancelRoutine(Irp, NULL))
{
/*
Irp has already been cancelled (before we got to queue it),
and we got to remove the cancel routine before the canceler could,
so we cancel/complete the irp ourself.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return FALSE;
}
//else were ok
Irp->IoStatus.Status = STATUS_PENDING;
IoMarkIrpPending(Irp);
InsertTailList(Queue);
Unlock(theLock);
}
DEQUEUE_BOILERPLATE
{
Lock(theLock);
Irp = RemoveHeadList(Queue);
if (!IoSetCancelRoutine(Irp, NULL))
{
/*
Cancel routine WILL be called after we release the spinlock. It will try to remove
the irp from the list and cancel/complete this irp. Since we allready removed it,
make its ListEntry point to itself.
*/
InitializeListHead(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
return;
}
/*
Cancel routine will NOT be called, canceled or not.
The Irp might have been canceled (Irp->Cancel flag set) but we don't care,
since we are to complete this Irp now anyways.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}
/*
Boiler plate for irp cancelation, for irp queues you manage yourself
-Gunnar
*/
CancelRoutine(
DEV_OBJ Dev,
Irp
)
{
//don't need this since we have our own sync. protecting irp cancellation
IoReleaseCancelSpinLock(Irp->CancelIrql);
theLock = Irp->Tail.Overlay.DriverContext[3];
Lock(theLock);
RemoveEntryList(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}
QUEUE_BOLIERPLATE
{
Lock(theLock);
Irp->Tail.Overlay.DriverContext[3] = &theLock;
IoSetCancelRoutine(Irp, CancelRoutine);
if (Irp->Cancel && IoSetCancelRoutine(Irp, NULL))
{
/*
Irp has already been cancelled (before we got to queue it),
and we got to remove the cancel routine before the canceler could,
so we cancel/complete the irp ourself.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return FALSE;
}
//else were ok
Irp->IoStatus.Status = STATUS_PENDING;
IoMarkIrpPending(Irp);
InsertTailList(Queue);
Unlock(theLock);
}
DEQUEUE_BOILERPLATE
{
Lock(theLock);
Irp = RemoveHeadList(Queue);
if (!IoSetCancelRoutine(Irp, NULL))
{
/*
Cancel routine WILL be called after we release the spinlock. It will try to remove
the irp from the list and cancel/complete this irp. Since we allready removed it,
make its ListEntry point to itself.
*/
InitializeListHead(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
return;
}
/*
Cancel routine will NOT be called, canceled or not.
The Irp might have been canceled (Irp->Cancel flag set) but we don't care,
since we are to complete this Irp now anyways.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}

View file

@ -1,39 +1,39 @@
Next-Gen (NT 5.2) Executive Locks in NTOSKRNL.
------------------------------
1a. Rundown Protection
USED IN: Thread/Process Ps* Code.
EXAMPLES: NtSetInformationProcess/Thread, PspCreateThread/Process, PspSuspend/ResumeThread...
REPLACES: Unlocked access and/or PsLock/UnlockProcess.
ROS STATUS: Implemented. Code needs cleanup. Not yet tested. Not yet used.
1b. Cache-Aware Rundown Protection
USED IN: Unknown. Functions exported for drivers.
EXAMPLES: None.
REPLACES: Nothing.
ROS STATUS: Unimplemented.
2. Guarded Mutex
USED IN: Configuration Manager, MCB Functions (FsRtl), Binary Hive Module (Hv), PnP (Notifications), LPC, Jobs (Ps), Device Map (Ob), and Memory Management (Address Space/Virtual Memory).
EXAMPLES: Too many.
REPLACES: Anything that used FAST_MUTEX.
ROS STATUS: Implemented, slightly tested; appears to still contain a bug.
3. Fast Referencing
USED IN: Tokens.
EXAMPLES: R: PsReferencePrimary/EffectiveToken. D: Failure code of anything that calls those two functions.
REPLACES: Normal referencing.
ROS STATUS: Hackplemented stubs.
4a. Pushlocks
USED IN: Configuration Manager (Cm), Handle Table (Ex), Binary Hive Module (Hv), Memory Management (Address Space/Virtual Memory), Object Namespace (Directories/Names) (Ob), Impersonation (Ps).
EXAMPLES: Too many.
REPLACES: Anything that used ERESOURCE.
ROS STATUS: Implemented (missing Block/([Timed]Wait)Unblock) and slightly tested.
4b. Cache-Aware Pushlocks
USED IN: AWE (Mm).
EXAMPLES: None.
REPLACES: Executive Resources.
ROS STATUS: Unimplemented.
Next-Gen (NT 5.2) Executive Locks in NTOSKRNL.
------------------------------
1a. Rundown Protection
USED IN: Thread/Process Ps* Code.
EXAMPLES: NtSetInformationProcess/Thread, PspCreateThread/Process, PspSuspend/ResumeThread...
REPLACES: Unlocked access and/or PsLock/UnlockProcess.
ROS STATUS: Implemented. Code needs cleanup. Not yet tested. Not yet used.
1b. Cache-Aware Rundown Protection
USED IN: Unknown. Functions exported for drivers.
EXAMPLES: None.
REPLACES: Nothing.
ROS STATUS: Unimplemented.
2. Guarded Mutex
USED IN: Configuration Manager, MCB Functions (FsRtl), Binary Hive Module (Hv), PnP (Notifications), LPC, Jobs (Ps), Device Map (Ob), and Memory Management (Address Space/Virtual Memory).
EXAMPLES: Too many.
REPLACES: Anything that used FAST_MUTEX.
ROS STATUS: Implemented, slightly tested; appears to still contain a bug.
3. Fast Referencing
USED IN: Tokens.
EXAMPLES: R: PsReferencePrimary/EffectiveToken. D: Failure code of anything that calls those two functions.
REPLACES: Normal referencing.
ROS STATUS: Hackplemented stubs.
4a. Pushlocks
USED IN: Configuration Manager (Cm), Handle Table (Ex), Binary Hive Module (Hv), Memory Management (Address Space/Virtual Memory), Object Namespace (Directories/Names) (Ob), Impersonation (Ps).
EXAMPLES: Too many.
REPLACES: Anything that used ERESOURCE.
ROS STATUS: Implemented (missing Block/([Timed]Wait)Unblock) and slightly tested.
4b. Cache-Aware Pushlocks
USED IN: AWE (Mm).
EXAMPLES: None.
REPLACES: Executive Resources.
ROS STATUS: Unimplemented.
TODO: Kernel Locks (Queued and In-Stack Spinlocks)