mirror of
https://github.com/reactos/reactos.git
synced 2024-12-28 01:55:19 +00:00
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:
parent
5a74450800
commit
f11806f4f0
6 changed files with 259 additions and 211 deletions
32
reactos/media/doc/DdCreateDirectDrawObject.txt
Normal file
32
reactos/media/doc/DdCreateDirectDrawObject.txt
Normal 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
|
16
reactos/media/doc/DdDeleteDirectDrawObject.txt
Normal file
16
reactos/media/doc/DdDeleteDirectDrawObject.txt
Normal 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.
|
|
@ -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.
|
|
@ -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.
|
||||
|
|
|
@ -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);
|
||||
|
||||
}
|
||||
|
|
|
@ -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)
|
Loading…
Reference in a new issue