You an use the APIs, yes. But the issue is owning the dispatch entry points. As a miniport driver, you delegate dispatch to the port driver (NDIS) in this case. So precisely, handling AddDevice and IRPs is for NDIS to do so trying to pick a personality of a FDO during AddDevice is going to difficult and hard to support.
What is the reticence to just build multiple drivers for the different FDO functions? If you want to share functionality that functionality can still live in the parent or a lower filter that loads across all of the device stacks.
Technically, the NDIS interface and even the corresponding UM APIs are all orthogonal to the rest of the Win32 API / NT kernel and drivers and applications cannot mix and match. In practice, every platform that you care about supporting has NDIS functions that are thin wrappers of the underlying DDI / API calls and you can mostly do what you like. If this were to cease on some future version of Windows, must likely your binary would not load due to undefined imports or explicit checking by the loader. At that point users we ask for a version that works on Windows XXX (in soft or loud voices depending upon to who you sell)
Sent from Surface Pro
From: xxxxx@comcast.net
Sent: Monday, June 16, 2014 12:55 PM
To: Windows System Software Devs Interest List
I thought you just have to #define NDIS_WDM, or something like that, and then you can use all of the APIs, including the bus interface - err interface.