I have been developing ISA device driver for Windows 10.
I had been using the “LogConfig” directive to specify the driver’s resource listing, but Microsoft has deprecated it. I have been actively exploring alternative methods to address this problem. During my search, I came across a conversation related to this specific issue.[https://community.osr.com/discussion/293327/coming-back-to-driver-development/p2]. I attempted to utilize the “FactDef” method instead of the LogConfig in the inf file. However, this approach yielded the same error message of “Found legacy operation FactDef.”
Since these section has also been deprecated by Microsoft, I am currently in search of an alternative method to address this situation.
I would greatly appreciate it if someone could provide input on this matter.
So the docpage for factDef claims (or rather implies) that it remains supported for manually installed device drivers. It would be nice if they explained exactly what they mean by that and how your manually installed driver non-package differs from a manually installed driver package. In this thread here https://community.osr.com/discussion/293940/inf-file-for-legacy-isa-driver-error-submitting-to-microsoft#latest it isn’t clear if this was a failed attempt at WHQL signing or Attestation signing. If you can’t get it attestation signed then that’s the end of the story: it won’t install other than in test signing mode.
I"m the one who started the other thread you commented on, and yes I’m stuck in Microsoft hell about it. Since I last looked at the page on FactDef they added a caution
Caution
If you are building a universal or Windows Driver package, this section is not valid. See Using a Universal INF File and Getting Started with Windows Drivers.
Since my partner is a lawyer she’s taught me a lot about parsing rules. I would think from reading this that a universal driver is a subset of a Windows Driver, but it appears Microsoft describes a “Windows Driver” and a “Windows Desktop Driver” as two different things, and maybe a Windows Desktop Driver can use FactDef to specify resources in the INF. Maybe.
It would be nice if they specified where FactDef could be used rather than where it can’t be used using language that isn’t very precise.
If it can only be used in a Windows Desktop Driver, then how to you specify in the INF file that it’s a desktop driver? I can’t find any information on that at all. Googling
“Microsoft desktop driver” INF
Doesn’t yield anything useful.
I was able to install the driver with the settings to test drivers disabling the certification requirements. I had a lot of headaches getting the Azure account set up to upload a signed driver for Microsoft counter signing, but it was rejected because of the FactDef in the INF file.
Anybody know how to designate an INF file to be for a Microsoft Desktop Driver"?
Thanks for this discussion, I see the confusion here and will try to clarify this in the docs going forward.
There are two different aspects to this that are getting crossed - what will work functionally, and what will get a WHQL signature. FactDef and LogConfig are both deprecated, however the code that handles those directives is still present on desktop (this will not change). MS will no longer be providing a WHQL signature on INF files using deprecated directives, though.
So, yet another class of devices is forced back into attestation signing.
@Zac_Lockard
Thanks for the update.
Actually I am having ISA device, if LogConfig and FactDef it deprecated what is the alternate way to provide IRQ to driver.
Can you suggest some other method to Pass the IRQ to driver instead passing through INF file.
There is no alternative. You have to use those statements. You simply can’t get WHQL, end of story. NO ONE is going to be doing any new development for 40-year-old technology.
@Tim_Roberts said:
There is no alternative. You have to use those statements. You simply can’t get WHQL, end of story. NO ONE is going to be doing any new development for 40-year-old technology.
I was under the impression they cannot even self attest sign.
@Bill_Olson said:
I was able to install the driver with the settings to test drivers disabling the certification requirements. I had a lot of headaches getting the Azure account set up to upload a signed driver for Microsoft counter signing, but it was rejected because of the FactDef in the INF file.
Anybody know how to designate an INF file to be for a Microsoft Desktop Driver"?
@Tim_Roberts said:
So, yet another class of devices is forced back into attestation signing.
I was trying to do an attestation signing, but from what I understood you still needed to submit it to Microsoft to go though attestation signing. I’m I missing something?
I contacted Microsoft tech support and kept getting the run around. In my last exchange I asked the question directly if non-PnP hardware is no longer supported. So far the answer has been crickets. That was two days ago.
I’ve been talking to my customer and they are looking at the possibility of changing the hardware to include PnP circuitry. That may be the only way to get a 64 bit driver into their customers hands. We’ve been using a 32 bit driver, but many customers want a 64 bit driver because their corporate policies are pushing for all computers to be running a 64 bit OS. Corporate policies have also not been happy with a non-signed driver either.
I was under the impression they cannot even self attest sign.
Sure you can. There are no mandatory tests that must be passed for attestation signing.
@Bill_Olson said:
@Tim_Roberts said:
So, yet another class of devices is forced back into attestation signing.
I was trying to do an attestation signing, but from what I understood you still needed to submit it to Microsoft to go though attestation signing. I’m I missing something?
I don’t think you are missing anything. A while ago, the Microsoft Hardware Dashboard has been accepting my self attested driver submissions no problem and then one day it suddenly stopped accepting them and complained about the INF file. Luckily for us this was a simple adjust to the INF to get the dashboard to accept and sign them (our driver is PnP).
yes, attestation signing requires a valid inf if you are signing a pnp ‘driver package’. You can get non pnp drivers attestation signed, I wonder if there is an approach there where you get your driver .sys file signed and then manually install it. The end goal is to get the stupid thing installed, not to pass the whql/attestation inf tests.
@Tim_Roberts said:
I was under the impression they cannot even self attest sign.
Sure you can. There are no mandatory tests that must be passed for attestation signing.
There is an acceptance criteria for attestation signatures as of December, and any deprecated directives will not be accepted.
I’ve been talking to my customer and they are looking at the possibility of changing the hardware to include PnP circuitry.
In the absence of a definitive answer from Microsoft regarding their dashboard not accepting non-PnP drivers in any form, this would be my long term approach.
Short term I would look at a microcontroller and off the shelf USB to serial cable if, as indicated, your data rates are slow enough.
In the absence of a definitive answer from Microsoft regarding their dashboard not accepting non-PnP drivers in any form
You have an answer from Mr. Lockard, which is about as definitive as you can hope to get: “There is an acceptance criteria for attestation signatures as of December, and any deprecated directives will not be accepted.”
If Mr. Lockard said it, in this context, you can take it to the bank.
So… there’s the official policy.
Peter
You have an answer from Mr. Lockard, which is about as definitive as you can hope to get: “There is an acceptance criteria for attestation signatures as of December, and any deprecated directives will not be accepted.”
I fully accept that and agree.
Unfortunately I have managers who want unequivocal answers from Microsoft. I was thinking from that perspective. Luckily we have an OEM distributor for Microsoft product with a lot of clout. And we buy a lot of Microsoft product from them. So we tend to get those answers.
@rob18767 said:
Unfortunately I have managers who want unequivocal answers from Microsoft. I was thinking from that perspective.
Great point, I’ll update the INF documentation shortly to show this syntax as blocking. I also realized that we had labeled some (other) syntax as deprecated which is not yet blocking anything, so these updates will clarify the current status.
Thank you Zac for trying to help.
@rob18767 said:
I’ve been talking to my customer and they are looking at the possibility of changing the hardware to include PnP circuitry.
In the absence of a definitive answer from Microsoft regarding their dashboard not accepting non-PnP drivers in any form, this would be my long term approach.
Short term I would look at a microcontroller and off the shelf USB to serial cable if, as indicated, your data rates are slow enough.
The data rate is dead slow, however, the way the ISA interface works, it sends or receives only one byte at a time, and they did not implement an interrupt line when they built the hardware, so when the external hardware is doing an A to D conversion, the OS sits there and polls the interface.
They had tried a USB solution that just converted all the calls to the ISA to USB and the interface got slower than molasses in January. I dug into it and found that it was the way the USB protocol was set up. The USB controller gives each hardware device a sub-frame of 125 us to transfer all it can every 1 ms frame. With one byte per transfer, this slows down the transfer rate to 1 byte per ms.
I found some areas where I could pack up multiple bytes into one packet and speed things up some and wrote microcontroller code to unpack it on the external hardware end, but there were times when we would be stuck with one byte per ms. I got the hardware and code to the test phase, ran into some problems (I think processes were stepping on each other) and ran out of time to debug it. That was 10 years ago and they haven’t cut me loose to go back to it since. Someone else took it up a couple of years ago, but he didn’t understand the problem with the frames and sub-frames and didn’t want to listen to me so his efforts failed. He’s no longer with the company.
The company is very hardware oriented. I’m am the entire software department. Even though I have a degree in Electronic Engineering they don’t seem to want me to get too close to the hardware so the USB project has just sat on the shelf for a decade.
The guy I work with the most would like to do a USB interface, but his management is the roadblock.
The company is very hardware oriented. I’m am the entire software department.
After reading the rules (I do not work for FTDI) may I suggest
https://ftdichip.com/
They do USB to serial (UART) converters in chip and cable form. They have their own drivers.
As long you know how a UART works this could be your ‘plug and play’ interface. Add this to a microcontroller and you may have a solution.