How to open, read and send on USB interface with Winbatch?

[Bill]

Hello Folks,

I used Winbatch to programm on the serial interface in the past and have now the need to do the same with USB but can't find any examples how to open, read and send the USB interface, if it doesn't provide or emulate an serial COM port (like COM1, COM2 and so on) just the device name only or vendor id. Can anybody help?

Thx in advance for a soon response, Bill

[ChuckC]

What kind of USB device are you attempting to communicate with?

Most USB devices come with a driver that presents the device to the operating system as a HID [Human Interface Device] such as a keyboard or mouse, audio output device [e.g., speakers/headphones/earbuds], a printer, a serial port [COM port], mass storage device [flash drive, hard disk drive, SSD], etc....

[Bill]

Thx for your Answer!!!

It's a measuring Device (Lab) with it's own Driver, called "libusb-win32 Usb Devices" by SGS Thomson Microelectronics, connected local on Port_#0001.Hub_#0002, no emulated serial Port number (like COM1, COM2 and so on) just the Port information as I mentioned before. I was thinking there is a Syntax for USB Devices in the Winbatch Extender, like for RS232 Devices, get a handle with Vendor ID or something like that and then just open the USB Port and read and write on it ... too easy thinking? :P

[td]

Since your device does not fit one of the built-in Windows USB classes you would likely need to use the Windows low-level Win32 APIs from the Winusb.dll file and Winusb.h header file to set up a pipe to your device. You could try and do that with DllCall function calls or by writing your own USB extender. I am not aware of any high-level cover technology like .Net to access the device that would provide the kind of functionality you desire.

The Win32 API documentation can be found here:

https://docs.microsoft.com/en-us/windows/win32/api/winusb/   

Perhaps another user who is aware of an easier method of communicating directly with a random USB device will post something.

[td]

There is the  Windows.Devices.Usb namespace but it is for Windows Runtime applications only.  That means it is not accessible to desktop applications like WinBatch. It appears to simply be a UWP cover for the Win32 API mentioned above.

[ChuckC]

A Google Search with the search parameters "sgs thomson microelectronics libusb-win32 Usb Devices" turns up some results that are applicable.

http://www.driverhive.com/DriverSearchResults.aspx?s=sgs+thomson+microelectronics

https://www.nuget.org/packages/libusb-win32-driver/

https://sourceforge.net/p/libusb-win32/wiki/Home/

https://sourceforge.net/p/libusb-win32/mailman/message/30227509/

From what I read, the Linux/Unix "libusb" project was ported to Windows, and what you find on Source Forge and NuGet are the project in source form and packaged-for-use form, respectively.  Per the notes on Source Forge, libusb-win32 is in bug-fix mode only and has been replaced by libusb-1.0 API & libusb Windows.

Anyway, the library is designed to allow user-mode code to interact with generic USB devices without having to have more device-specific drivers developed & installed.

On the libusb-win32 home page on Source Forge, search for the following text "For developers who want to use libusb-win32" and start reading from there regarding writing code to use libusb-win32.

I haven't looked at the "usb.h" header file or examined the library file "libusb0.dll" to see what functions it exports.  It is not guaranteed to be possible with WinBatch, but depending on the complexity of the API functions that libusb-win32 provides, you may be able to get by with DllLoad() & DllCall() in  WinBatch to interface with the piece of lab equipment that you have.  If that is not possible, then you have 2 additional methods that you can use to find a solution to the problem.  One would be to write a custom WinBatch extender that wraps up the libusb-win32 API functions and makes them more readily usable from within WinBatch.  The other is to write C# code which makes use of PInvoke [Platform Invoke] to make use of the functions exported by libusb0.dll and then dynamically compile that C# code within your WinBatch script, followed by using WinBatch's CLR support for the .NET Framework to utilize the functionality of the C# code that you wrote & compiled.

A subsequent Google Search for using libusb-win32 with C# returned the following promising links:

https://github.com/LibUsbDotNet/LibUsbDotNet

https://sourceforge.net/projects/libusbdotnet/

https://stackoverflow.com/questions/47810329/write-to-usb-port-c-sharp-using-libusbdotnet-c-sharp-usb-library

These links all refer to projects, source code and NuGet packages that are all newer [circa 2017] as compared to libusb-win32 [2016], and the discussion thread about "write-to-usb-port-c-sharp..." actually includes information about yet another .NET accessible library for USB communication, and may be an even better choice.

You now have a significant amount of homework to do w/respect to following up on these links and reading thru their content to get a better understanding of what you're going to have to do.  Any time that you can find a simple straight forward C# example or C/C++ example that demonstrates basic usage of the required API functions for interacting with a generic USB device, you'll have something to use as a reference for writing your WinBatch script and any additional "helper code" in C# or in a custom extender [C/C++].

[Bill]

Puuuhhhh :P

Thx for all that - and so much - information about this issue!! As you said: I have now a significant amount of homework to do :D

I reply in a couple of days, weeks, months, if I could check it out :P

Thank you very much again for your very detailed research!!!

[td]

Just a note.  The WinUSB.dll API can be used for user-mode applications as well kernel-mode drivers.  However, it does require that the driver "Winusb.sys"  be installed on the targeted Windows system and be the device's registered driver in order for user-mode applications to work correctly.  I have no idea if your device will work with the "Winusb.sys" driver so Chuck's suggestions are likely a better choice.

[td]

Another possible approach could/maybe/maybe-not option would be the DevicIoControl function:

https://docs.microsoft.com/en-us/windows/win32/api/ioapiset/nf-ioapiset-deviceiocontrol

There are several IOCL codles that apply to USB devices. Here is a reference to one of them:

https://docs.microsoft.com/en-us/windows/win32/api/genericusbfnioctl/ni-genericusbfnioctl-ioctl_genericusbfn_transfer_in

Never tried it so I don't know if it would work with a non-standard Windows device.

[ChuckC]

AFAIK, all of the user-mode libraries end up making DeviceIoControl() function calls as that is the single point of entry from user mode to kernel mode.  The part that varies significantly is what specific driver is being interacted with, as that determines which IOCTL codes are going to be used.

It is possible to open a handle to a device at various points in the driver stack and interact with it at different levels.  For example, with a mounted NTFS volume, you can open handles to files & directories on the volume, but you can also take an [un]mounted volume and open a handle to it to perform whole-volume related operations.  Likewise, you can open a handle to an underlying partition with unallocated space and perform operations to create a new volume, or expand or delete an existing volume.  And, again, you can open a handle to a disk drive itself and perform partition management operations.

As this all relates to USB devices, the same layered onion-like driver stack is in play, and so a USB device might be interacted with via its highest level driver where it appears as a keyboard, mouse or COM port.  But, the device can also be interacted with at a lower level by opening a handle to the device with the appropriate device name that channels the interactions thru a specific lower level driver.  In some cases, the presence of the higher level driver results in direct access being blocked at a lower level, with some admin-level tasks needing to be performed to disable the higher level driver.  In other cases, access is not restricted.  YMMV.


It's difficult to get any more specific with advice at this point since I do not have one of the USB devices that the OP has, so I cannot go hands-on for live testing in a dev lab.

[td]

WinBatch uses the DevicIoControl function in several places for a variety of reasons but mostly to query device drivers for device information including information about USB devices. However, WinBatch is focused on storage devices. And as you said without having access to the device in question the suggestion is little more than speculation.