jds

WdmStub

79 posts in this topic

He also said if one was to update WDMSTUB.SYS to change the name to avoid confusion.

Of course he shall have his wish respected. I propose the updated version, if and when we arrive at that, should be named "NUWDMST".

Why not "WDMSTUBX" for "WDMSTUB eXtended/eXtender?" I think the name should be as close to the original as possible while fulfilling Oney's wishes.

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites
I personally prefer the VXD as it is always there just like the NT/2000/XP NTKERN.VXD that it is trying to emulate.

So we do agree on this point. BTW, v. 4.20 is still a VxD, right? It's from before he moved on to .SYS.

The source code is for a VXD. I don't see any for a SYS File.

0

Share this post


Link to post
Share on other sites

Anyhow, the source code for WDMSTUB came with the book. That means you can use the code as a base to build something of your own with a different name.

Thanks, PROBLEMCHYLD, you've done well! This gives us the green light! :yes:

BTW, can you also give us the time/date of the e-mail? Probably not important, but it helps with traceability.

In case you haven't seen it, below is the notice that comes with the WdmStub code. So you can see why it was important to get more up-to-date permission for what we're wanting to do here :

Redistributing WDMSTUB

WDMSTUB is an exception to the blanket license to use the sample programs for this book. The author will grant a royalty-free license to anyone to redistribute WDMSTUB as part of a WDM driver package. The license will, however, include conditions designed to insure the consistency and quality of WDMSTUB on end user machines. Send e-mail to waltoney@xxxxxxxx.xxx for information about obtaining this conditional license.

Note: A special license is required even if you ship WDMSTUB under a different name. This driver includes special checking to make sure that it does not unload while some other vendor’s driver might be using it, and the special license will insure that you preserve that checking.

Joe.

Edited by jds
0

Share this post


Link to post
Share on other sites

Wishlist for a next version of WDMSTUB:

_vsnwprintf

HidNotifyPresence

InterlockedPopEntrySList

InterlockedPushEntrySList

TdiCopyBufferToMdl

TdiCopyMdlToBuffer

ZwDeleteValueKey

Here's two more that might come in handy in the future.

WdfVersionUnbind

WdfVersionBind

And yet some more:

KeReadStateEvent

InterlockedExchangeAdd

KeQueryActiveProcessors

RtlUpcaseUnicodeString <-- although I reckon this one may not be feasible

0

Share this post


Link to post
Share on other sites

You guys are aware his book has an Second Edition.

0

Share this post


Link to post
Share on other sites

You guys are aware his book has an Second Edition.

My copy is clearly the first.

0

Share this post


Link to post
Share on other sites

BTW, can you also give us the time/date of the e-mail? Probably not important, but it helps with traceability.

Feb 20, 2012 06:28:41 PM

Why not "WDMSTUBX" for "WDMSTUB eXtended/eXtender?" I think the name should be as close to the original as possible while fulfilling Oney's wishes.

That would be a great name for it. Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

I have been wondering about the three different versions 5.00.006 of WDMSTUB.SYS (that we know of, so far), and what may be different between them. Anyway, when I opened them with Dependency Walker, it reported the following dependencies :

Oneysoft version => ntoskrnl.exe, HAL.DLL

Garmin version => ntoskrnl.exe

NUSB30e version => ntoskrnl.exe

Digging deeper with Dependency Walker revealed these dependencies :

ntoskrnl.exe => bootvid.dll, HAL.DLL, kdcom.dll

HAL.DLL => ntoskrnl.exe

bootvid.dll => ntoskrnl.exe, HAL.DLL

kdcom.dll => ntoskrnl.exe, HAL.DLL

So, all three versions ultimately show the same dependencies, but only the Oneysoft version shows a direct dependency on HAL.DLL (and is also noticeably larger than the other two, more recent, versions). I'm not sure, but that suggests to me that there may be functional differences between these three versions, despite the identical version numbering.

The other notable thing, is that these apparent dependencies are not provided by W98SE. I searched around to find these versions of said files, before Dependency Walker was fully satisfied with WDMSTUB.SYS :

bootvid.dll = 5.1.2600.0 (xpclient.010817-1148)

HAL.DLL = 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

kdcom.dll = 5.1.2600.0 (xpclient.010817-1148)

ntoskrnl.exe = 5.1.2600.2622 (xpsp_sp2_gdr.050301-1519)

Now I wonder, are these extra modules sometimes needed for WdmStub to do its job on W98, or are they only used on say, W2000?

Joe.

0

Share this post


Link to post
Share on other sites

Dependency Walker gives false results for WDM drivers on 9x/ME. It'll always show dependencies to one of or both hal.dll and ntoskrnl.exe, which are NT-OS only files.

There are four known compilations of WDMSTUB.SYS v. 5.0.0.6, AFAIK:

1) PE TIMESTAMP Wed Jun 11 22:05:16 2003 (3EE7D1CC), 20480 KiB, MD5 69309403061DD2953D402015B6E4EFB1 is a debug build compiled from the source provided with W. Oney's Service Pack 3 to the WDM book 2nd Ed. (released June 12, 2003);

