I have an application that talks to hardware via the serial port. (Actually, it talks to a lot of hardware, banking peripherals). The app runs on both Win32 and OS/2. Of course, the main theme is porting the thing natively to linux (and I'm working on that). But just for fun I tried to get it to work with WINE, and while the "device emulation" works perfectly (much to my surprise, really good work guys!) the serial communication doesn't go far. The hardware receives the data, but the signals (RTS/CTS etc.) are NOT correctly handled by WINE. Is this an area that is being worked on?
Gerson Kurz <gerson.kurz@t-online.de> wrote: : : Is this an area that is being worked on? Mike McCormack did and does a lot of work around the serial port. What wine vintage did you try? Can you describe your problems more in deapth? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Gerson Kurz <gerson.kurz@t-online.de> wrote: :... : Of course, the main theme is porting the thing natively to linux (and I'm : working on that). But just for fun I tried to get it to work with WINE, and :... You know about winelib? After cleaning up your code (winemaker), .configure and make you have ( if things work smooth) a perfect Linux application, with no hassles of a code split. If you want to sell your application commercial, of course a code audit is needed to check if wine's implementation of the Win Api is enough for the requirements of your code. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Sun, 4 Nov 2001, Gerson Kurz wrote:> I have an application that talks to hardware via the serial port. > (Actually, it talks to a lot of hardware, banking peripherals). The app > runs on both Win32 and OS/2. > > Of course, the main theme is porting the thing natively to linux (and I'm > working on that). But just for fun I tried to get it to work with WINE, and > while the "device emulation" works perfectly (much to my surprise, really > good work guys!) the serial communication doesn't go far. The hardware > receives the data, but the signals (RTS/CTS etc.) are NOT correctly handled > by WINE. > > Is this an area that is being worked on?As I understand it, Wine does not attempt to "handle" the signals. That is up to the linux serial driver. If your banking peripherals need some off-brand flow control or so, I think there is some provision in the serial driver for some of them. You might need to condition the port with setserial and/or stty -F before starting Wine. True there are windose functions to read and set the lines and wait for them to change, and as far as my app and hardware cares, they work. In general, Wine does not work hardware directly, but uses the services of the host *NIX OS. Lawson The Devil finds work for idle minds.
On Sun, 04 Nov 2001 21:03:22 +0100 Gerson Kurz <gerson.kurz@t-online.de> wrote:> I have an application that talks to hardware via the serial port. > (Actually, it talks to a lot of hardware, banking peripherals). The app > runs on both Win32 and OS/2. > > Of course, the main theme is porting the thing natively to linux (and I'm > working on that). But just for fun I tried to get it to work with WINE, and > while the "device emulation" works perfectly (much to my surprise, really > good work guys!) the serial communication doesn't go far. The hardware > receives the data, but the signals (RTS/CTS etc.) are NOT correctly handled > by WINE. >Dear Kurz, I have an application that uses serial comm. with a litle Microchip PIC programmer. And I have the same problem. In the moment, the solution was instalation of Codeweavers Wine from wine.codeweavers.com, but I'm studing why the Wine from winehq.com has this problem. This event ocours because the codeweavers is an older version of wine,but is very stable. Other older version, from winehq, runs ok. Lowson wrote me an e-mail with a method to call wine and debug the serial access: | It that doesn't help, maybe wine --debugmsg +comm,+file blah.exe 2>&1|tee logfile will at least give you different error messages, which might tell me what is wrong. Or you could just give up and boot with the boot parameter "devfs=nomount". I _think_ that will disable devfs and give you back your old /dev/ttyS* devices. Maybe. Lawson ---oof--- Please, mail me if you know what is happen. Antonio
On Sun, 4 Nov 2001, Gerson Kurz wrote:> I have an application that talks to hardware via the serial port. > (Actually, it talks to a lot of hardware, banking peripherals). The app > runs on both Win32 and OS/2.Uwe, I think, mentioned winemaker. He knows whereof he speaks. winemaker is awesome. You get this by a little winelib program winemaker and I constructed from a --debugmsg +storage trace.> > Of course, the main theme is porting the thing natively to linux (and I'm > working on that). But just for fun I tried to get it to work with WINE, and > while the "device emulation" works perfectly (much to my surprise, really > good work guys!) the serial communication doesn't go far. The hardware > receives the data, but the signals (RTS/CTS etc.) are NOT correctly handled > by WINE. > > Is this an area that is being worked on?Maybe it is now. I would be interested to know if the attached patch from Mike McCormack addresses your issue with RTS/CTS. It makes my app run better, Mike and I agree it looks right, but Alexandre has the majority vote. Oh, in case you are not used to patch, you can apply this one like so: cd <wine> patch -p 0 --dry-run < dtr_control.diff patch -p 0 < dtr_control.diff or, cat dtr_control.diff | patch -p 0 -d <wine> --dry-run cat dtr_control.diff | patch -p 0 -d <wine> <wine> is of course the root of the Wine source tree. Lawson Constants aren't, and variables won't. -------------- next part -------------- Index: dlls/kernel/comm.c ==================================================================RCS file: /home/wine/wine/dlls/kernel/comm.c,v retrieving revision 1.41 diff -u -w -r1.41 comm.c --- dlls/kernel/comm.c 2001/10/21 15:01:20 1.41 +++ dlls/kernel/comm.c 2001/11/06 00:11:07 @@ -1060,14 +1060,13 @@ port.c_cflag |= CRTSCTS; TRACE("CRTSCTS\n"); } +#endif if (lpdcb->fDtrControl == DTR_CONTROL_ENABLE) { - port.c_cflag &= ~CRTSCTS; - TRACE("~CRTSCTS\n"); + WARN("DSR/DTR flow control not supported\n"); } -#endif if (lpdcb->fInX) port.c_iflag |= IXON; else @@ -1242,18 +1241,20 @@ lpdcb->fNull = 0; lpdcb->fBinary = 1; + /* termios does not support DTR/DSR flow control */ + lpdcb->fOutxDsrFlow = 0; + lpdcb->fDtrControl = DTR_CONTROL_DISABLE; + #ifdef CRTSCTS if (port.c_cflag & CRTSCTS) { - lpdcb->fDtrControl = DTR_CONTROL_ENABLE; lpdcb->fRtsControl = RTS_CONTROL_ENABLE; lpdcb->fOutxCtsFlow = 1; - lpdcb->fOutxDsrFlow = 1; } else #endif { - lpdcb->fDtrControl = DTR_CONTROL_DISABLE; lpdcb->fRtsControl = RTS_CONTROL_DISABLE; + lpdcb->fOutxCtsFlow = 0; } if (port.c_iflag & IXON) lpdcb->fInX = 1;