Hi all, This is my first time on this list.
I've been playing around with Wine with quite a bit of success, but I've ran into a problem when trying to get an old program that uses IR to work correctly. I've already post on comp.emulators.ms-windows.wine and they referred my problem here. Here is the info that I have...
For the record, I am running Wine 20021031.
The program is based on the commercial Greenleaf Comm++ libraries. It is designed to be utilized in Windows on top of a *virtual* Com port running IrDA. The software itself knows nothing of IrDA, it's the *virtual* Com port's responsibility to provide that. Apparently it uses IrCOMM and TinyTP, but I'm just learning exactly what that means.
I setup Linux to run IrDA through /dev/ttyS0 (the physical IR serial device) on /dev/ircomm0 (the IrDA device). I set
"Com4" = "/dev/ircomm0".
in the wine config file.
I run the software with "--debugmsg +comm,+file" and look at the output. The software gets to a point where it performs some basic Serial port setup (SetupComm(), GetCommState(), SetCommState(), etc) and then I get the following...
<snip> trace:file:Writefile 192 0x420b1190 14 0x4230a200 0x430a1530 trace:file:Writefile Overlapped not specified or invalid event flag <-- this is the interesting line trace:ClearCommError handle 0xc0 cbInQue = 0 cbOutQue = 0 ... last line repeated until timeout </snip>
( big apologies for not having a larger dump )
The pointer to the OVERLAPPED structure in this function is not set to NULL, but the hEvent member of that struct is set to ZERO (0), which seems to be the problem. I don't know why that member variable is set to ZERO (0), but that obviously keeps me from actually writing anything to the IR port.
So my question involves how to approach this problem. I actually modified the Wine code to "overlook" the bad hEvent variable in WriteFile(), ReadFile(), and GetOverlappedResult() just for kicks to see what would happen. When I do that, it actually sends stuff over the IR connection and processes more ( additional ReadFile[Ex](), WriteFile[Ex](), GetOverlappedResult() calls ), but obviously the handshaking doesn't complete correctly since I'm ignoring the error checking. Could my problem be in the way IrDA is setup ( i.e. what is the correct way to emulate a Windows *virtual* COM port running IrDA in Wine )?? Any advice or information on this problem would be really appreciated. Thanks.
-- Ryan
On Thu, 21 Nov 2002, Ryan Reading wrote:
The program is based on the commercial Greenleaf Comm++ libraries. It is designed to be utilized in Windows on top of a *virtual* Com port running IrDA. The software itself knows nothing of IrDA, it's the *virtual* Com port's responsibility to provide that. Apparently it uses IrCOMM and TinyTP, but I'm just learning exactly what that means.
They probably just meant that the IrCOMM wire(less) protocol is based on TinyTP. The app would have to use winsock to use any other IrDA protocol than IrCOMM, and wine has no support for that yet (although I've occasionally been thinking about what it would take to implement it).
I setup Linux to run IrDA through /dev/ttyS0 (the physical IR serial device) on /dev/ircomm0 (the IrDA device). I set
"Com4" = "/dev/ircomm0".
in the wine config file.
Sounds like a setup that should work if you set up IrDA and IrCOMM correctly (loaded all the right modules, such as ircomm and ircomm-tty, started irmanager, and enabled IrDA discovery, etc)
So my question involves how to approach this problem. I actually modified the Wine code to "overlook" the bad hEvent variable in WriteFile(), ReadFile(), and GetOverlappedResult() just for kicks to see what would happen. When I do that, it actually sends stuff over the IR connection and processes more ( additional ReadFile[Ex](), WriteFile[Ex](), GetOverlappedResult() calls ), but obviously the handshaking doesn't complete correctly since I'm ignoring the error checking.
The IR handshaking is the IrDA discovery protocol's and IrCOMM's (TinyTP's) responsibility, not the app's, the app only sees a virtual com port. I don't think handshaking is an issue.
But if the device is opened in overlapped mode (is it?), then I think wine currently does need the hEvent to synchronize properly, though I think Martin Wilck would be the expert on that. Perhaps he could give more insight?
-
Ove Kaaven -
Ryan Reading