2) PE TIMESTAMP Wed Sat Mar 15 09:16:46 2003 (3E7319AE), 11520 KiB, MD5 3AA89DDB2B5FE621E0EB11F9D1FFBD39 is a release build that comes with some Honeywell drivers;

3) PE TIMESTAMP Wed Thu May 22 10:55:15 2003 (3ECCD6C3), 11520 KiB, MD5 1D7284E0F3CB98A189F0AC17C3F13337 is a release build that comes with the Garmin USB GPS drivers;

4) PE TIMESTAMP Sun Sep 24 19:05:20 2006 (45170120), 12767 KiB, MD5 9AA0AEA685F135C9D1409F8E3E5ADD10 is a release build that comes with NUSB30e.

While the first three are functionally identical, despite being clearly different compilations, with some different optimizations, the fourth is an updated version that exports one more function. It is the one in general use and it is the most up to date one that I know of, and, of course, it shouldn't be versioned 5.0.0.6...

And to answer the question you posed: yes, they're only used in NT-OSes.

0

Share this post


Link to post
Share on other sites

NTOSKRNL.EXE and HAL.DLL provide the Core functionality for WDM Drivers on NT OSes. When Microsoft ported WDM to Windows 9x they put most of the Functions in NTKERN.VXD and a few in other VXDs. The normal Export/Import model cannot handle this configuration, so Microsoft provided a way to Export Functions under the name of Modules other than the ones hosting them.

These Exports are published via Kernel calls, not by PE Export tables. This is why Dependency Walker cannot follow Imports back to these Exports. In addition more than one Module can add Functions under the same Module name. WDMSTUB adds it's functions under the Module name NTOSKRNL.EXE on top of the ones already defined, replacing a few of the existing ones.

VXDs can only add Functions in this manner as they do not have Export Tables.

0

Share this post


Link to post
Share on other sites

Thanks for the explanations, guys.

So it's not just with KernelEx that you can't depend on Dependency Walker ;)

OK, so we don't actually need those XP files, and it sounds like the nusb30e build of WdmStub is the default one to try. Any idea if its source exists somewhere?

Also, a crazy idea occurred to me ... if the above XP files don't have dependencies other than between themselves, could they be used together as an alternative to WdmStub (ignoring for the moment the problem that you'd probably need a license for XP to use them legitimately, which not all W98 users would have)?

Joe.

0

Share this post


Link to post
Share on other sites
WmiTraceMessage
IoAssignResources
IoReportResourceForDetection
HalDispatchTable
RtlLargeIntegerDivide
IoReportDetectedDevice
HalMakeBeep

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Here a list of everything in this thread. I'll try to keep the list updated :thumbup

MmFreeContiguousMemorySpecifyCache
MmAllocateContiguousMemorySpecifyCache
NdisQueryBufferSafe
_aulldvrm
KeBugCheck
KeRegisterBugCheckReasonCallback
KeDeregisterBugCheckReasonCallback
InterlockedPushEntrySlist
InterlockedPopEntrySlist
NdisMRegisterUnloadHandler
NdisIMCopySendPerPacketInfo
NdisInitializeString
KeLowerIrql
KeRaiseIrqlToDpcLevel
_vsnwprintf
HidNotifyPresence
TdiCopyBufferToMdl
TdiCopyMdlToBuffer
ZwDeleteValueKey
WdfVersionUnbind
WdfVersionBind
KeReadStateEvent
InterlockedExchangeAdd
KeQueryActiveProcessors
RtlUpcaseUnicodeString
WmiTraceMessage
WmiQueryTraceInformation
IoAssignResources
IoReportResourceForDetection
HalDispatchTable
RtlLargeIntegerDivide
IoReportDetectedDevice
HalMakeBeep
IoSetCompletionRoutineEx
ExFreePoolWithTag
IoSetHardErrorOrVerifyDevice
ZwOpenSymbolicLinkObject

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

Here a list of everything in this thread. I'll try to keep the list updated :thumbup

MmFreeContiguousMemorySpecifyCache
MmAllocateContiguousMemorySpecifyCache
NdisQueryBufferSafe
_aulldvrm
KeBugCheck
KeRegisterBugCheckReasonCallback
KeDeregisterBugCheckReasonCallback
InterlockedPushEntrySlist
InterlockedPopEntrySlist
NdisMRegisterUnloadHandler
NdisIMCopySendPerPacketInfo
NdisInitializeString
KeLowerIrql
KeRaiseIrqlToDpcLevel
_vsnwprintf
HidNotifyPresence
TdiCopyBufferToMdl
TdiCopyMdlToBuffer
ZwDeleteValueKey
WdfVersionUnbind
WdfVersionBind
KeReadStateEvent
InterlockedExchangeAdd
KeQueryActiveProcessors
RtlUpcaseUnicodeString
WmiTraceMessage
WmiQueryTraceInformation
IoAssignResources
IoReportResourceForDetection
HalDispatchTable
RtlLargeIntegerDivide
IoReportDetectedDevice
HalMakeBeep

I have five of these in my WDMEX Project already. Five more look pretty trivial to implement.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.