https://bugs.winehq.org/show_bug.cgi?id=42424
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Summary|Renesas Flash Programmer |Multiple programs using |V3.02.01 installer fails to |Driver Store installer |install USB drivers |"dpinst.exe" fail to |(NtQueryInformationToken |install drivers |missing support for |(NtQueryInformationToken |'TokenUIAccess') |missing support for | |'TokenUIAccess') (Renesas | |Flash Programmer V3.02.01, | |Hantek 6000B)
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Another one, from wine-devel:
https://www.winehq.org/pipermail/wine-devel/2022-January/205250.html
These programs are both using Microsoft's Driver Store redistributable installer dpinst.exe (or dpinst64.exe).
Unlike Anastasius at the time this bug was filed, I think it's possible and worthwhile to get some USB device drivers to work. Some Windows drivers can't work due to requiring kernel features (the big one is probably going to be arbitrary user space memory access via non-buffered ioctls), but others should be able to without difficulty. I've already introduced wineusb.sys, which as of the time of writing has enough functionality for at least one Windows driver to work.
Anyway, stubbing TokenUIAccess gets the installer further, but then it breaks later due to missing Driver Store functions in setupapi. These functions are undocumented and pretty much nobody has reverse-engineered them either. Given that dpinst.exe is a Microsoft component itself, and actually has at least some documentation to it (mostly in the form of its own help message printed when run with the /? switch) I think implementing a dpinst.exe replacement would be a more feasible approach.