WDM on Windows 98.

Hello All,

How can the WDM drivers have common API’s on Win98 and Windows NT ,its ok
that windows NT kernel has that API set but from where WDm gets this API’s
on Win98.

Ntkern.vxd.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Pawar [mailto:xxxxx@rediffmail.com]
Sent: Tuesday, October 15, 2002 8:58 PM
To: NT Developers Interest List
Subject: [ntdev] WDM on Windows 98.

Hello All,

How can the WDM drivers have common API’s on Win98 and Windows NT ,its
ok
that windows NT kernel has that API set but from where WDm gets this
API’s
on Win98.


You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

So can we use these API’s in non WDM driver on windows 98 ?

Yes, you can. Moreover, you can call WDM services from VXD drivers on Win9x.

----- Original Message -----
From: “Pawar”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Wednesday, October 16, 2002 10:03 AM
Subject: [ntdev] Re: WDM on Windows 98.

> So can we use these API’s in non WDM driver on windows 98 ?
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nival.com
> To unsubscribe send a blank email to %%email.unsub%%
>

> How can the WDM drivers have common API’s on Win98 and Windows NT
,its ok

that windows NT kernel has that API set but from where WDm gets this
API’s
on Win98.

From NTKERN.VXD binary (or is it inside VMM32.VXD?) which is an NT
emulator over VMM and system VXDs.

Note that drivers on Win9x had the concept of “loader”, the other
driver which does all job of their loading and initialization.
For all WDM drivers, NTKERN is a loader. It loads the PE image,
resolves imports to NTOSKRNL and HAL to some routines of its own, and
then calls DriverEntry.

It wraps CONFIGMG around to provide functions like
IoInvalidateDeviceRelations (which is a wrapper around
CONFIGMG!CM_Reenumerate_DevNode - saw this personally in SoftICE).
It registers itself in CONFIGMGR and sends PnP IRPs to the WDM driver
as a response to CONFIGMG calls.
It uses other system VXDs for things like ISRs, DMA. Dunno what VMM
entities are mapped to DPCs and work items.
It exposes the openable file names to the apps, and maps work with
these files to IRPs sent to WDM drivers.

Now the problems. Block device drivers must be loaded by IOS (not
NTKERN) which manages all block devices in Win9x. Thus, block device
drivers cannot be WDM. Filesystems too due to IFSMgr. So, some Win9x
drivers must still be VXDs.

Sometimes it is necessary to talk to WDM drivers from a VXD, for
instance, in USB disk driver (disk driver is VXD, USB stack is WDM).
Vice versa is also necessary sometimes. There are ways to solve these
VXD/WDM boundary problems, though not so easy. I only remember that
NTKERN provided NtKernxxx functions for WDM drivers willing to talk to
VXDs, I don’t remember how the vice versa is done. I don’t even know
how PnP loads the USB disk driver - as WDM by NTKERN or as VXD by IOS.
I don’t also know whether the direct calls from VXD to WDM via a
pointer are allowed or it is impossible due to different execution
contexts.

The recommended book on WDM (especially recommended due to Win9x
details) is by Walter Oney.
The book IIRC described the “boundary” issues I mentioned above, there
was also CCPORT DDK sample - COM ports must be VXDs too due to VCOMM,
and CCPORT allowed USB COM ports (i.e. USB modems).

Resume: VMM/VXD architecture is ugly due to historical reasons, it was
the DOS virtual machine manager first and only then (with Win3.11 and
Win95) evolved to a complete OS kernel, it carries a lot of DOS legacy
and depends on lots of assembler handicrafting.
NT kernel is much more properly designed.

Max

Can I get all the functionality from WDM which I get from std. VXD API’s ?

Pawar wrote:

Can I get all the functionality from WDM which I get from std. VXD API’s ?

No.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

What are the restrictions on WDM driver over VXD.

Pawar wrote:

What are the restrictions on WDM driver over VXD.

Ask a specific question, if you can. This question calls for about 200
pages worth of answer.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

Block device drivers, filesystems and serial port drivers cannot be
WDM, only VXD.

Anyway the VXD-based OSes are obsoleted year ago with XP release :slight_smile:

Max

“Pawar” wrote in message
news:LYRIS-542-80315-2002.10.17-06.25.09–maxim#xxxxx@lists
.osr.com…
> What are the restrictions on WDM driver over VXD.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>

“Maxim S. Shatskih” wrote:

Anyway the VXD-based OSes are obsoleted year ago with XP release :slight_smile:

We wish!

I imagine the following rhetorical question being posed in Redmond some
years ago: “Will no one rid me of this meddlesome real-mode operating
system?” I guess it’s almost happened…


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

I had to impliment a legacy serial port vxd for Windows 98 so that legacy
applications could use a USB modem. One problem is that serial vxd is
unloaded when the port is closed even before all the IRPs have been
returned from the USB WDM stack. So I implemented a hybrid NT system
kernal mode component (can’t really call it a WDM driver) which presented
a VxD interface (Undocumented call at the time. Not sure if it is
documented now) to control the callbacks from the outstanding IRPs.

Since both the VxD and the SYS were written in C++ (Customer wanted C++
drivers. It wasn’t my decision.). I had to hand code a group of standard
calls in assembler to handle the VxD jumps to get from the VxD to the SYS
module VxD interface. (i.e. I wrapped the VxD jumps)