Coming Back to Driver Development

It’s been a while for me. I did some driver development back in 2010 and 2011, but the 32 bit ISA driver I wrote back in 2010 has been doing the job adequately and the USB project got pushed to the back burner and was never completed. Now customers are getting to a point where their IT departments are requiring them to update to at least Win 10 x64, so I’m back looking at the drivers.

This is a two part question. I’ve been trying to get up to speed with VS 2019 and the new WDK, but I’ve hit some problems, but if the answer to the first question is no, we’re going to need a different approach.

As I mentioned, the interface hardware currently in use is an 8 bit ISA card. The system this interfaces with was original introduced in the 1980s and it still does the job. The company I work for has been slowly updating the hardware in the system to use newer components, but the interface has been unchanged for over 30 years. They can still get industrial motherboards with ISA slots, so they keep going with ISA.

There have been three attempts by three different people to make a USB replacement and I got the furthest. A direct translation of the ISA commands to USB is glacially slow because of the nature of the ISA command pattern and USB’s scheduled nature. I worked around it, but still had some problems I didn’t solve before getting pulled off to do something else.

Anyway, Question #1 - Does Windows 10 x64 still support ISA? I think it does, but we haven’t been able to find any examples, even in industrial computing applications.

If true, I’ve run into some issues getting set up to compile the driver again. I’m just trying to get going with the tools that support Win 10. I have Visual Studio Professional 2019 Version 16.11.9 installed and I installed the 2004 version of the WDK for Win 10. There was an error message for VSIXInstaller at the end, but according to my searches, it appears that only supports an old version of Visual Studio and doesn’t support VS 2019.

I found the Getting Started document on OSR’s site
https://osr.com/getting-started-writing-windows-drivers/

It says:

“Visual Studio and the WDK together provide everything you need to create driver projects, and to compile, link, and even debug Windows drivers. After you’ve successfully installed Visual Studio and the WDK, you can very easily build a simple driver demo project. You don’t even need any hardware! Just select “New Project” and within Visual C++ select the Windows Driver project category. Within this category select Kernel Mode Driver (KMDF). Click OK and Visual Studio will generate a simple starter or demo driver project for you that doesn’t require any specific hardware. This driver will successfully build, and can even be installed on a test machine. Yup, it really is that simple.”

I selected New->Project, but there is no Windows Driver category, or anything that has anything to do with drivers available. My guess is either something from the WDK installer didn’t work right or Microsoft went and changed things since document was written and it takes some other magical incantation to get a new driver project now.

What am I doing wrong?

Thanks in advance…

Does Windows 10 x64 still support ISA? I think it does, but we haven’t been able to find any examples, even in industrial computing applications

As far as I know, yes it does. See this NTDEV thread.

I have Visual Studio Professional 2019 Version 16.11.9 installed and I installed the 2004 version of the WDK for Win 10.

…

I selected New->Project, but there is no Windows Driver category, or anything that has anything to do with drivers available.

OK. You could very well have run into the well known “I installed the WDK with VS, but the I don’t see any driver type projects” problem. I’ve had that happen to me, and I’ve seen it happen to countless clients/students/colleagues over the years.

First, you really DO want to install the Windows 11 WDK. This is the latest WDK, it works with VS 2019 (only) and it’s the right WDK to use for Win 10 driver development.

