Questions about the TL866 wine driver wrapper.

[braselectron]

Can you please better explain how you managed to "wrap" the windows driver so that wine could detect the driver correctly and make MiniPro work ?

I really would like to understand this concept because there are many situations where this could be the solution to use Win32 applications that need drivers under wine and could make Linux experience much simpler and avoid the VM/VBox solutions. This is very important for hardware enthusiasts and techs to "port" gadgets/instruments that rely on software and drivers to work full feature on GNU systems.

My special interest now (and I believe @radiomanV interest too) is the Hantek DSO's

I have the DSO-2250 USB and I was able to use openhantek (only the older version, could not get the newer versions to work) but with less features and partially functional (FFT and cursors don't work). If I could understand how to "wrap" the drivers (I understand that there are two to be considered in this case, a bootloader and a firmware) the "wine" experience would be much better than the VM. But the I really believe that the openhantek project has bigger goals as to "opensource" it, like the software for the TL866 hardware, since this could be the better way to have a development of new device support made by the community and not a single person in China that, one day, can stop updating and we are left with a "blackbox".

So, for now, I really believe that not only me but the GNU community (included here hardware hackers, ham radio enthusiasts, software developers, and so on) would benefit from a driver "wrapper" solution strategy "task force group".

Please share your thoughts and your interest in the wrapper for the Hantek DSO.

[radiomanV]

There's no driver wrapper but exe low level wrapper. No windows driver is involved here. Now, te technique used here is called function redirect or dll injection or hooking. More on this subject here https://en.m.wikipedia.org/wiki/Hooking The technique is quite simple, you replace the needed function by another one wich provide the desired functionality. You can achieve this by patching the original function address to point to another address, thus redirecting program flow to another location. The problem is how to patch the desired function at runtime, without physical exe modifications and before the application run? well, because the way of how windows loader works you can achieve this by studying what dll's(shared objects .so in Linux) are loaded at startup and force the loader to load a fake library(our wrapper of course).

Luckily i have discovered that if you put an system library in the same directory with the exe then the wine loader it loads that library instead of system-wide library.

The trick is to implement every function which that library exports or only to load that library and ensure that no function in that library is called(because if you call an nonexistent function you crash the program); this behavior is used in TL866 minipro.exe, the setupapi.dll is loaded but no original function is called because we patch the application to not to use these functions, the setupapi.dll is used here only to load our new code which will provide the new functionality.

In short this is how is working:

1. You execute Minipro.exe
2. The wine loader is loading the exe in memory(the app. is not running yet)
3. The wine loader then loads all required dependencies one by one (dll's)
4. For every dll which it loads is execute the library initialization routine DllMain to permit for every library to make his own initialization. (The app. is not running yet)
5. When is the turn for the setupapi.dll to load and we are in the DllMain routine, well then we begin to patch every function which doesn't work in linux by redirecting them at the new address.
6. Wine loader give control to the application entry point (main/winmain) and then the app. begin to run, but because we already patched her we achieve the new functionality. The big problem is that you must reverse engineer that application by disasemblying it and find every function address, function prototype, arguments and so on which is an heavy task even for an experienced programmer. The TL866 minipro wrapper was an experimental project more an proof of concept. And it was pure luck to have not so many functions(i have replaced only those functions which are incompatible with the Linux ecosystem, the usb read/write and usb open/close functions by using the linux libusb api).

I'm sure that by studying the Hantek DSO application you can achieve the same result; or maybe not, depending on how the app. is designed.

[braselectron]

Thank you for the feedback.

I will study the concept and post back my findings (and questions).

By the way, I found this: https://msdn.microsoft.com/windows/hardware/drivers/install/setupapi

And it says this:

Device installation software can use these functions to perform custom operations in class installers, co-installers, and device installation applications.

For device installation applications, Driver Install Frameworks (DIFx) provides high-level tools that abstract the low-level SetupAPI operations that install Plug and Play (PnP) function drivers and manage the association between application software and the drivers.

This with your explanation might be the clue.

[radiomanV]

The windows setupapi has no help here in wine applications. The driver is an kernel program and is very specific to OS low level. You can't run Windows drivers in Linux with wine. The setupapi.dll was choosen by me only to load my code, no function exported by this library is used, only the name matters here. In fact from what i saw, the hantek application (DSO-2250 USB.exe) don't use the setupapi.dll at all. All the low level usb communications reside in DSO2250USB.dll; this is the library you want to hack to make this app. to work in wine, but i tell you, its hard. Good luck.