Hello all Wine developers,
[the second attempt to send, is the list subscribers only?]
the firs I would like to express my respect to the work done.
Now to one of our application, we maintain open-source chromatographic software CHROMuLAN
https://sourceforge.net/projects/chromulan/
Unfortunately, it is written in Delphi (version 6 used) and we have not resources to port it to run native on Linux even that Linux is for last 18 years our main development platform for embedded hardware design and development. Our long term is to port application to Lazarus/FPC or even rewrite in in Qt but that is not option now.
Fortunately, the CHROMuLAN application runs quite well under latest Wine version. But we have problem with access to the data acquisition hardware.
The devices are connected to computer through special protocol (uLAN) RS-485 network. We have drivers for Linux (the firs platform), Windows (even 64-bit tested) and other targets. All for PCI, RS-232/485 converters and PCI RS-485 addon cards. Whole stack even runs under ReactOS in QEMU now. But Wine is more pleasant solution when someone uses Linux as his/her main desktop system.
https://sourceforge.net/projects/ulan/
Problem is that I loke to provide driver API to the Wine application. The real windows driver is KMD/WMD "ul_wdm.sys" which is registered as "\\.\UL_DRV" by IoCreateDevice and IoCreateSymbolicLink. Driver provides some context per each open and then read, write and iocts are used.
We have exactly the same drive for Linux (x86, 64-bit, MIPS, ARM, PowerPC) with same functionality but Linux IOCTLs numbers are built different way and there are some slight differences caused by differences in Win API IOCTLs processing and Windows does not support poll equivalent for devices too.
I have studied Wine and wineserver more times and have not found how to achieve provision of the Linux driver to the Wine application. Or more or less found that there would be problem because wineserver seems to deliver only IOCTLs events. But I was not sure so I have finally proven that by trial.
I have written DLL/SYS as a driver supporting all required IRP_MJ_xxx and IOCTLs in the style of KMD/WMD driver and implemented functions as calling to the Linux "/dev/ulan" operation equivalents.
But it really does not work. Only IOCTLs are delivered to the ul_drv.sys and even that fails because open context is not setup. Pointer irpStack->FileObject is filled with 0x66666666.
You can find my attempt at
http://cmp.felk.cvut.cz/~pisa/ulan/wine/
Now to the questions,
Is there some mechanism in Wine which I could use? Is there chance to do that as little intrusive (i.e. DLL) that it can be acceptable for Wine mainline?
It seems that serial port device somehow solves similar problem but is seems to be hardwired to wineserv.
As for my case, it is possible that read and write to the open /dev/ulan file are done directly from context of application if it receives Linux filehandle into wine/dlls/ntdll/file.c .
If the new FD_TYPE_ (FD_TYPE_SERIAL) is defined then all processing can be done in Linux native NTDLL. Even IOCTLs translation because they are really straightforward (like wine-git/dlls/ntdll/serial.c does in COMM_DeviceIoControl). But such solution seems intrusive to me.
On the other hand the structure struct object_ops in wine/wine/server/object.h seems to provide all operations.
Can I use some registration in the server to solve access? I am missing something? Is there some suggestion which approach to take?
Some reasonable simple solution is preferred because if projects takes too much time it would even more postpone possibility to start real application porting.
Thanks for each possible advice,
Pavel -- Pavel Pisa e-mail: pisa@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/