Sooooo… REMOVE the 2004 version of the WDK for Win 10. Install the SDK and WDK as described on the MSFT page. BE SURE to select the option, offered at the end, after the install finishes, to install the whatever-it-is components to hook-up with VS at the end (THIS not working, or not being requested, is what most typically causes the projects to not show up.

Let us know how that goes,

Peter

A direct translation of the ISA commands to USB is glacially slow because of the nature of the ISA command pattern and USB’s scheduled nature.

I find that impossible to believe. An ISA bus with zero wait states transfers a word every 250ns. In that time USB will have completed two complete microframes. That is, you can transfer 16kB on USB in the same time you get 2 BYTES on ISA. If USB is slower than ISA, then you have done something horribly wrong.

Actually, a lot of this depends on the user interface. I have dealt with a number of instrument manufacturers whose drivers were a little more than write register / read register as separate IOCTL’s. The challenge there is how to create a new interface that can easily be adopted for the program controlling the device, then provide drivers so both ISA and USB can work.

An ISA bus with zero wait states transfers a word every 250ns

I love that we can count on Mr. Roberts to enlighten us with stuff like this. I, for one, have no earthly clue about how fast or slow most hardware interfaces are. ISA being capable of only transferring one word in 250ns really puts the age of that interface into perspective. And that’s quite separate from whether making a USB interface for an ancient ISA device is easy or not easy… I think it depends a lot on the register access pattern required, as Mr. Burn stated.

Still… I love learning the relative speed of various buses.

Thank you, Mr. Roberts.

@Tim_Roberts said:

A direct translation of the ISA commands to USB is glacially slow because of the nature of the ISA command pattern and USB’s scheduled nature.

I find that impossible to believe. An ISA bus with zero wait states transfers a word every 250ns. In that time USB will have completed two complete microframes. That is, you can transfer 16kB on USB in the same time you get 2 BYTES on ISA. If USB is slower than ISA, then you have done something horribly wrong.

Which USB standard are you referring to?
microframe is 125us for HS and 1ms for FS/LS.

Microframe is a HS concept, and is always 125us. A frame is 1ms, for all speeds. HS has both: 8 microframes make up a frame.

My brain is a vast warehouse of useless knowledge. Very much like the secret warehouse at the end of “Raiders of the Lost Ark”.

@Don_Burn said:
Actually, a lot of this depends on the user interface. I have dealt with a number of instrument manufacturers whose drivers were a little more than write register / read register as separate IOCTL’s. The challenge there is how to create a new interface that can easily be adopted for the program controlling the device, then provide drivers so both ISA and USB can work.

This is how the hardware was designed. All transfers are one byte at a time. A straight translation to USB means that you are transferring one byte per 125 us sub-frame (USB2 or 3). On the ISA bus it’s 250ns as Tim Roberts points out. The 500x slow down in transfer rate becomes very noticeable very fast.

I figured out how to bundle some transfers into blocks and transfer over USB, but the microcontroller I used on the USB device side had to reproduce the ISA bus on the device side. The back plane of the device chassis is a slightly modified ISA bus protocol. I made some suggestions how we could move further low level functions to the microcontroller, but their customers were clamoring for some other things and I had to switch back to Windows app development and they put USB on a lower priority since ISA was working.

As far as ISA on Win 10 x86, I know that works. We’re still using the driver I wrote in 2010. Industrial motherboards are available with ISA slots. I just didn’t know if Win 10 x64 supports ISA. x64 can be different when you get off the well beaten track.

I downloaded the Win 11 WDK, but the installer said it’s the Win 10 WDK. Maybe a typo on Microsoft’s part?

@“Peter_Viscarola_(OSR)” said:

Does Windows 10 x64 still support ISA? I think it does, but we haven’t been able to find any examples, even in industrial computing applications

As far as I know, yes it does. See this NTDEV thread.

I have Visual Studio Professional 2019 Version 16.11.9 installed and I installed the 2004 version of the WDK for Win 10.

…

I selected New->Project, but there is no Windows Driver category, or anything that has anything to do with drivers available.

OK. You could very well have run into the well known “I installed the WDK with VS, but the I don’t see any driver type projects” problem. I’ve had that happen to me, and I’ve seen it happen to countless clients/students/colleagues over the years.

First, you really DO want to install the Windows 11 WDK. This is the latest WDK, it works with VS 2019 (only) and it’s the right WDK to use for Win 10 driver development.

Sooooo… REMOVE the 2004 version of the WDK for Win 10. Install the SDK and WDK as described on the MSFT page. BE SURE to select the option, offered at the end, after the install finishes, to install the whatever-it-is components to hook-up with VS at the end (THIS not working, or not being requested, is what most typically causes the projects to not show up.

Let us know how that goes,

Peter

I removed the old Win 10 WDK and installed the new one, but I didn’t get the option to install anything else at the end. I noticed there is an EWDK, do I need to install that? It says it’s a stand alone development environment, so I would guess not.

I extracted all the install files and stored them on my NAS before I began. A practice I do whenever possible because online installers can end up pointing to dead links eventually. Something MS does more than just about anyone else. Is there a stand alone MSI that will connect this with VS?

OK, it did ask me the question:
Install Windows Driver Kit Visual Studio extension to complete integration with Visual Studio, the Windows Driver Kit extension is required.

The only option was “Close”. I made sure the check was set and clicked Close. It came back immediately saying:
The install of “Windows Driver Kit” was not successful for all of the selected products. For more information click on the install log link at the bottom of the dialog.

Here is the contents of the log:

2/1/2022 6:53:32 PM - Microsoft VSIX Installer
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - vsixinstaller.exe version:
2/1/2022 6:53:32 PM - 16.9.1050
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - Command line parameters:
2/1/2022 6:53:32 PM - C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\VSIXInstaller.exe,/a,C:\Program Files (x86)\Windows Kits\10\Vsix\VS2019\WDK.vsix,/callingprocessid:11432,/installas:1996
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:32 PM - Microsoft VSIX Installer
2/1/2022 6:53:32 PM - -------------------------------------------
2/1/2022 6:53:33 PM - Skipping product Microsoft.VisualStudio.Product.Professional (10f4b98e) since it does not support extensions
2/1/2022 6:53:33 PM - Initializing Install…
2/1/2022 6:53:33 PM - Extension Details…
2/1/2022 6:53:33 PM - Identifier : Microsoft.Windows.DriverKit
2/1/2022 6:53:33 PM - Name : Windows Driver Kit
2/1/2022 6:53:33 PM - Author : Microsoft Corporation
2/1/2022 6:53:33 PM - Version : 10.0.21381.0
2/1/2022 6:53:33 PM - Description : A set of extensions that integrates Windows Driver development into Visual Studio.
2/1/2022 6:53:33 PM - Locale : en-US
2/1/2022 6:53:33 PM - MoreInfoURL :
2/1/2022 6:53:33 PM - InstalledByMSI : False
2/1/2022 6:53:33 PM - SupportedFrameworkVersionRange : [4.5,)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - SignatureState : ValidSignature
2/1/2022 6:53:33 PM - SignedBy : Microsoft Corporation
2/1/2022 6:53:33 PM - Certificate Info :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - [Subject] : CN=Microsoft Corporation, OU=OPC, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
2/1/2022 6:53:33 PM - [Issuer] : CN=Microsoft Code Signing PCA 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
2/1/2022 6:53:33 PM - [Serial Number] : 33000003C93EFB7FE21A3D22B30000000003C9
2/1/2022 6:53:33 PM - [Not Before] : 12/15/2020 1:24:05 PM
2/1/2022 6:53:33 PM - [Not After] : 12/2/2021 1:24:05 PM
2/1/2022 6:53:33 PM - [Thumbprint] : E120FF932F2D4DFB59B1DA16BA7C397119E2DEBF
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Supported Products :
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Community
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Pro
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM - Microsoft.VisualStudio.Enterprise
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - References :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - Identifier : Microsoft.VisualStudio.MPF
2/1/2022 6:53:33 PM - Name : Visual Studio MPF
2/1/2022 6:53:33 PM - Version : [11.0,12.0)
2/1/2022 6:53:33 PM - MoreInfoURL :
2/1/2022 6:53:33 PM - Nested : No
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Prerequisites :
2/1/2022 6:53:33 PM - -------------------------------------------------------
2/1/2022 6:53:33 PM - Identifier : Microsoft.VisualStudio.Component.CoreEditor
2/1/2022 6:53:33 PM - Name : Visual Studio core editor
2/1/2022 6:53:33 PM - Version : [16.0,17.0)
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Signature Details…
2/1/2022 6:53:33 PM - Extension is signed with a valid signature.
2/1/2022 6:53:33 PM -
2/1/2022 6:53:33 PM - Searching for applicable products…
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2010 Professional
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Professional 2013
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2013 Shell (Integrated)
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Professional 2015
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio Community 2015
2/1/2022 6:53:33 PM - Found installed product - Microsoft Visual Studio 2015 Shell (Integrated)
2/1/2022 6:53:33 PM - Found installed product - Global Location
2/1/2022 6:53:33 PM - Found installed product - Visual Studio Professional 2017
2/1/2022 6:53:33 PM - VSIXInstaller.NoApplicableSKUsException: This extension is not installable on any currently installed products.
at VSIXInstaller.ExtensionService.GetInstallableDataImpl(IInstallableExtension extension, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable`1& skuData)
at VSIXInstaller.ExtensionService.GetInstallableData(String vsixPath, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable`1& skuData)
at VSIXInstaller.ExtensionPackService.IsExtensionPack(IStateData stateData, Boolean isRepairSupported)
at VSIXInstaller.ExtensionPackService.ExpandExtensionPackToInstall(IStateData stateData, Boolean isRepairSupported)
at VSIXInstaller.App.Initialize(Boolean isRepairSupported)
at VSIXInstaller.App.Initialize()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()

I have several versions of VS installed (I use VC 2010 the most). I have VS 2019 installed and it runs, but it didn’t show up in the list.

I finally got it to work. I completely uninstalled VS 2017 and VS 2019, then reinstalled VS 2019. When I reinstalled the WDK, another screen came up after the Install Windows Driver Kit VS Extension and I was able integrate the driver kit with VS 2019. They’re there now.

Thanks for the help.

Glad you got it sorted.

This is another example of the bandwidth / latency problem. Versus the ISA bus, USB is like a high bandwidth high latency network. Many algorithms have been designed to address this problem, but in general you need to be able to have more data ready to send or ‘in flight’ than just one byte at a time.

I know nothing about your particular problem, but that probably means redesigning the UM program to make the calls higher level ‘commands’ instead of simple read / write requests. That will be a breaking change between your driver and application. In your situation, that may or may not be a problem. Regulatory hurtles are often an impediment to changes of this kind on top of the obvious deployment problems.

good luck!

@MBond2 said:
This is another example of the bandwidth / latency problem. Versus the ISA bus, USB is like a high bandwidth high latency network. Many algorithms have been designed to address this problem, but in general you need to be able to have more data ready to send or ‘in flight’ than just one byte at a time.

I know nothing about your particular problem, but that probably means redesigning the UM program to make the calls higher level ‘commands’ instead of simple read / write requests. That will be a breaking change between your driver and application. In your situation, that may or may not be a problem. Regulatory hurtles are often an impediment to changes of this kind on top of the obvious deployment problems.

good luck!

This is an industrial tester with many I/O selectable based on the addressing. During a test it sets addresses in the test system to address a given I/O selection, then runs a test on that point. Signals are injected on a point by setting a D2A, and measurements are made by reading the A2D connected to that point. The A2D should have been implemented with a hardware interrupt, but the system polls it while doing a conversion.

Because of the polling, each D2A takes two 125us on USB, first send the messages to trigger the D2A, then come back to read it. With ISA it’s two ISA cycles most of the time, sometimes it takes 2 polls. A test will usually cycle through a bunch of I/O ports and run tests, one after another.

With USB I could combine a bunch of calls for setup, but for the A2D there isn’t any way around the delays at least the way the hardware is now.

If your USB device included one of the many available cheap microprocessors you could move all the processing down to the device and just use the host to control which programs to run.

Moving the work to a micro controller is exactly the right thing to do, but it will likely require a redesign of the UM program to send commands like ‘Run test suite A’ and expect a response with all of those test results. A whole batch of tests of tests get run by the microcontroller, and the results get sent back. If the OP can’t change the UM part, then this will be very hard.

One idea is that if there is some way that the driver can detect the start of test suite A without being explicitly told, it can send a command to the microcontroller to run the whole batch that is expected, and only return the first result to UM once all of the results are ready. Then the remaining test results can be satisfied from host memory without any device access and they will all complete quickly. This only works if you can expect a certain set of tests from the first IOCTL or something else

I was testing with a USB controller with a built in microcontroller from Cypress. I built a state machine in the microcontroller for I/O on the backplane bus of the tester and a FIFO system to pumping data through. I rewrote the I/O layer of the sending programs to take advantage of this.

We talked about moving more functionality to the microcontroller and there are a number of low level functions that could be on the microcontroller. The systems engineer (who also is the sales guy, it’s a small company) has talked about making an inexpensive system for simple testing that has an embedded PC in the test chassis and all you do is plug in a monitor, keyboard, and mouse. If that happens, it will be a while.

At the time I was working on USB there was a suite of programs and two accessed the hardware asynchronously during test. The programs with USB ran OK stand alone with the hardware, but I couldn’t get a full test with the two programs accessing the hardware during a test. I assumed there was a situation where the FIFO was getting mixes of data from the two programs almost at once. I was working on sorting that out when they drew me off to do other things.

The suite of programs are very old. The first of them was written in 1987 for Windows 1.0. The whole suite was released for Windows 2.0. I finished a port to 32 bit Windows when I started. It had stalled a few years before when they ran out of the money and the previous programmer got laid off. Over the last few years I’ve been writing a new program with all the functionality of the suite. At this point the two programs that access the hardware during test are combined in one program.

There is talk again of getting USB working. This time with only one program accessing the hardware it should be an easier problem. Ultimately some solution using a current standard bus is where they want to go. We’ve looked a little at industrial ethernet too. Right now they are building computers for customers with an industrial motherboard that has an ISA slot that costs around $1000.

If we have a solution that uses a standard bus like USB or ethernet that will save them the cost of having to build and support custom PCs. The customers can use any PC they want. In most labs that use this equipment, there are multiple users for the testers, so if each user can use their own laptop that will make a lot of users happy. Everyone can configure the software the way they like and not have to worry about other users as much.

That’s the long term goal, but short term we need a working x64 ISA driver.

On the driver build front I’m making some progress. I started out creating a KMDF bare bones driver and then started looking at the old driver to cut and paste. Upon researching further I found the old driver was built as WDM. I don’t know why, I think KMDF was a thing in 2010, but I created an empty WDM project and it compiled (with a few warnings that were cleaned up).

I’m experimenting with 32 bit first because I have a working 32 bit driver to compare to. I’ve hit the wall with Win 10 hiding things from the user. My test system is set up as quad boot: Win 7, an old version of Win 10 x86, an up to date version of Win 10 x86, and a new installation of Win 10 x64.

I remembered seeing the driver in Device Manager before, but I could not find it in the newer x86 version of Win 10. I enabled Show Hidden Devices and ended up going over every device in each sub-category. Just to do a sanity check and I went back to Win 7, the card’s driver shows up under “Non-Plug n Play Devices” when I select Show Hidden Devices. How do I see a non-PnP device in Win 10 device manager? I know it’s installed, I’ve done testing with the hardware on the Win 10 installation, and I reinstalled the entire software package (which installs the driver too) just to make sure.

You’ve just accidentally wandered into a very ugly area.

You initially asked: Does Windows 10 support ISA. The answer was: Yes, absolutely.

You have an old driver, that was presumably written before Windows 2000? That’s the case if the driver does not have handlers for IRP_MJ_PNP. In that case, you don’t have a WDM driver. You have a Windows NT V4 style, non-PnP and non-Power Management supporting driver.

These drivers are, for all intents and purposes, not supported on modern Windows systems. They might work; they might not work; it depends on the specifics of the system on which they are running.

This driver needs to be rewritten, and it’ll be easiest to rewrite it using WDF. When we do this for our clients, it’s usually “just” a matter of pulling the guts of the hardware manipulation code out of the old driver, and stuffing it into a new, modern, WDF structure. It’s not hard, but you DO need to know how to write WDF drivers.

There’s really no alternative.

Now, if your driver IS a WDM driver (if it handles IRP_MJ_PNP) well, then, there’s hope.

Peter

The driver was originally written by me in 2010. At the time the oldest OS in use was XP. I looked at the code and there are several uses of IRP_MJ_, specifically IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL. I assume that’s what I should be looking for?

The hardware though is not PnP. It’s a very old design that predates PnP technology and is very simple. The entire schematic fits on one A sized sheet of paper. Is non PnP hardware not supported by Win 10?