Arbitrary DOS device name

[Daniel Kucera]

Hello all,

I have a Windows software which tries to access dos device name but it 
is failing:

0009:Call KERNEL32.CreateFileA(0060f588 
"\\.\d6CDE-0",40000000,00000002,00000000,00000003,00000000,00000000) 
ret=00b1117f
0009:Call ntdll.RtlInitAnsiString(0060f49c,0060f588 "\\.\d6CDE-0") 
ret=7b036296
0009:Ret  ntdll.RtlInitAnsiString() retval=0060f49c ret=7b036296
0009:Call ntdll.RtlAnsiStringToUnicodeString(3fff8bf8,0060f49c,00000000) 
ret=7b0362fb
0009:Ret  ntdll.RtlAnsiStringToUnicodeString() retval=00000000 
ret=7b0362fb
0009:Call ntdll._wcsicmp(3fff8c00 L"\\.\d6CDE-0",7b09d0c0 L"CONIN$") 
ret=7b0355c9
0009:Ret  ntdll._wcsicmp() retval=fffffff9 ret=7b0355c9
0009:Call ntdll._wcsicmp(3fff8c00 L"\\.\d6CDE-0",7b09d0ce L"CONOUT$") 
ret=7b035636
0009:Ret  ntdll._wcsicmp() retval=fffffff9 ret=7b035636
0009:Call ntdll.wcsncmp(3fff8c00 L"\\.\d6CDE-0",7b09d644 
L"\\.\",00000004) ret=7b035670
0009:Ret  ntdll.wcsncmp() retval=00000000 ret=7b035670
0009:Call ntdll.iswalpha(00000064) ret=7b0356cd
0009:Ret  ntdll.iswalpha() retval=00000102 ret=7b0356cd
0009:Call ntdll._wcsnicmp(3fff8c08 L"d6CDE-0",7b09d638 
L"PIPE\",00000005) ret=7b0356f5
0009:Ret  ntdll._wcsnicmp() retval=fffffff4 ret=7b0356f5
0009:Call ntdll._wcsnicmp(3fff8c08 L"d6CDE-0",7b09d624 
L"MAILSLOT\",00000009) ret=7b03570e
0009:Ret  ntdll._wcsnicmp() retval=fffffff7 ret=7b03570e
0009:Call ntdll.RtlIsDosDeviceName_U(3fff8c08 L"d6CDE-0") ret=7b035724
0009:Ret  ntdll.RtlIsDosDeviceName_U() retval=00000000 ret=7b035724
0009:Call ntdll.RtlDosPathNameToNtPathName_U(3fff8c00 
L"\\.\d6CDE-0",0060f458,00000000,00000000) ret=7b035769
0009:Ret  ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 
ret=7b035769
0009:Call 
ntdll.NtCreateFile(0060f454,40100080,0060f474,0060f460,00000000,00000000,00000002,00000001,00000060,00000000,00000000) 
ret=7b03581e
0009:Ret  ntdll.NtCreateFile() retval=c0000034 ret=7b03581e
0009:Call ntdll.RtlNtStatusToDosError(c0000034) ret=7b035a11
0009:Ret  ntdll.RtlNtStatusToDosError() retval=00000002 ret=7b035a11
0009:Call ntdll.RtlFreeUnicodeString(0060f458) ret=7b03592b
0009:Ret  ntdll.RtlFreeUnicodeString() retval=0060f458 ret=7b03592b
0009:Ret  KERNEL32.CreateFileA() retval=ffffffff ret=00b1117f

The problem is, that wine doesn't recognize "\\.\d6CDE-0" as valid 
DOS device name:
https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2ae...

Even when I created the device in HKEY_LOCAL_MACHINE\Software\Wine\Ports 
it doesn't allow to open it.

When I patched the corresponding DLL to use COM81 and created the device 
in Ports, it works okay (can open the device).

I want to write a patch for ntdll/path.c to recognize my string as DOS 
device but I want it to be generic enough to be acceptable.

What approach do you suggest? Can I add a generic match, something like: 
"\\.\[^\]+$" ?

To add some context here, the software is for controlling USB 
osclloscope from Hantek:
http://hantek.com/uploadpic/hantek/files/20210731/Hantek-6000_Ver2.2.7_D2021...
It installs a driver which creates mentioned "DOS device" and 
communicates through it using ioctl.
I am reversing the driver and I'll create a Linux char device to handle 
those ioctl calls and talk to the USB device using libusb.

Thanks.

[Stefan Dösinger]

Am Montag, 24. Jänner 2022, 13:13:23 EAT schrieb Daniel Kucera:
> I am reversing the driver and I'll create a Linux char device to handle
> those ioctl calls and talk to the USB device using libusb.

If I understand you right you want to create a $WINEPREFIX/dosdevices/d6CDE-0 
link to whatever char device your Linux driver creates, and that doesn't work 
because Wine will only do that for COM ports and other drives?

From Wine's point of view the proper solution is to load the original Windows 
device driver, have it talk to the USB hardware via libusb and the Windows 
software via the device it creates. Wine nowadays should have infrastructure 
to support that. I haven't used it myself though.

Beyond opening the device name, how would the ioctl forward work? Is it some 
standard serial port ioctl that pass throuh Wine to your driver fine? Or would 
you need to teach Wine to forward them as well?

[Daniel Kucera]

On 2022-01-24 12:26, Stefan Dösinger wrote:
> Am Montag, 24. Jänner 2022, 13:13:23 EAT schrieb Daniel Kucera:
> > I am reversing the driver and I'll create a Linux char device to 
> > handle
> > those ioctl calls and talk to the USB device using libusb.
>
> If I understand you right you want to create a 
> $WINEPREFIX/dosdevices/d6CDE-0
> link to whatever char device your Linux driver creates, and that 
> doesn't work
> because Wine will only do that for COM ports and other drives?

I can create the link but wine refuses to open the device because it 
doesn't match any of the defined device prefixes: 
https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2ae...
> From Wine's point of view the proper solution is to load the original 
> Windows
> device driver, have it talk to the USB hardware via libusb and the 
> Windows
> software via the device it creates. Wine nowadays should have 
> infrastructure
> to support that. I haven't used it myself though.

I was researching this option but I haven't even found a way to load a 
driver.
Besides, if the original driver doesn't work out-of-the-box (which I 
presume it won't), I am not really able to write/compile wine/Windows 
driver.
> Beyond opening the device name, how would the ioctl forward work? Is it 
> some
> standard serial port ioctl that pass throuh Wine to your driver fine? 
> Or would
> you need to teach Wine to forward them as well?

So what works for me now is, that when I create the link COM81 -> 
/dev/hantek and create the device using cuse 
(https://libfuse.github.io/doxygen/cuse_8c.html) , the software is able 
to open the device:

FUSE library version: 3.10.3
  unique: 2, opcode: CUSE_INIT (4096), nodeid: 0, insize: 56, pid: 
1568849
  CUSE_INIT: 7.34
  flags=0x00000001
    CUSE_INIT: 7.31
    flags=0x00000001
    max_read=0x00020000
    max_write=0x00100000
    dev_major=0
    dev_minor=0
    dev_info: DEVNAME=hantek
    unique: 2, success, outsize: 103
  unique: 4, opcode: OPEN (14), nodeid: 0, insize: 48, pid: 1568962
    unique: 4, success, outsize: 32
  unique: 6, opcode: IOCTL (39), nodeid: 0, insize: 72, pid: 1568962
  unknown ioctld 21505
    unique: 6, error: -22 (Invalid argument), outsize: 16
  unique: 8, opcode: RELEASE (18), nodeid: 0, insize: 64, pid: 0
    unique: 8, success, outsize: 16

The software is calling DeviceIoControl() which results in ioctl calls 
in wine server and ends here:
https://github.com/wine-mirror/wine/blob/master/server/fd.c#L2408

To forward the call to device, I would need to modify this function, 
something in this sense:

diff --git a/server/fd.c b/server/fd.c
index 5d80e218b97..627b44fc195 100644
--- a/server/fd.c
+++ b/server/fd.c
@@ -2261,7 +2261,8 @@ int default_fd_ioctl( struct fd *fd, ioctl_code_t 
code, struct async *async )
          unmount_device( fd );
          return 1;
      default:
-        set_error( STATUS_NOT_SUPPORTED );
+       ioctl(fd->unix_fd, code, ioctl_data); // how the get the call 
data here?
+        //set_error( STATUS_NOT_SUPPORTED );
          return 0;
      }
  }

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=105983

Your paranoid android.

=== debian11 (build log) ===

error: corrupt patch at line 77
Task: Patch failed to apply

=== debian11 (build log) ===

error: corrupt patch at line 77
Task: Patch failed to apply

[Stefan Dösinger]

Am Dienstag, 25. Jänner 2022, 20:39:55 EAT schrieb Daniel Kucera:
> I was researching this option but I haven't even found a way to load a
> driver.
> Besides, if the original driver doesn't work out-of-the-box (which I
> presume it won't), I am not really able to write/compile wine/Windows
> driver.

I'm hoping that maybe Remi can chime in on this question.
> The software is calling DeviceIoControl() which results in ioctl calls
> in wine server and ends here:
> https://github.com/wine-mirror/wine/blob/master/server/fd.c#L2408
>
> To forward the call to device, I would need to modify this function,
> something in this sense:

One other option to investigate: Write a small Windows/Wine device driver that 
registers the character device and forwards it to the Unix device node. If you 
get that working you shouldn't need to modify wineserver in a very device 
specific way. In theory the API is also stable (Wine just implements the 
Windows driver API), so the Windows device driver can live out of tree.

See dlls/*.sys for some examples of existing device drivers; In particular 
mountmgr.sys, wineusb.sys are examples of drivers that talk to both the 
Windows and Unix side.

[Daniel Kucera]

On 2022-01-26 10:09, Stefan Dösinger wrote:
> One other option to investigate: Write a small Windows/Wine device 
> driver that
> registers the character device and forwards it to the Unix device node. 
> If you
> get that working you shouldn't need to modify wineserver in a very 
> device
> specific way. In theory the API is also stable (Wine just implements 
> the
> Windows driver API), so the Windows device driver can live out of tree.
>
> See dlls/*.sys for some examples of existing device drivers; In 
> particular
> mountmgr.sys, wineusb.sys are examples of drivers that talk to both the
> Windows and Unix side.

Okay, I'm going to try this. So far I have managed to compile an empty 
hantek.sys.so (copied and renamed tdi.sys).

danman@silverhorse:~/storage/Projects/hantek-usb/wine/dlls/hantek.sys$ 
ls -lah
total 256K
drwxrwxr-x   2 danman danman 4,0K jan 26 23:33 .
drwxrwxr-x 864 danman danman  36K jan 26 23:21 ..
-rw-rw-r--   1 danman danman  118 jan 26 23:33 .gitignore
-rw-rw-r--   1 danman danman 1,1K jan 26 23:33 hantek.sys.fake
-rwxrwxr-x   1 danman danman 126K jan 26 23:33 hantek.sys.so
-rw-rw-r--   1 danman danman 1,7K jan 26 23:21 hantek.sys.spec
-rw-rw-r--   1 danman danman 1,2K jan 26 23:22 main.c
-rw-rw-r--   1 danman danman  52K jan 26 23:33 main.o
-rw-rw-r--   1 danman danman  11K jan 26 23:33 Makefile
-rw-rw-r--   1 danman danman   95 jan 26 23:22 Makefile.in

How do I load it in wine now?

[Stefan Dösinger]

> Am 27.01.2022 um 01:36 schrieb Daniel Kucera :
>
> How do I load it in wine now?

Have a look at how mountmgr.sys is loaded. Tiere is a service in HKLM\System\CurrentControlSet\Services\MountMgr

Regarding potentially loading the original driver: Do you have a Windows installation with the driver installed? Look at where it is installed in the registry, maybe Wine has the necessary infrastructure to load it if you add it manually. Though all that is not exactly my area of expertise :-/

[Daniel Kucera]

On 2022-01-27 08:32, Stefan Dösinger wrote:
> > Am 27.01.2022 um 01:36 schrieb Daniel Kucera :
> >
> > How do I load it in wine now?
>
> Have a look at how mountmgr.sys is loaded. Tiere is a service in
> HKLM\System\CurrentControlSet\Services\MountMgr
>
> Regarding potentially loading the original driver: Do you have a
> Windows installation with the driver installed? Look at where it is
> installed in the registry, maybe Wine has the necessary infrastructure
> to load it if you add it manually. Though all that is not exactly my
> area of expertise :-/

I have copied the original driver to C: and installed like this:

wine sc create DSO6CDE binPath= C:\Hantek6000BAMD64.Sys type= kernel

This have resulted in ~ the same registry contents of 
HKLM\System\CurrentControlSet\Services\DSO6CDE as on my Windows 
installation but the driver doesn't work unfortunately.

For future reference, to install my driver I had to:

- build it (make)
- cp hantek.sys.so /usr/lib/x86_64-linux-gnu/wine/
- cp hantek.sys.fake ~/.wine/drive_c/windows/system32/drivers/hantek.sys
- wine sc create Hantek binPath= 
C:\windows\system32\drivers\hantek.sys type= kernel start= auto

Now when I run the app, I can see trace from the driver:

$ WINEDEBUG=trace+hantek wine Scope.exe
002b:trace:hantek:DriverEntry (000000000011FCA0, 
L"\Registry\Machine\System\CurrentControlSet\Services\Hantek") 
hantek
002b:trace:hantek:DriverEntry created device hantek

Now just the implementation... :)

Thank you for your help.

[Daniel Kucera]

On 2022-01-27 14:13, Daniel Kucera wrote:
> Now just the implementation... :)

Okay, so I have moved a bit further.

I can receive those ioctls in my driver which is great.

002b:trace:hantek:hantek_ioctl ioctl 222059 insize 10 outsize 10
002b:trace:hantek:hantek_ioctl indata 
"\x00\x02\x00\xf7\xea\xf8\x00\x00\x00\x00"

Now I am trying to write the usb part, so I tried to use libusb but 
there are two problems:

1. When I include libusb.h in my source file:
#include <libusb-1.0/libusb.h>

I am getting following when running ./configure --enable-win64 :
dlls/hantek.sys/main.c:31: error: system header libusb-1.0/libusb.h 
cannot be used with msvcrt

so I have done this to allow the configure to proceed but it is dirty:
          if (!strcmp( pFile->name, "stdarg.h" )) return NULL;
          fprintf( stderr, "%s:%d: error: system header %s cannot be used 
with msvcrt\n",
                   pFile->included_by->file->name, pFile->included_line, 
pFile->name );
-        exit(1);
+        //exit(1);

What is the proper way to fix this?

2. configure is generating broken Makefile:
hantek.sys.so hantek.sys.fake: hantek.sys.spec main.o 
../../dlls/ntoskrnl.exe/libntoskrnl.def \
   ../../dlls/msvcrt/libmsvcrt.a ../../dlls/winecrt0/libwinecrt0.a \
   ../../dlls/kernel32/libkernel32.def ../../dlls/ntdll/libntdll.def 
../../tools/winebuild/winebuild \
   ../../tools/winegcc/winegcc
         ../../tools/winegcc/winegcc -o $@ --wine-objdir ../.. -m64 -fPIC 
-fasynchronous-unwind-tables \
   -shared hantek.sys.spec -mno-cygwin -Wl,--subsystem,native main.o 
-lntoskrnl -lusb-1 $(LDFLAGS)

note the -lusb-1

while in Makefile.in I have specified:
IMPORTS   = ntoskrnl usb-1.0

I also tried 'usb-1.0' and usb-1.0 but none of them works.

How to fix this one? I am now manually editing the generated Makefile to 
-lusb-1.0

Despite these problems, the libusb seems to work correctly in the driver 
and I can query it's version:

$ WINEDEBUG=trace+hantek wine Scope.exe
002a:trace:hantek:DriverEntry Using libusb v1.0.24.11584

002a:trace:hantek:DriverEntry (000000000011FCB0, 
L"\Registry\Machine\System\CurrentControlSet\Services\Hantek") 
hantek
002a:trace:hantek:DriverEntry create device hantek 
(L"\Device\d6CDE-0") dos device (L"\DosDevices\d6CDE-0")
wine: Read access denied for device L"\??\Z:\", FS volume label and 
serial are not available.
wine: Read access denied for device L"\??\Z:\", FS volume label and 
serial are not available.
wine: Read access denied for device L"\??\Z:\", FS volume label and 
serial are not available.
wine: Read access denied for device L"\??\Z:\", FS volume label and 
serial are not available.
002b:trace:hantek:hantek_ioctl ioctl 222059 insize 10 outsize 10
002b:trace:hantek:hantek_ioctl indata 
"\x00\x02\x00\xf7\xea\xf8\x00\x00\x00\x00"

Thank you in advance.
Daniel.

[Daniel Kucera]

On 2022-01-27 20:52, Daniel Kucera wrote:
> Despite these problems, the libusb seems to work correctly in the
> driver and I can query it's version:

It probably won't be that easy. After some more calls, it is failing:

002a:trace:hantek:DriverEntry Using libusb v1.0.24.11584

tem32\winedevice.exe: ../../libusb/os/threads_posix.h:46: 
usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0' failed.
wine: Assertion failed at address 00007FDB2BA96808 (thread 002a), 
starting debugger...
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
000f:err:service:process_send_command service protocol error - failed to 
read pipe r = 0  count = 0!
000f:fixme:service:scmdatabase_autostart_services Auto-start service 
L"Hantek" failed to start: 1053

Is there any native wine usb api I can call?

[Daniel Kucera]

On 2022-01-27 21:49, Daniel Kucera wrote:
> On 2022-01-27 20:52, Daniel Kucera wrote:
> > Despite these problems, the libusb seems to work correctly in the
> > driver and I can query it's version:
>
> It probably won't be that easy. After some more calls, it is failing:
>
> 002a:trace:hantek:DriverEntry Using libusb v1.0.24.11584
>
> tem32\winedevice.exe: ../../libusb/os/threads_posix.h:46:
> usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0' failed.
> wine: Assertion failed at address 00007FDB2BA96808 (thread 002a),
> starting debugger...
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 002d:fixme:dbghelp:elf_search_auxv can't find symbol in module
> 000f:err:service:process_send_command service protocol error - failed
> to read pipe r = 0  count = 0!
> 000f:fixme:service:scmdatabase_autostart_services Auto-start service
> L"Hantek" failed to start: 1053
>
> Is there any native wine usb api I can call?

Good news!

I have been able to fix configure and mutex issue by removing 
-mno-cygwin option from Makefile.in
The other linker issue I fixed by specifying the lib name as:
IMPORTS   = ntoskrnl usb-1.0.
this removes the last dot and anything behind.

The driver works and I can run my scope app on wine!

My last question is how to build the driver off the tree? Is there any 
example/guide?

I plan to write a blog post after everything is solved to help others 
trying to write a driver.

Thank you.

[Stefan Dösinger]

Am Freitag, 28. Jänner 2022, 12:03:22 EAT schrieb Daniel Kucera:
> Good news!
>
> I have been able to fix configure and mutex issue by removing
> -mno-cygwin option from Makefile.in
> The other linker issue I fixed by specifying the lib name as:
> IMPORTS   = ntoskrnl usb-1.0.
> this removes the last dot and anything behind.
>
> The driver works and I can run my scope app on wine!

Gratulations! You got what you set out to do, although getting the original 
Windows driver to work would be nice to have too.
> My last question is how to build the driver off the tree? Is there any
> example/guide?

https://wiki.winehq.org/Winelib_User%27s_Guide is probably a starting point, 
although it is more about converting existing Windows software than writing 
something new and possibly outdated.

Look at the winegcc and winebuild invocations that the build system does with 
your in-tree driver. Also have a look at tools/winemaker.

[Zebediah Figura (she/her)]

On 1/24/22 04:13, Daniel Kucera wrote:
> To add some context here, the software is for controlling USB 
> osclloscope from Hantek:
> http://hantek.com/uploadpic/hantek/files/20210731/Hantek-6000_Ver2.2.7_D2021...
>
> It installs a driver which creates mentioned "DOS device" and 
> communicates through it using ioctl.
> I am reversing the driver and I'll create a Linux char device to handle 
> those ioctl calls and talk to the USB device using libusb.

I assume that you tried to install the original Windows driver in Wine 
and that it didn't work for some reason or another, right?

I might take a look and see if I can figure out what's going wrong; 
hardware devices and Windows drivers are an interest of mine.

On 2022-01-27 20:54, Zebediah Figura (she/her) wrote:
> I assume that you tried to install the original Windows driver in Wine
> and that it didn't work for some reason or another, right?

Correct.
> I might take a look and see if I can figure out what's going wrong;
> hardware devices and Windows drivers are an interest of mine.

Sure, if you are interested.

[Zebediah Figura]

What's going wrong is broadly bug 42424 [1]. I think the best solution 
is to reimplement dpinst.exe, and to that end I've written a replacement 
implementation, attached here. It's enough to actually install the 
drivers so that they'll be used when the device is plugged in, but I 
can't easily test without the device.

Since you already seem to be working with the Wine tree, would you mind 
applying this patch, rerunning the installer, and trying the native 
drivers? I'd be interested to see how well they work.

[1] https://bugs.winehq.org/show_bug.cgi?id=42424

On 2022-02-01 07:11, Zebediah Figura wrote:
> Since you already seem to be working with the Wine tree, would you
> mind applying this patch, rerunning the installer, and trying the
> native drivers? I'd be interested to see how well they work.

Thank you, I'll happily try.

I've applied the patch, copied the exe to system32 but there seems to be 
some problem:

$ wine ~/.wine/drive_c/windows/system32/dpinst64.exe
0009:err:module:__wine_process_init 
L"C:\windows\system32\dpinst64.exe" not found

[Zebediah Figura (she/her)]

On 2/1/22 05:28, [e-mail] wrote:
> On 2022-02-01 07:11, Zebediah Figura wrote:
> > Since you already seem to be working with the Wine tree, would you
> > mind applying this patch, rerunning the installer, and trying the
> > native drivers? I'd be interested to see how well they work.
>
> Thank you, I'll happily try.
>
> I've applied the patch, copied the exe to system32 but there seems to be 
> some problem:
>
> $ wine ~/.wine/drive_c/windows/system32/dpinst64.exe
> 0009:err:module:__wine_process_init 
> L"C:\windows\system32\dpinst64.exe" not found

That's because "wine" is symlinked to 32-bit wine, which redirects 
system32 to syswow64. "wine64" will work.

Note though that dpinst needs to be called with specific arguments, 
which is part of the reason I asked to rerun the installer.

One other thing I forgot to mention—you'll need to override dpinst64.exe 
as "builtin,native", since the default for the main EXE is 
native,builtin when loaded with an exact path.

On 2022-02-01 18:14, Zebediah Figura (she/her) wrote:
> That's because "wine" is symlinked to 32-bit wine, which redirects
> system32 to syswow64. "wine64" will work.

The result is the same with wine64

$ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
0009:err:module:__wine_process_init 
L"C:\windows\system32\dpinst64.exe" not found
> Note though that dpinst needs to be called with specific arguments,
> which is part of the reason I asked to rerun the installer.

I rerun the installer but nothing has changed.
> One other thing I forgot to mention—you'll need to override
> dpinst64.exe as "builtin,native", since the default for the main EXE
> is native,builtin when loaded with an exact path.

How do I do this? And more generally, how do I correctly install the 
compiled binary?
I just copied the exe to system32 as you can see above but I cannot run 
make install because I am using wine from distribution install (apt 
get).
I also tried to install wine from sources in a VM with fresh install of 
ubuntu but there I cannot even start wine. See attached log file.
I tried latest master and wine-6.23.

Thank you.

[Zebediah Figura]

On 2/1/22 11:39, [e-mail] wrote:
> On 2022-02-01 18:14, Zebediah Figura (she/her) wrote:
> > That's because "wine" is symlinked to 32-bit wine, which redirects
> > system32 to syswow64. "wine64" will work.
>
> The result is the same with wine64
>
> $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> 0009:err:module:__wine_process_init
> L"C:\windows\system32\dpinst64.exe" not found
> > Note though that dpinst needs to be called with specific arguments,
> > which is part of the reason I asked to rerun the installer.
>
> I rerun the installer but nothing has changed.
> > One other thing I forgot to mention—you'll need to override
> > dpinst64.exe as "builtin,native", since the default for the main EXE
> > is native,builtin when loaded with an exact path.
>
> How do I do this?

Generally, open winecfg, and in the "Libraries" tab type in 
"dpinst64.exe", then set the override to "builtin,native".

You can also use the environment variable 
"WINEDLLOVERRIDES=dpinst64.exe=b,n".
> And more generally, how do I correctly install the
> compiled binary?
> I just copied the exe to system32 as you can see above but I cannot run
> make install because I am using wine from distribution install (apt
> get).

Okay, my guess is that you're trying to use the system wine executable 
instead of wine from the build tree, and that wine is trying to look for 
builtin dpinst64.exe in /usr/lib/ as a result.

Note that to manually ensure things are installed into a prefix, you can 
usually use "wine wineboot -u".

On 2022-02-01 18:47, Zebediah Figura wrote:
> On 2/1/22 11:39, [e-mail] wrote:
> > On 2022-02-01 18:14, Zebediah Figura (she/her) wrote:
> > > That's because "wine" is symlinked to 32-bit wine, which redirects
> > > system32 to syswow64. "wine64" will work.
> >
> > The result is the same with wine64
> >
> > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > 0009:err:module:__wine_process_init
> > L"C:\windows\system32\dpinst64.exe" not found
> > > Note though that dpinst needs to be called with specific arguments,
> > > which is part of the reason I asked to rerun the installer.
> >
> > I rerun the installer but nothing has changed.
> > > One other thing I forgot to mention—you'll need to override
> > > dpinst64.exe as "builtin,native", since the default for the main EXE
> > > is native,builtin when loaded with an exact path.
> >
> > How do I do this?
>
> Generally, open winecfg, and in the "Libraries" tab type in
> "dpinst64.exe", then set the override to "builtin,native".
>
> You can also use the environment variable 
> "WINEDLLOVERRIDES=dpinst64.exe=b,n".
> > And more generally, how do I correctly install the
> > compiled binary?
> > I just copied the exe to system32 as you can see above but I cannot 
> > run
> > make install because I am using wine from distribution install (apt
> > get).
>
> Okay, my guess is that you're trying to use the system wine executable
> instead of wine from the build tree, and that wine is trying to look
> for builtin dpinst64.exe in /usr/lib/ as a result.
>
> Note that to manually ensure things are installed into a prefix, you
> can usually use "wine wineboot -u".

I checked with strace:

openat(AT_FDCWD, 
"/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY) = -1 
ENOENT (No such file or directory)
write(2, "0009:err:module:__wine_process_i"..., 
850009:err:module:__wine_process_init 
L"C:\windows\system32\dpinst64.exe" not found
) = 85

copied the lib:
sudo cp programs/dpinst64/dpinst64.exe.so 
/usr/lib/x86_64-linux-gnu/wine/

now I am getting:

$ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
002b:err:module:__wine_process_init 
L"C:\windows\system32\dpinst64.exe" not supported on this system

The same with setup.exe:

$ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64 
Setup.EXE
0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
0040:err:module:__wine_process_init L"C:\Program Files 
(x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
0042:err:module:__wine_process_init L"C:\Program Files 
(x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system

[Zebediah Figura]

On 2/1/22 13:25, [e-mail] wrote:
> I checked with strace:
>
> openat(AT_FDCWD,
> "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY) = -1
> ENOENT (No such file or directory)
> write(2, "0009:err:module:__wine_process_i"...,
> 850009:err:module:__wine_process_init
> L"C:\windows\system32\dpinst64.exe" not found
> ) = 85
>
> copied the lib:
> sudo cp programs/dpinst64/dpinst64.exe.so
> /usr/lib/x86_64-linux-gnu/wine/
>
> now I am getting:
>
> $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> 002b:err:module:__wine_process_init
> L"C:\windows\system32\dpinst64.exe" not supported on this system
>
> The same with setup.exe:
>
> $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> Setup.EXE
> 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> 0040:err:module:__wine_process_init L"C:\Program Files
> (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> 0042:err:module:__wine_process_init L"C:\Program Files
> (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system

If you're building with MinGW, you want to copy it as "dpinst64.exe", 
not "dpinst64.exe.so".

Probably easier is just to run the wine binary from the build tree 
instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't 
require installing anything at all.

[Daniel Kucera]

On 2022-02-01 22:39, Zebediah Figura wrote:
> On 2/1/22 13:25, [e-mail] wrote:
> > I checked with strace:
> >
> > openat(AT_FDCWD,
> > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY) = 
> > -1
> > ENOENT (No such file or directory)
> > write(2, "0009:err:module:__wine_process_i"...,
> > 850009:err:module:__wine_process_init
> > L"C:\windows\system32\dpinst64.exe" not found
> > ) = 85
> >
> > copied the lib:
> > sudo cp programs/dpinst64/dpinst64.exe.so
> > /usr/lib/x86_64-linux-gnu/wine/
> >
> > now I am getting:
> >
> > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > 002b:err:module:__wine_process_init
> > L"C:\windows\system32\dpinst64.exe" not supported on this system
> >
> > The same with setup.exe:
> >
> > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > Setup.EXE
> > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > 0040:err:module:__wine_process_init L"C:\Program Files
> > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > 0042:err:module:__wine_process_init L"C:\Program Files
> > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
>
> If you're building with MinGW, you want to copy it as "dpinst64.exe",
> not "dpinst64.exe.so".
>
> Probably easier is just to run the wine binary from the build tree
> instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> require installing anything at all.

It took me a while to understand what's wrong there - the setup.exe is 
32bit binary and I didn't run with wine64 so I have to recompile 32bit 
wine.
Now, when I am installing the software, I get following error:

0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
0138:err:module:import_dll Library USBD.SYS (which is needed by 
L"C:\Program Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys") not 
found
0150:err:module:import_dll Library USBD.SYS (which is needed by 
L"C:\Program Files\Hantek6000\Driver\Others\Hantek6000BX86.sys") 
not found
0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001

Is there something to do to "activate" usbd.sys support? Is it 
implemented at all?

Thank you for everything.

Daniel.

[Daniel Kucera]

On 2022-02-14 00:20, Daniel Kucera wrote:
> On 2022-02-01 22:39, Zebediah Figura wrote:
> > On 2/1/22 13:25, [e-mail] wrote:
> > > I checked with strace:
> > >
> > > openat(AT_FDCWD,
> > > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY) = 
> > > -1
> > > ENOENT (No such file or directory)
> > > write(2, "0009:err:module:__wine_process_i"...,
> > > 850009:err:module:__wine_process_init
> > > L"C:\windows\system32\dpinst64.exe" not found
> > > ) = 85
> > >
> > > copied the lib:
> > > sudo cp programs/dpinst64/dpinst64.exe.so
> > > /usr/lib/x86_64-linux-gnu/wine/
> > >
> > > now I am getting:
> > >
> > > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > 002b:err:module:__wine_process_init
> > > L"C:\windows\system32\dpinst64.exe" not supported on this system
> > >
> > > The same with setup.exe:
> > >
> > > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > > Setup.EXE
> > > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > 0040:err:module:__wine_process_init L"C:\Program Files
> > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > 0042:err:module:__wine_process_init L"C:\Program Files
> > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> >
> > If you're building with MinGW, you want to copy it as "dpinst64.exe",
> > not "dpinst64.exe.so".
> >
> > Probably easier is just to run the wine binary from the build tree
> > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > require installing anything at all.
>
> It took me a while to understand what's wrong there - the setup.exe is
> 32bit binary and I didn't run with wine64 so I have to recompile 32bit
> wine.
> Now, when I am installing the software, I get following error:
>
> 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> 0138:err:module:import_dll Library USBD.SYS (which is needed by
> L"C:\Program Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> not found
> 0150:err:module:import_dll Library USBD.SYS (which is needed by
> L"C:\Program Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> not found
> 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
>
> Is there something to do to "activate" usbd.sys support? Is it
> implemented at all?
>
> Thank you for everything.
>
> Daniel.

I've found out it is searching for usbd.sys in following paths:
0120:trace:module:load_dll looking for L"USBD.SYS" in 
L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
0120:err:module:import_dll Library USBD.SYS (which is needed by 
L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not 
found

but it was in system32/drivers so I copied it to system32. Now I am 
getting ntdll error:

$ WINEDEBUG=trace+dpinst wine Setup.EXE
0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
0158:err:ntdll:NtQueryInformationToken Unhandled token information class 
26
0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub

[Daniel Kucera]

On 2022-02-14 01:14, Daniel Kucera wrote:
> On 2022-02-14 00:20, Daniel Kucera wrote:
> > On 2022-02-01 22:39, Zebediah Figura wrote:
> > > On 2/1/22 13:25, [e-mail] wrote:
> > > > I checked with strace:
> > > >
> > > > openat(AT_FDCWD,
> > > > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY) 
> > > > = -1
> > > > ENOENT (No such file or directory)
> > > > write(2, "0009:err:module:__wine_process_i"...,
> > > > 850009:err:module:__wine_process_init
> > > > L"C:\windows\system32\dpinst64.exe" not found
> > > > ) = 85
> > > >
> > > > copied the lib:
> > > > sudo cp programs/dpinst64/dpinst64.exe.so
> > > > /usr/lib/x86_64-linux-gnu/wine/
> > > >
> > > > now I am getting:
> > > >
> > > > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > > 002b:err:module:__wine_process_init
> > > > L"C:\windows\system32\dpinst64.exe" not supported on this system
> > > >
> > > > The same with setup.exe:
> > > >
> > > > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > > > Setup.EXE
> > > > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > 0040:err:module:__wine_process_init L"C:\Program Files
> > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > > 0042:err:module:__wine_process_init L"C:\Program Files
> > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > >
> > > If you're building with MinGW, you want to copy it as "dpinst64.exe",
> > > not "dpinst64.exe.so".
> > >
> > > Probably easier is just to run the wine binary from the build tree
> > > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > > require installing anything at all.
> >
> > It took me a while to understand what's wrong there - the setup.exe is
> > 32bit binary and I didn't run with wine64 so I have to recompile 32bit
> > wine.
> > Now, when I am installing the software, I get following error:
> >
> > 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> > 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> > 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> > 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> > 0138:err:module:import_dll Library USBD.SYS (which is needed by
> > L"C:\Program Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> > not found
> > 0150:err:module:import_dll Library USBD.SYS (which is needed by
> > L"C:\Program Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> > not found
> > 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> >
> > Is there something to do to "activate" usbd.sys support? Is it
> > implemented at all?
> >
> > Thank you for everything.
> >
> > Daniel.
>
> I've found out it is searching for usbd.sys in following paths:
> 0120:trace:module:load_dll looking for L"USBD.SYS" in
> L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
> 0120:err:module:import_dll Library USBD.SYS (which is needed by
> L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not
> found
>
> but it was in system32/drivers so I copied it to system32. Now I am
> getting ntdll error:
>
> $ WINEDEBUG=trace+dpinst wine Setup.EXE
> 0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
> 0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
> 0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
> 0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
> 0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> 0158:err:ntdll:NtQueryInformationToken Unhandled token information 
> class 26
> 0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
> 0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub

I have patched my ntdll to respond to class 26 like this:

diff --git a/dlls/ntdll/unix/security.c b/dlls/ntdll/unix/security.c
index 8e3afd07..5fcd2fba 100644
--- a/dlls/ntdll/unix/security.c
+++ b/dlls/ntdll/unix/security.c
@@ -503,6 +503,10 @@ NTSTATUS WINAPI NtQueryInformationToken( HANDLE 
token, TOKEN_INFORMATION_CLASS c
          SERVER_END_REQ;
          break;

+    case TokenUIAccess:
+        status = STATUS_SUCCESS;
+       break;
+
      default:
          ERR( "Unhandled token information class %u\n", class );
          return STATUS_NOT_IMPLEMENTED;

Now I see something new - there is a driver install wizard showing 
failed installation of the driver so there is probably something wrong 
with the installation, see this video:
https://www.youtube.com/watch?v=Ko9gg6wVsX8

I can also see there is dpinst process while the wizard is on:
danman    498279 10.8  0.7 1938044 30568 ?       Ss   09:29   0:01 
C:\Program Files (x86)\Hantek6000\Bin\dpinst64.exe /F /EL /PATH 
C:\Program Files (x86)\Hantek6000\Driver\Win10

Daniel.

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=107886

Your paranoid android.

=== debian11 (build log) ===

error: corrupt patch at line 96
Task: Patch failed to apply

=== debian11 (build log) ===

error: corrupt patch at line 96
Task: Patch failed to apply

[Zebediah Figura]

On 2/14/22 03:49, Daniel Kucera wrote:
> On 2022-02-14 01:14, Daniel Kucera wrote:
> > On 2022-02-14 00:20, Daniel Kucera wrote:
> > > On 2022-02-01 22:39, Zebediah Figura wrote:
> > > > On 2/1/22 13:25, [e-mail] wrote:
> > > > > I checked with strace:
> > > > >
> > > > > openat(AT_FDCWD,
> > > > > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", O_RDONLY)
> > > > > = -1
> > > > > ENOENT (No such file or directory)
> > > > > write(2, "0009:err:module:__wine_process_i"...,
> > > > > 850009:err:module:__wine_process_init
> > > > > L"C:\windows\system32\dpinst64.exe" not found
> > > > > ) = 85
> > > > >
> > > > > copied the lib:
> > > > > sudo cp programs/dpinst64/dpinst64.exe.so
> > > > > /usr/lib/x86_64-linux-gnu/wine/
> > > > >
> > > > > now I am getting:
> > > > >
> > > > > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > > > 002b:err:module:__wine_process_init
> > > > > L"C:\windows\system32\dpinst64.exe" not supported on this system
> > > > >
> > > > > The same with setup.exe:
> > > > >
> > > > > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > > > > Setup.EXE
> > > > > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > 0040:err:module:__wine_process_init L"C:\Program Files
> > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > > > 0042:err:module:__wine_process_init L"C:\Program Files
> > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > >
> > > > If you're building with MinGW, you want to copy it as "dpinst64.exe",
> > > > not "dpinst64.exe.so".
> > > >
> > > > Probably easier is just to run the wine binary from the build tree
> > > > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > > > require installing anything at all.
> > >
> > > It took me a while to understand what's wrong there - the setup.exe is
> > > 32bit binary and I didn't run with wine64 so I have to recompile 32bit
> > > wine.
> > > Now, when I am installing the software, I get following error:
> > >
> > > 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> > > 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> > > 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> > > 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> > > 0138:err:module:import_dll Library USBD.SYS (which is needed by
> > > L"C:\Program Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> > > not found
> > > 0150:err:module:import_dll Library USBD.SYS (which is needed by
> > > L"C:\Program Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> > > not found
> > > 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > >
> > > Is there something to do to "activate" usbd.sys support? Is it
> > > implemented at all?
> > >
> > > Thank you for everything.
> > >
> > > Daniel.
> >
> > I've found out it is searching for usbd.sys in following paths:
> > 0120:trace:module:load_dll looking for L"USBD.SYS" in
> > L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
> > 0120:err:module:import_dll Library USBD.SYS (which is needed by
> > L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not
> > found
> >
> > but it was in system32/drivers so I copied it to system32. Now I am
> > getting ntdll error:
> >
> > $ WINEDEBUG=trace+dpinst wine Setup.EXE
> > 0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
> > 0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
> > 0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
> > 0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
> > 0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > 0158:err:ntdll:NtQueryInformationToken Unhandled token information
> > class 26
> > 0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
> > 0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub
>
> I have patched my ntdll to respond to class 26 like this:
>
> diff --git a/dlls/ntdll/unix/security.c b/dlls/ntdll/unix/security.c
> index 8e3afd07..5fcd2fba 100644
> --- a/dlls/ntdll/unix/security.c
> +++ b/dlls/ntdll/unix/security.c
> @@ -503,6 +503,10 @@ NTSTATUS WINAPI NtQueryInformationToken( HANDLE
> token, TOKEN_INFORMATION_CLASS c
>            SERVER_END_REQ;
>            break;
> - case TokenUIAccess:
> -
>    status = STATUS_SUCCESS;
> -
>   break;
> -
>  default:
>      ERR( "Unhandled token information class %u\n", class );
>      return STATUS_NOT_IMPLEMENTED;
>
> Now I see something new - there is a driver install wizard showing
> failed installation of the driver so there is probably something wrong
> with the installation, see this video:
> https://www.youtube.com/watch?v=Ko9gg6wVsX8
>
> I can also see there is dpinst process while the wizard is on:
> danman    498279 10.8  0.7 1938044 30568 ?       Ss   09:29   0:01
> C:\Program Files (x86)\Hantek6000\Bin\dpinst64.exe /F /EL /PATH
> C:\Program Files (x86)\Hantek6000\Driver\Win10

That's native dpinst, which is exactly what my builtin implementation is 
supposed to replace.

That said, if you're getting FIXMEs from usbd.sys, that should mean that 
the driver has already been installed and even enumerated, so I suppose 
you must have used builtin dpinst at some point. So now all that remains 
is to run the program and see if it manages to find its custom character 
device.

[Daniel Kucera]

On 2022-02-15 01:56, Zebediah Figura wrote:
> On 2/14/22 03:49, Daniel Kucera wrote:
> > On 2022-02-14 01:14, Daniel Kucera wrote:
> > > On 2022-02-14 00:20, Daniel Kucera wrote:
> > > > On 2022-02-01 22:39, Zebediah Figura wrote:
> > > > > On 2/1/22 13:25, [e-mail] wrote:
> > > > > > I checked with strace:
> > > > > >
> > > > > > openat(AT_FDCWD,
> > > > > > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", 
> > > > > > O_RDONLY)
> > > > > > = -1
> > > > > > ENOENT (No such file or directory)
> > > > > > write(2, "0009:err:module:__wine_process_i"...,
> > > > > > 850009:err:module:__wine_process_init
> > > > > > L"C:\windows\system32\dpinst64.exe" not found
> > > > > > ) = 85
> > > > > >
> > > > > > copied the lib:
> > > > > > sudo cp programs/dpinst64/dpinst64.exe.so
> > > > > > /usr/lib/x86_64-linux-gnu/wine/
> > > > > >
> > > > > > now I am getting:
> > > > > >
> > > > > > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > > > > 002b:err:module:__wine_process_init
> > > > > > L"C:\windows\system32\dpinst64.exe" not supported on this 
> > > > > > system
> > > > > >
> > > > > > The same with setup.exe:
> > > > > >
> > > > > > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > > > > > Setup.EXE
> > > > > > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > > 0040:err:module:__wine_process_init L"C:\Program Files
> > > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > > > > 0042:err:module:__wine_process_init L"C:\Program Files
> > > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this system
> > > > >
> > > > > If you're building with MinGW, you want to copy it as 
> > > > > "dpinst64.exe",
> > > > > not "dpinst64.exe.so".
> > > > >
> > > > > Probably easier is just to run the wine binary from the build tree
> > > > > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > > > > require installing anything at all.
> > > >
> > > > It took me a while to understand what's wrong there - the setup.exe 
> > > > is
> > > > 32bit binary and I didn't run with wine64 so I have to recompile 
> > > > 32bit
> > > > wine.
> > > > Now, when I am installing the software, I get following error:
> > > >
> > > > 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> > > > 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> > > > 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> > > > 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> > > > 0138:err:module:import_dll Library USBD.SYS (which is needed by
> > > > L"C:\Program Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> > > > not found
> > > > 0150:err:module:import_dll Library USBD.SYS (which is needed by
> > > > L"C:\Program 
> > > > Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> > > > not found
> > > > 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > >
> > > > Is there something to do to "activate" usbd.sys support? Is it
> > > > implemented at all?
> > > >
> > > > Thank you for everything.
> > > >
> > > > Daniel.
> > >
> > > I've found out it is searching for usbd.sys in following paths:
> > > 0120:trace:module:load_dll looking for L"USBD.SYS" in
> > > L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
> > > 0120:err:module:import_dll Library USBD.SYS (which is needed by
> > > L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not
> > > found
> > >
> > > but it was in system32/drivers so I copied it to system32. Now I am
> > > getting ntdll error:
> > >
> > > $ WINEDEBUG=trace+dpinst wine Setup.EXE
> > > 0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
> > > 0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
> > > 0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
> > > 0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
> > > 0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > 0158:err:ntdll:NtQueryInformationToken Unhandled token information
> > > class 26
> > > 0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
> > > 0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub
> >
> > I have patched my ntdll to respond to class 26 like this:
> >
> > diff --git a/dlls/ntdll/unix/security.c b/dlls/ntdll/unix/security.c
> > index 8e3afd07..5fcd2fba 100644
> > --- a/dlls/ntdll/unix/security.c
> > +++ b/dlls/ntdll/unix/security.c
> > @@ -503,6 +503,10 @@ NTSTATUS WINAPI NtQueryInformationToken( HANDLE
> > token, TOKEN_INFORMATION_CLASS c
> >            SERVER_END_REQ;
> >            break;
> > - case TokenUIAccess:
> > -
> >    status = STATUS_SUCCESS;
> > -
> >   break;
> > -
> >  default:
> >      ERR( "Unhandled token information class %u\n", class );
> >      return STATUS_NOT_IMPLEMENTED;
> >
> > Now I see something new - there is a driver install wizard showing
> > failed installation of the driver so there is probably something wrong
> > with the installation, see this video:
> > https://www.youtube.com/watch?v=Ko9gg6wVsX8
> >
> > I can also see there is dpinst process while the wizard is on:
> > danman    498279 10.8  0.7 1938044 30568 ?       Ss   09:29   0:01
> > C:\Program Files (x86)\Hantek6000\Bin\dpinst64.exe /F /EL /PATH
> > C:\Program Files (x86)\Hantek6000\Driver\Win10
>
> That's native dpinst, which is exactly what my builtin implementation
> is supposed to replace.
>
> That said, if you're getting FIXMEs from usbd.sys, that should mean
> that the driver has already been installed and even enumerated, so I
> suppose you must have used builtin dpinst at some point. So now all
> that remains is to run the program and see if it manages to find its
> custom character device.

I run the software after each change and it still cannot find the 
device.

But the driver seems to be installed:

danman@danman-VirtualBox:~/.wine/drive_c/Program Files (x86)/Hantek6000$ 
find ~/.wine/drive_c/windows/ | grep -i hant
/home/danman/.wine/drive_c/windows/inf/Hantek6000B.inf
/home/danman/.wine/drive_c/windows/inf/Hantek6000B.pnf
/home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969
/home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.inf
/home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.cat
/home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000BAMD64.SYS
/home/danman/.wine/drive_c/windows/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee}/Hantek6000B.cat

[Daniel Kucera]

On 2022-02-15 09:09, Daniel Kucera wrote:
> On 2022-02-15 01:56, Zebediah Figura wrote:
> > On 2/14/22 03:49, Daniel Kucera wrote:
> > > On 2022-02-14 01:14, Daniel Kucera wrote:
> > > > On 2022-02-14 00:20, Daniel Kucera wrote:
> > > > > On 2022-02-01 22:39, Zebediah Figura wrote:
> > > > > > On 2/1/22 13:25, [e-mail] wrote:
> > > > > > > I checked with strace:
> > > > > > > 
> > > > > > > openat(AT_FDCWD,
> > > > > > > "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", 
> > > > > > > O_RDONLY)
> > > > > > > = -1
> > > > > > > ENOENT (No such file or directory)
> > > > > > > write(2, "0009:err:module:__wine_process_i"...,
> > > > > > > 850009:err:module:__wine_process_init
> > > > > > > L"C:\windows\system32\dpinst64.exe" not found
> > > > > > > ) = 85
> > > > > > > 
> > > > > > > copied the lib:
> > > > > > > sudo cp programs/dpinst64/dpinst64.exe.so
> > > > > > > /usr/lib/x86_64-linux-gnu/wine/
> > > > > > > 
> > > > > > > now I am getting:
> > > > > > > 
> > > > > > > $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > > > > > 002b:err:module:__wine_process_init
> > > > > > > L"C:\windows\system32\dpinst64.exe" not supported on this 
> > > > > > > system
> > > > > > > 
> > > > > > > The same with setup.exe:
> > > > > > > 
> > > > > > > $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace wine64
> > > > > > > Setup.EXE
> > > > > > > 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > > > 0040:err:module:__wine_process_init L"C:\Program Files
> > > > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this 
> > > > > > > system
> > > > > > > 0042:err:module:__wine_process_init L"C:\Program Files
> > > > > > > (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this 
> > > > > > > system
> > > > > > >
> > > > > >
> > > > > > If you're building with MinGW, you want to copy it as 
> > > > > > "dpinst64.exe",
> > > > > > not "dpinst64.exe.so".
> > > > > >
> > > > > > Probably easier is just to run the wine binary from the build tree
> > > > > > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > > > > > require installing anything at all.
> > > > >
> > > > > It took me a while to understand what's wrong there - the setup.exe 
> > > > > is
> > > > > 32bit binary and I didn't run with wine64 so I have to recompile 
> > > > > 32bit
> > > > > wine.
> > > > > Now, when I am installing the software, I get following error:
> > > > >
> > > > > 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> > > > > 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> > > > > 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> > > > > 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> > > > > 0138:err:module:import_dll Library USBD.SYS (which is needed by
> > > > > L"C:\Program 
> > > > > Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> > > > > not found
> > > > > 0150:err:module:import_dll Library USBD.SYS (which is needed by
> > > > > L"C:\Program 
> > > > > Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> > > > > not found
> > > > > 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > >
> > > > > Is there something to do to "activate" usbd.sys support? Is it
> > > > > implemented at all?
> > > > >
> > > > > Thank you for everything.
> > > > >
> > > > > Daniel.
> > > >
> > > > I've found out it is searching for usbd.sys in following paths:
> > > > 0120:trace:module:load_dll looking for L"USBD.SYS" in
> > > > L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
> > > > 0120:err:module:import_dll Library USBD.SYS (which is needed by
> > > > L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not
> > > > found
> > > >
> > > > but it was in system32/drivers so I copied it to system32. Now I am
> > > > getting ntdll error:
> > > >
> > > > $ WINEDEBUG=trace+dpinst wine Setup.EXE
> > > > 0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
> > > > 0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
> > > > 0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
> > > > 0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
> > > > 0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > 0158:err:ntdll:NtQueryInformationToken Unhandled token information
> > > > class 26
> > > > 0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
> > > > 0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub
> > >
> > > I have patched my ntdll to respond to class 26 like this:
> > >
> > > diff --git a/dlls/ntdll/unix/security.c b/dlls/ntdll/unix/security.c
> > > index 8e3afd07..5fcd2fba 100644
> > > --- a/dlls/ntdll/unix/security.c
> > > +++ b/dlls/ntdll/unix/security.c
> > > @@ -503,6 +503,10 @@ NTSTATUS WINAPI NtQueryInformationToken( HANDLE
> > > token, TOKEN_INFORMATION_CLASS c
> > >            SERVER_END_REQ;
> > >            break;
> > > - case TokenUIAccess:
> > > -
> > >    status = STATUS_SUCCESS;
> > > -
> > >   break;
> > > -
> > >  default:
> > >      ERR( "Unhandled token information class %u\n", class );
> > >      return STATUS_NOT_IMPLEMENTED;
> > >
> > > Now I see something new - there is a driver install wizard showing
> > > failed installation of the driver so there is probably something 
> > > wrong
> > > with the installation, see this video:
> > > https://www.youtube.com/watch?v=Ko9gg6wVsX8
> > >
> > > I can also see there is dpinst process while the wizard is on:
> > > danman    498279 10.8  0.7 1938044 30568 ?       Ss   09:29   0:01
> > > C:\Program Files (x86)\Hantek6000\Bin\dpinst64.exe /F /EL /PATH
> > > C:\Program Files (x86)\Hantek6000\Driver\Win10
> >
> > That's native dpinst, which is exactly what my builtin implementation
> > is supposed to replace.
> >
> > That said, if you're getting FIXMEs from usbd.sys, that should mean
> > that the driver has already been installed and even enumerated, so I
> > suppose you must have used builtin dpinst at some point. So now all
> > that remains is to run the program and see if it manages to find its
> > custom character device.
>
> I run the software after each change and it still cannot find the 
> device.
>
> But the driver seems to be installed:
>
> danman@danman-VirtualBox:~/.wine/drive_c/Program Files
> (x86)/Hantek6000$ find ~/.wine/drive_c/windows/ | grep -i hant
> /home/danman/.wine/drive_c/windows/inf/Hantek6000B.inf
> /home/danman/.wine/drive_c/windows/inf/Hantek6000B.pnf
> /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969
> /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.inf
> /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.cat
> /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000BAMD64.SYS
> /home/danman/.wine/drive_c/windows/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee}/Hantek6000B.cat

The inf file contains a definition of a service:

[DSO6CDE.AddServiceAmd64]
DisplayName = %SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %10%\System32\Drivers\Hantek6000BAMD64.SYS

When I check my Windows installation, the service is present in registry 
(see attached export).
But it is not present in Wine. So I tried to load the export.
The service still hasn't been started on wine start so I changed Start 
DWORD from 3 to 2

Now I see the service failing start:

003c:trace:service:process_send_start_message 0000000000158F60 
L"DSO6CDE" 0000000000000000 0
00d4:trace:service:service_handle_control L"winedevice" control 
2147483648 data 00000000001487D2 data_size 16
00d4:trace:service:OpenSCManagerW (null) (null) 0x1
00a0:trace:service:svcctl_OpenSCManagerW ((null), (null), 1)
00d4:trace:service:OpenServiceW 0000000000148D40 L"DSO6CDE" 0x8001
00a0:trace:service:svcctl_OpenServiceW (L"DSO6CDE", 0x8001)
00d4:trace:service:CloseServiceHandle 0000000000148D40
00a0:trace:service:svcctl_CloseServiceHandle (&000000000015AC80)
00d4:trace:service:QueryServiceConfigW 0000000000148F60 0000000000000000 
0 0000000000A1FA50
00a0:trace:service:svcctl_QueryServiceConfigW (0000000000FCF978)
00d4:trace:service:QueryServiceConfigW 0000000000148F60 000000000014A1E0 
284 0000000000A1FA50
00a0:trace:service:svcctl_QueryServiceConfigW (0000000000FCF978)
00d4:trace:service:QueryServiceConfigW Image path           = 
L"\SystemRoot\System32\Drivers\Hantek6000BAMD64.SYS"
00d4:trace:service:QueryServiceConfigW Group                = L""
00d4:trace:service:QueryServiceConfigW Dependencies         = L""
00d4:trace:service:QueryServiceConfigW Service account name = 
L"LocalSystem"
00d4:trace:service:QueryServiceConfigW Display name         = 
L"@oem9.inf,%SvcDesc%;Hantek6000B Scope Service"
00d4:trace:service:SetServiceStatus 0000000000148F60 0x30 0x2 0 0 0 0 
0x2710
00a0:trace:service:svcctl_SetServiceStatus (000000000015ADD0, 
0000000000159F04)
00d4:err:ntoskrnl:ZwLoadDriver failed to create driver 
L"\Registry\Machine\System\CurrentControlSet\Services\DSO6CDE": 
c0000142
00d4:trace:service:SetServiceStatus 0000000000148F60 0x30 0x1 0 0 0 0 0
00a0:trace:service:svcctl_SetServiceStatus (000000000015ADD0, 
0000000000159EA4)
00d4:trace:service:CloseServiceHandle 0000000000148F60
00dc:trace:service:svcctl_CloseServiceHandle (&000000000015ADD0)
003c:trace:service:service_start returning 1114
003c:fixme:service:scmdatabase_autostart_services Auto-start service 
L"DSO6CDE" failed to start: 1114

And the program still cannot find the device.

[Daniel Kucera]

On 2022-02-15 10:19, Daniel Kucera wrote:
> On 2022-02-15 09:09, Daniel Kucera wrote:
> > On 2022-02-15 01:56, Zebediah Figura wrote:
> > > On 2/14/22 03:49, Daniel Kucera wrote:
> > > > On 2022-02-14 01:14, Daniel Kucera wrote:
> > > > > On 2022-02-14 00:20, Daniel Kucera wrote:
> > > > > > On 2022-02-01 22:39, Zebediah Figura wrote:
> > > > > > > On 2/1/22 13:25, [e-mail] wrote:
> > > > > > >> I checked with strace:
> > > > > > >> 
> > > > > > >> openat(AT_FDCWD,
> > > > > > >> "/usr/lib/wine/../x86_64-linux-gnu/wine/dpinst64.exe.so", 
> > > > > > >> O_RDONLY)
> > > > > > >> = -1
> > > > > > >> ENOENT (No such file or directory)
> > > > > > >> write(2, "0009:err:module:__wine_process_i"...,
> > > > > > >> 850009:err:module:__wine_process_init
> > > > > > >> L"C:\windows\system32\dpinst64.exe" not found
> > > > > > >> ) = 85
> > > > > > >> 
> > > > > > >> copied the lib:
> > > > > > >> sudo cp programs/dpinst64/dpinst64.exe.so
> > > > > > >> /usr/lib/x86_64-linux-gnu/wine/
> > > > > > >> 
> > > > > > >> now I am getting:
> > > > > > >> 
> > > > > > >> $ wine64 ~/.wine/drive_c/windows/system32/dpinst64.exe
> > > > > > >> 002b:err:module:__wine_process_init
> > > > > > >> L"C:\windows\system32\dpinst64.exe" not supported on this 
> > > > > > >> system
> > > > > > >> 
> > > > > > >> The same with setup.exe:
> > > > > > >> 
> > > > > > >> $ WINEDLLOVERRIDES=dpinst64.exe=b,n WINEDEBUG=dpinst+trace 
> > > > > > >> wine64
> > > > > > >> Setup.EXE
> > > > > > >> 0032:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > > >> 0040:err:module:__wine_process_init L"C:\Program Files
> > > > > > >> (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this 
> > > > > > >> system
> > > > > > >> 0042:err:module:__wine_process_init L"C:\Program Files
> > > > > > >> (x86)\Hantek6000\Bin\dpinst64.exe" not supported on this 
> > > > > > >> system
> > > > > > >> 
> > > > > > > 
> > > > > > > If you're building with MinGW, you want to copy it as 
> > > > > > > "dpinst64.exe",
> > > > > > > not "dpinst64.exe.so".
> > > > > > > 
> > > > > > > Probably easier is just to run the wine binary from the build 
> > > > > > > tree
> > > > > > > instead, e.g. "path/to/build/tree/wine64 Setup.EXE". That doesn't
> > > > > > > require installing anything at all.
> > > > > >
> > > > > > It took me a while to understand what's wrong there - the 
> > > > > > setup.exe is
> > > > > > 32bit binary and I didn't run with wine64 so I have to recompile 
> > > > > > 32bit
> > > > > > wine.
> > > > > > Now, when I am installing the software, I get following error:
> > > > > >
> > > > > > 0118:fixme:imm:ImeSetActiveContext (0x257560, 0): stub
> > > > > > 0118:fixme:imm:ImmReleaseContext (00020060, 00257560): stub
> > > > > > 0108:fixme:imm:ImeSetActiveContext (0x245220, 1): stub
> > > > > > 0108:fixme:imm:ImmReleaseContext (00020090, 00245220): stub
> > > > > > 0138:err:module:import_dll Library USBD.SYS (which is needed by
> > > > > > L"C:\Program 
> > > > > > Files\Hantek6000\Driver\Win10\Hantek6000BX86.sys")
> > > > > > not found
> > > > > > 0150:err:module:import_dll Library USBD.SYS (which is needed by
> > > > > > L"C:\Program 
> > > > > > Files\Hantek6000\Driver\Others\Hantek6000BX86.sys")
> > > > > > not found
> > > > > > 0108:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > >
> > > > > > Is there something to do to "activate" usbd.sys support? Is it
> > > > > > implemented at all?
> > > > > >
> > > > > > Thank you for everything.
> > > > > >
> > > > > > Daniel.
> > > > >
> > > > > I've found out it is searching for usbd.sys in following paths:
> > > > > 0120:trace:module:load_dll looking for L"USBD.SYS" in
> > > > > L"C:\users\danman\Temp;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\windows\system32\WindowsPowershell\v1.0"
> > > > > 0120:err:module:import_dll Library USBD.SYS (which is needed by
> > > > > L"C:\Program Files\Hantek6000\Driver\Others\HANT~1W0.SYS") not
> > > > > found
> > > > >
> > > > > but it was in system32/drivers so I copied it to system32. Now I am
> > > > > getting ntdll error:
> > > > >
> > > > > $ WINEDEBUG=trace+dpinst wine Setup.EXE
> > > > > 0044:fixme:imm:ImeSetActiveContext (0x257540, 0): stub
> > > > > 0044:fixme:imm:ImmReleaseContext (00010020, 00257540): stub
> > > > > 0024:fixme:imm:ImeSetActiveContext (0x245240, 1): stub
> > > > > 0024:fixme:imm:ImmReleaseContext (0001005A, 00245240): stub
> > > > > 0024:fixme:shell:SHChangeNotify ignoring unsupported flags: 2001
> > > > > 0158:err:ntdll:NtQueryInformationToken Unhandled token information
> > > > > class 26
> > > > > 0150:fixme:imm:ImeSetActiveContext (0x245380, 1): stub
> > > > > 0150:fixme:imm:ImmReleaseContext (000D00C6, 00245380): stub
> > > >
> > > > I have patched my ntdll to respond to class 26 like this:
> > > >
> > > > diff --git a/dlls/ntdll/unix/security.c b/dlls/ntdll/unix/security.c
> > > > index 8e3afd07..5fcd2fba 100644
> > > > --- a/dlls/ntdll/unix/security.c
> > > > +++ b/dlls/ntdll/unix/security.c
> > > > @@ -503,6 +503,10 @@ NTSTATUS WINAPI NtQueryInformationToken( HANDLE
> > > > token, TOKEN_INFORMATION_CLASS c
> > > >            SERVER_END_REQ;
> > > >            break;
> > > > - case TokenUIAccess:
> > > > -
> > > >    status = STATUS_SUCCESS;
> > > > -
> > > >   break;
> > > > -
> > > >  default:
> > > >      ERR( "Unhandled token information class %u\n", class );
> > > >      return STATUS_NOT_IMPLEMENTED;
> > > >
> > > > Now I see something new - there is a driver install wizard showing
> > > > failed installation of the driver so there is probably something 
> > > > wrong
> > > > with the installation, see this video:
> > > > https://www.youtube.com/watch?v=Ko9gg6wVsX8
> > > >
> > > > I can also see there is dpinst process while the wizard is on:
> > > > danman    498279 10.8  0.7 1938044 30568 ?       Ss   09:29   0:01
> > > > C:\Program Files (x86)\Hantek6000\Bin\dpinst64.exe /F /EL /PATH
> > > > C:\Program Files (x86)\Hantek6000\Driver\Win10
> > >
> > > That's native dpinst, which is exactly what my builtin implementation
> > > is supposed to replace.
> > >
> > > That said, if you're getting FIXMEs from usbd.sys, that should mean
> > > that the driver has already been installed and even enumerated, so I
> > > suppose you must have used builtin dpinst at some point. So now all
> > > that remains is to run the program and see if it manages to find its
> > > custom character device.
> >
> > I run the software after each change and it still cannot find the 
> > device.
> >
> > But the driver seems to be installed:
> >
> > danman@danman-VirtualBox:~/.wine/drive_c/Program Files
> > (x86)/Hantek6000$ find ~/.wine/drive_c/windows/ | grep -i hant
> > /home/danman/.wine/drive_c/windows/inf/Hantek6000B.inf
> > /home/danman/.wine/drive_c/windows/inf/Hantek6000B.pnf
> > /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969
> > /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.inf
> > /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000B.cat
> > /home/danman/.wine/drive_c/windows/system32/driverstore/filerepository/Hantek6000B.inf_8fc6bacdccaea0f2e123badfd166626c32bc0969/Hantek6000BAMD64.SYS
> > /home/danman/.wine/drive_c/windows/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee}/Hantek6000B.cat
>
> The inf file contains a definition of a service:
>
> [DSO6CDE.AddServiceAmd64]
> DisplayName = %SvcDesc%
> ServiceType = 1
> StartType = 3
> ErrorControl = 1
> ServiceBinary = %10%\System32\Drivers\Hantek6000BAMD64.SYS
>
> When I check my Windows installation, the service is present in
> registry (see attached export).
> But it is not present in Wine. So I tried to load the export.
> The service still hasn't been started on wine start so I changed Start
> DWORD from 3 to 2
>
> Now I see the service failing start:
>
> 003c:trace:service:process_send_start_message 0000000000158F60
> L"DSO6CDE" 0000000000000000 0
> 00d4:trace:service:service_handle_control L"winedevice" control
> 2147483648 data 00000000001487D2 data_size 16
> 00d4:trace:service:OpenSCManagerW (null) (null) 0x1
> 00a0:trace:service:svcctl_OpenSCManagerW ((null), (null), 1)
> 00d4:trace:service:OpenServiceW 0000000000148D40 L"DSO6CDE" 0x8001
> 00a0:trace:service:svcctl_OpenServiceW (L"DSO6CDE", 0x8001)
> 00d4:trace:service:CloseServiceHandle 0000000000148D40
> 00a0:trace:service:svcctl_CloseServiceHandle (&000000000015AC80)
> 00d4:trace:service:QueryServiceConfigW 0000000000148F60
> 0000000000000000 0 0000000000A1FA50
> 00a0:trace:service:svcctl_QueryServiceConfigW (0000000000FCF978)
> 00d4:trace:service:QueryServiceConfigW 0000000000148F60
> 000000000014A1E0 284 0000000000A1FA50
> 00a0:trace:service:svcctl_QueryServiceConfigW (0000000000FCF978)
> 00d4:trace:service:QueryServiceConfigW Image path           =
> L"\SystemRoot\System32\Drivers\Hantek6000BAMD64.SYS"
> 00d4:trace:service:QueryServiceConfigW Group                = L""
> 00d4:trace:service:QueryServiceConfigW Dependencies         = L""
> 00d4:trace:service:QueryServiceConfigW Service account name = 
> L"LocalSystem"
> 00d4:trace:service:QueryServiceConfigW Display name         =
> L"@oem9.inf,%SvcDesc%;Hantek6000B Scope Service"
> 00d4:trace:service:SetServiceStatus 0000000000148F60 0x30 0x2 0 0 0 0 
> 0x2710
> 00a0:trace:service:svcctl_SetServiceStatus (000000000015ADD0, 
> 0000000000159F04)
> 00d4:err:ntoskrnl:ZwLoadDriver failed to create driver
> L"\Registry\Machine\System\CurrentControlSet\Services\DSO6CDE":
> c0000142
> 00d4:trace:service:SetServiceStatus 0000000000148F60 0x30 0x1 0 0 0 0 0
> 00a0:trace:service:svcctl_SetServiceStatus (000000000015ADD0, 
> 0000000000159EA4)
> 00d4:trace:service:CloseServiceHandle 0000000000148F60
> 00dc:trace:service:svcctl_CloseServiceHandle (&000000000015ADD0)
> 003c:trace:service:service_start returning 1114
> 003c:fixme:service:scmdatabase_autostart_services Auto-start service
> L"DSO6CDE" failed to start: 1114
>
> And the program still cannot find the device.

Ok, the file was not in the correct location, I had to copy 
Hantek6000BAMD64.SYS to system32/drivers

I suppose all this (creating service, copying to system32/drivers) 
should be handled during the inf installation (maybe by dpinst?).

Now, the service is started correctly:

003c:trace:service:process_send_start_message 000000000015A790 
L"DSO6CDE" 0000000000000000 0
00d8:trace:service:service_handle_control L"winedevice" control 
2147483648 data 00000000001486E2 data_size 16
00d8:trace:service:OpenSCManagerW (null) (null) 0x1
00a8:trace:service:svcctl_OpenSCManagerW ((null), (null), 1)
00d8:trace:service:OpenServiceW 0000000000148650 L"DSO6CDE" 0x8001
00e0:trace:service:svcctl_OpenServiceW (L"DSO6CDE", 0x8001)
00d8:trace:service:CloseServiceHandle 0000000000148650
00a8:trace:service:svcctl_CloseServiceHandle (&000000000015B2E0)
00d8:trace:service:QueryServiceConfigW 0000000000148AA0 0000000000000000 
0 0000000000A1FA50
00e0:trace:service:svcctl_QueryServiceConfigW (000000000144F978)
00d8:trace:service:QueryServiceConfigW 0000000000148AA0 000000000014A230 
284 0000000000A1FA50
00a8:trace:service:svcctl_QueryServiceConfigW (00000000010EF978)
00d8:trace:service:QueryServiceConfigW Image path           = 
L"\SystemRoot\System32\Drivers\Hantek6000BAMD64.SYS"
00d8:trace:service:QueryServiceConfigW Group                = L""
00d8:trace:service:QueryServiceConfigW Dependencies         = L""
00d8:trace:service:QueryServiceConfigW Service account name = 
L"LocalSystem"
00d8:trace:service:QueryServiceConfigW Display name         = 
L"@oem9.inf,%SvcDesc%;Hantek6000B Scope Service"
00d8:trace:service:SetServiceStatus 0000000000148AA0 0x30 0x2 0 0 0 0 
0x2710
00e0:trace:service:svcctl_SetServiceStatus (000000000015BA00, 
000000000015AE34)
00d8:trace:service:SetServiceStatus 0000000000148AA0 0x30 0x4 0x5 0 0 0 
0
00a8:trace:service:svcctl_SetServiceStatus (000000000015BA00, 
000000000015AE34)
003c:trace:service:service_start returning 0

with trace+all I can see it imports some functions from usbd.sys:

56994.783:00c8:00d4:trace:loaddll:build_module Loaded 
L"C:\windows\System32\Drivers\USBD.SYS" at 00007FD8B7670000: builtin
56994.783:00c8:00d4:trace:module:load_dll Loaded module 
L"\??\C:\windows\System32\Drivers\USBD.SYS" at 00007FD8B7670000
00d4: close_handle( handle=0050 )
00d4: close_handle() = 0
56994.783:00c8:00d4:trace:heap:RtlFreeHeap 
(0000000000140000,30000062,000000000017F0E0): returning TRUE
56994.783:00c8:00d4:trace:virtual:NtProtectVirtualMemory 
0xffffffffffffffff 0xb63180 00000018 00000004
56994.783:00c8:00d4:trace:virtual:get_vprot_range_size base 0xb63000, 
size 0x2000, mask 0x20.
56994.783:00c8:00d4:trace:virtual:dump_view View: 0xb60000 - 0xb64fff 
(image)
56994.783:00c8:00d4:trace:virtual:dump_view       0xb60000 - 0xb62fff 
c-rWx
56994.783:00c8:00d4:trace:virtual:dump_view       0xb63000 - 0xb63fff 
c-rW-
56994.783:00c8:00d4:trace:virtual:dump_view       0xb64000 - 0xb64fff 
c-rWx
56994.783:00c8:00d4:trace:imports:import_dll --- 
USBD_CreateConfigurationRequestEx USBD.SYS.4 = 00007FD8B7679348
56994.783:00c8:00d4:trace:imports:import_dll --- 
USBD_ParseConfigurationDescriptorEx USBD.SYS.10 = 00007FD8B767936C
56994.783:00c8:00d4:trace:imports:import_dll --- USBD_GetUSBDIVersion 
USBD.SYS.8 = 00007FD8B7679430
56994.783:00c8:00d4:trace:virtual:NtProtectVirtualMemory 
0xffffffffffffffff 0xb63000 00001000 00000080
56994.783:00c8:00d4:trace:virtual:get_vprot_range_size base 0xb63000, 
size 0x2000, mask 0x20.
56994.783:00c8:00d4:trace:virtual:dump_view View: 0xb60000 - 0xb64fff 
(image)
56994.783:00c8:00d4:trace:virtual:dump_view       0xb60000 - 0xb64fff 
c-rWx
56994.783:00c8:00d4:trace:heap:RtlAllocateHeap 
(0000000000140000,30000062,00000020): returning 000000000017F6A0
56994.783:00c8:00d4:trace:module:build_module loaded 
L"\??\C:\windows\System32\Drivers\Hantek6000BAMD64.SYS" 
000000000017ED50 0000000000B60000
56994.783:00c8:00d4:trace:loaddll:build_module Loaded 
L"C:\windows\System32\Drivers\Hantek6000BAMD64.SYS" at 
0000000000B60000: native
56994.783:00c8:00d4:trace:module:load_dll Loaded module 
L"\??\C:\windows\System32\Drivers\Hantek6000BAMD64.SYS" at 
0000000000B60000
00d4: close_handle( handle=004c )
00d4: close_handle() = 0

But these functions are never called (no trace output from usbd) and the 
program still cannot find the device.

Are there any udev settings needed for the device to be "visible" by 
wine?
Is there some way how to trace a specific library (Hantek6000BAMD64.SYS) 
and find out what is it doing/calling?

[Zebediah Figura]

On 2/15/22 04:33, Daniel Kucera wrote:
> Ok, the file was not in the correct location, I had to copy
> Hantek6000BAMD64.SYS to system32/drivers
>
> I suppose all this (creating service, copying to system32/drivers)
> should be handled during the inf installation (maybe by dpinst?).

Not exactly.

The way it's supposed to work is, dpinst copies the inf file to 
C:/windows/inf/, and it copies all of the other files to the DriverStore 
directory. From the previous message it seems that's being done correctly.

When Windows detects a new device, it scans the C:/windows/inf/ 
directory for inf files that match, and if it finds one, then it 
"installs" it, which in practice means that only then the driver file 
will be copied to C:/windows/system32/drivers/, and the service registry 
entries created accordingly. At least, that's how it's supposed to work, 
provided I'm remembering all of the details correctly.
> But these functions are never called (no trace output from usbd) and the
> program still cannot find the device.
>
> Are there any udev settings needed for the device to be "visible" by
> wine?
> Is there some way how to trace a specific library (Hantek6000BAMD64.SYS)
> and find out what is it doing/calling?

We need to have permissions to access it. I would assume you already 
have those, if you're writing a user-space driver, but if not, I use a 
udev rules file with text like the following:

SUBSYSTEM=="usb", ATTR{idVendor}=="2040", MODE="0666"

(You can further limit it to the product, but I never bothered.)

If it still doesn't work, can you please attach a log with 
WINEDEBUG=+ntoskrnl,+pid,+plugplay,+setupapi,+wineusb ?

[Daniel Kucera]

On 2022-02-15 18:19, Zebediah Figura wrote:
> On 2/15/22 04:33, Daniel Kucera wrote:
> > Ok, the file was not in the correct location, I had to copy
> > Hantek6000BAMD64.SYS to system32/drivers
> >
> > I suppose all this (creating service, copying to system32/drivers)
> > should be handled during the inf installation (maybe by dpinst?).
>
> Not exactly.
>
> The way it's supposed to work is, dpinst copies the inf file to
> C:/windows/inf/, and it copies all of the other files to the
> DriverStore directory. From the previous message it seems that's being
> done correctly.
>
> When Windows detects a new device, it scans the C:/windows/inf/
> directory for inf files that match, and if it finds one, then it
> "installs" it, which in practice means that only then the driver file
> will be copied to C:/windows/system32/drivers/, and the service
> registry entries created accordingly. At least, that's how it's
> supposed to work, provided I'm remembering all of the details
> correctly.

Very interesting, thank you for information.
> > But these functions are never called (no trace output from usbd) and 
> > the
> > program still cannot find the device.
> >
> > Are there any udev settings needed for the device to be "visible" by
> > wine?
> > Is there some way how to trace a specific library 
> > (Hantek6000BAMD64.SYS)
> > and find out what is it doing/calling?
>
> We need to have permissions to access it. I would assume you already
> have those, if you're writing a user-space driver, but if not, I use a
> udev rules file with text like the following:
> SUBSYSTEM=="usb", ATTR{idVendor}=="2040", MODE="0666"
>
> (You can further limit it to the product, but I never bothered.)
>
> If it still doesn't work, can you please attach a log with
> WINEDEBUG=+ntoskrnl,+pid,+plugplay,+setupapi,+wineusb ?

The permissions look correct:

danman@danman-VirtualBox:~$ ls -lah /dev/bus/usb/001/
total 0
drwxr-xr-x 2 root root     80 úno 15 11:35 .
drwxr-xr-x 4 root root     80 úno 13 22:39 ..
crw-rw-r-- 1 root root 189, 0 úno 13 22:39 001
crw-rw-rw- 1 root root 189, 7 úno 15 11:35 008
danman@danman-VirtualBox:~$ lsusb
Bus 001 Device 008: ID 04b5:6cde ROHM LSI Systems USA, LLC DSO Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 80ee:0021 VirtualBox USB Tablet
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

See attached log.
Thank you.