Further to Peter?s answer (and I too have essayed to enter heretofore and also have deleted some nascent works)
You may have a legitimate issue with the document writers at Microsoft for not making this point more clear by using identical language for two different values, but the main problem is this is obvious. First, from the point of view that when approaching any API (DDI) the presence of two separate parameters indicates that they describe two logically different values (independent or otherwise) and second from the point of view that at a systemic level how would it be possible to implement in a different way.
You may justly criticise the doc writers for not including the correct references to other concepts or failing to qualify the count of which bytes, but when in this history of computing has any documentation ever been definitive from the point of view of the arbitrarily uninured; or for that matter in the history of writing, as each document must perforce assume something from its audience including at least the literacy to read its words.
I have often found that it is important to think before blindly blaming others for their miss-work on the design or documentation of hardware or software. This method has stood me well through every kind of technology I have ever encountered except for cryptography. In this area Microsoft assuredly has some of their worst APIs and even poorer documentation, but equally assuredly they are well advanced compared with others who participate.
Sent from Mailhttps: for Windows 10
From: xxxxx@osr.commailto:xxxxx
Sent: February 4, 2017 10:57 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Re: MmGetMdlByteCount greater than TransferBufferLength
You know, I’ve started to answer this thread three separate times, and each time I’ve lost the will to argue and deleted my answer.
Mr. Sykes… with all due respect… from a Windows architectural perspective, you’re just wrong. Take this as an opportunity to learn something, instead of as an opportunity to argue. Mr. Roberts is rarely incorrect about such fundamental concepts, and he’s absolutely correct here.
I will admit: If you spend most of your time in the upper parts of the storage stack (for example), it’s pretty easy to see the MDL as “the definitive description of the transfer”… but, really, it’s not.
It turns out that there are some places were the MDL size and the I/O operation (read/write) length are identical. But any time there is a separate place to get the length of the operation (URB, I/O Stack, SRB) it is incorrect to rely on the size of the underlying MDL as the size of the operation.
As Mr. Roberts and Mr. Grig described, the MDL describes the size of a buffer in kernel mode. That’s all it represents. When one performs an I/O operation from the described buffer, there is not ALWAYS the implication that the MDL describes the I/O operation.
Whenever there’s a description of the I/O operation… pointer, length, whatever… that’s separate from the MDL, you use the separate description. The MDL has to be valid. And the actual data buffer used for the transfer has to be a valid subset of the buffer described by the MDL. That subset can be 100% of the MDL or just part of the MDL.
This is just the way Windows architecture has been, since… well… at least 1992 when I started working with Windows NT.
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>