On Sun, 25 Apr 2004 02:40:49 -0400, you wrote: > trace:comm:PurgeComm handle 0x48, flags 5 > trace:comm:PurgeComm handle 0x48, flags a > (then a bunch of these ...) > trace:comm:ClearCommError handle 0x48 cbInQue = 0 cbOutQue = 0 > trace:comm:ClearCommError handle 0x48 cbInQue = 0 cbOutQue = 0 cbInQue and cbOutQue are the number of characters in the in- and output queues. Are you sure that there was no line with a number <> 0 ? > (then) > trace:file:ReadFile 0x48 0x419f6aa0 1 0x4074f3f4 (nil) > trace:file:ReadFile 0x48 0x419f6aa1 1 0x4074f3f4 (nil) > trace:file:ReadFile 0x48 0x419f6aa2 1 0x4074f3f4 (nil) > trace:file:ReadFile 0x48 0x419f6aa3 1 0x4074f3f4 (nil) > trace:file:ReadFile 0x48 0x419f6aa4 1 0x4074f3f4 (nil) > trace:file:ReadFile 0x48 0x419f6aa5 1 0x4074f3f4 (nil) Programs requests a number of characters, one at the time. Unfortunately you cannot see if the program gets the byte. The +relay debug channel will provide the return value of ReadFile, and perhaps the "LastError" value. This debug log is /much/ longer the +file, so be warned. > trace:comm:PurgeComm handle 0x48, flags a > (then it does it again, and then) > trace:comm:EscapeCommFunction handle 0x48, function=6 > trace:comm:EscapeCommFunction CLRDTR > trace:comm:EscapeCommFunction handle 0x48, function=4 > trace:comm:EscapeCommFunction CLRRTS > (and afterwards it tries to detect the device on another port...) Anyway, you see there has been plenty of activity on COM1. > > I've tried out the device in windows, and used portmon to monitor the > serial port. The device usually sends out a specific string every time > it's ready to connect. That is totally absent from your trace: no WriteFile's. > The program then polls the serial port until the > signal is caught, and then does some more handshaking with the device. > It would seem from this that the software is not reading the correct id > string. Anything to do with "fixme:comm:SetupComm insize 3102 outsize > 3102 unimplemented stub"? That message is harmless. > Is there anyway to monitor what's being sent > and read from the serial port under linux (like portmon for windows)? If you compile wine from source and know a bit of C you may want to put some additional TRACE statements in the source of ReadFile, WriteFile. > Could it be a dll problem (though the program should be fairly simple, > and it should run under windows 98). I didn't see any errors on the > "file" debug channel, though there were some warnings with 32-bit dlls > not found. +file generates plenty of warnings, usually as a result of finding the location/existence of files. > I'd really appreciate any help with this... > Thank you, Jad A number of programs that use serial communication are not working at the moment, while some others do. There is a chance you will have to wait until this problem is fixed. Rein. -- Rein Klazes rklazes@xxxxxxxxx _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
