WDK RTM Changes

I consistently did diffs (differential changes) between each new release of the WDK. It was interesting to follow the evolution of certain APIs and structures, as well as APIs which were added by mistake.

The latter happens because kits like the WDK are built from a master header file. Suppose it looks like this:

// begin_ntddk

//
// Process Functions
//
NTKERNELAPI
NTAPI
KeSetProcess(IN PRKPROCESS Process);

//
// Thread Functions
//
NTKERNELAPI
NTAPI
KeStartThread(IN PRKTHREAD Thread);

// end_ntddk

NTKERNELAPI
NTAPI
KeSetThreadDrmProtection(IN PRKTHREAD Thread);

What would happen in the DDK is that the KeSetProcess and KeStartThread would be exported, and by definition, “legit” to be used in drivers. Now suppose the developers add a new API in Vista, and don’t properly take a look at the DDK tags, you could end up with this:

// begin_ntddk

//
// Process Functions
//
NTKERNELAPI
NTAPI
KeSetProcess(IN PRKPROCESS Process);

NTKERNELAPI
NTAPI
KeProtectProcessForDrm(IN PRKPROCESS Process);

//
// Thread Functions
//
NTKERNELAPI
NTAPI
KeStartThread(IN PRKTHREAD Thread);

// end_ntddk

NTKERNELAPI
NTAPI
KeSetThreadDrmProtection(IN PRKTHREAD Thread);

Notice that the tags weren’t properly updated to keep the DRM/internal/undocumented function out from the DDK, so it will appear in the WDK. Of course, at the next release, someone is bound to notice and fixup the tags. So by doing cumulative diffs, I was able to get the prototypes of quite a few new APIs that didn’t make it into the final WDK. Of course, I don’t condone their use in a driver, but they’re useful for ReactOS/TinyKRNL development and to better understand some of the changes done in Vista.

One of the more memorable API sets that were added allow drivers (well, at least, were supposed to!) to modify the size of the kernel stack. Typically MmCreateKernelStack was a way to do this, but these new Ke functions give a much greater degree of control as well as give you a Callout function:

#define MAXIMUM_EXPANSION_SIZE (KERNEL_LARGE_STACK_SIZE – (PAGE_SIZE / 2))

typedef
VOID
(NTAPI *PEXPAND_STACK_CALLOUT) (
__in_opt PVOID Parameter
);

#if (NTDDI_VERSION >= NTDDI_WS03SP1)
NTKERNELAPI
NTSTATUS
KeExpandKernelStackAndCallout (
__in PEXPAND_STACK_CALLOUT Callout,
__in_opt PVOID Parameter,
__in SIZE_T Size
);
#endif

#if (NTDDI_VERSION >= NTDDI_LONGHORN)
NTKERNELAPI
NTSTATUS
KeExpandKernelStackAndCalloutEx (
__in PEXPAND_STACK_CALLOUT Callout,
__in_opt PVOID Parameter,
__in SIZE_T Size,
__in BOOLEAN Wait,
__in_opt PVOID Context
);

NTKERNELAPI
PVOID
KeAllocateCalloutStack (
__in BOOLEAN LargeStack
);

NTKERNELAPI
VOID
KeFreeCalloutStack (
__in PVOID Context
);

#endif

Now here’s the ironic thing: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/DevTest_g/hh/DevTest_g/t06_bugs_B0_77bda7e9-4f41-49e9-86db-04446dc9c7b7.xml.asp

“The driver switched stacks using a method that is not supported by the operating system. The only supported way to extend a kernel mode stack is by using KeExpandKernelStackAndCallout.”

I guess it’s either time for a WDK bug or an MSDN documentation bug to be opened!

However, perhaps the best WDK RTM change was this:

Original:

// This logic is a reasonable hack-o-rama to make BillG happy
// since his machine ran chkdsk after he installed Beta 3. Why?
// ’cause setup cracked a non-exclusive DASD handle near the
// end of setup, wrote some data, closed the handle and we
// set the verify bit … came back around and saw that other
// arbitrary activity had left the volume in a temporarily dirty
// state.
//
// Of course, the real problem is that we don’t have a journal.
//

RTM:

// This logic is a reasonable change. Why?
// ’cause setup cracked a non-exclusive DASD handle near the
// end of setup, wrote some data, closed the handle and we
// set the verify bit … came back around and saw that other
// arbitrary activity had left the volume in a temporarily dirty
// state.
//
// Of course, the real problem is that we don’t have a journal.

“hack-o-rama to make BillG happy” => “reasonable change”.

Got any more similar changes of your own? Feel free the post them!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.