Hi,
Please suggest me the most optimal driver structure for my situation:
1. I have two devices, one on an2131 and another on fx1. Both with the host-loaded firmwares.
2. Support for XP, Win7, Win 8/8.1, 10, 32/64 bit, except for XP (32 bit is enough).
As for now, I have two directories, "x86" and "x64". Each dir structure is as following:
dev.inf
ezload.sys+ezload.spt (firmware loader, spt file goes to system32\devload dir by the dev.inf)
fxload.sys+fxload.spt (same thing for fx1)
cyusb.sys (general access driver for the both firmware loaded devs)
ezusb.dll (my own client-side interfacing dll, works with cyusb.sys, copied to system32 to make things easier)
dev.cat (for the sake of digital signing)
ezload.sys and fxload.sys are the same cyusb.sys, renamed. This is to enable driver work when another twin device (remember, we should be able to use our an2131 and fx1 devices simultaneously) driver gets removed.
This stuff works, but we have a little problem: to remove/update firmware loading driver we need to manually delete spt file to make an spt loader .sys fail to operate. Otherwise, the loader starts and downloads so fast that we cannot catch it to delete in the windows dev manager!
And I'd like to have "one-button" install/remove procedure for the driver, if possible.
I'm trying to play with the dpinst.exe now but it's not that perfect either (though it removes the driver ok, both fw and non-fw instances, to the "Unknown Device" state, that's great). How it must be invoked by user? Seems like it's better to wrap dpinst by some installer creating app. Also, what I don't like about dpinst.exe is that it autocreates a package name using first model name found in INF (if I got it right). We have two devices so that is confusing to name only one, not the family. We could disable dpinst' control panel item creation and use some custom item created by an installer app. But I have doubts if this engineering is really optimal.
What do you think? What is the best practice for my case?
p.s. We are new to driver signing so being scared by Microsoft claims to stop supporting SHA-1, we sign it with SHA-2. Is that the right way we did it?
Regards,
Dmitry
