Possible help or direction to build Win to Linux pass through device - resent

Pavel Pisa pisa at cmp.felk.cvut.cz
Mon Jul 1 08:41:13 CDT 2013

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


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


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


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 Pisa
    e-mail:     pisa at cmp.felk.cvut.cz
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/

More information about the wine-devel mailing list