On Wed, 05 Dec 2001 10:34:05 +0000, "T REX" <the1trex@hotmail.com> wrote: >hmm, I ran a +relay,+seh. results can be found at: >http://www.termografinett.no/wine.log2.bz2 > >if you want to try the program, I upploaded it here: >http://www.termografinett.no/thinkboxx.tar.gz >its 1MB. That will not be necessary, the mystery is solved. 0806d8a0:Call kernel32.ReadFile(00000078,4124fdb0,00000400,40616958,4124a5f0) ret=0043ecff 0806d8a0:Ret kernel32.ReadFile() retval=00000000 ret=0043ecff 0806d8a0:Call kernel32.GetOverlappedResult(00000078,4124a5f0,40616958,00000001) ret=0043ed17 trace:seh:EXC_RtlRaiseException code=c000013a flags=00y Exception c000013a means that you typed Ctrl C to exit Wine. The Wine debugger could hardly start in this situation. As of why the application hangs, well, it's waiting to 1024 bytes of data to get to it through the serial link. The Wine problem is that the data does not come up on the serial link. The application problem is that it hangs when no data comes in as expected. A well written application should not hang because data is not available on the serial link, of course. To come back to the Wine problem, I see nothing that the app did that could trigger the device to output its 1024 bytes of data, so I think that the device is monitoring the serial data link state and outputting data as soon as some state is reached. I'm afraid that the reason that the device don't do it could be (from your previous trace) : 0806d898:Call kernel32.CreateFileA(42fbbdd8 "COM1",c0000000,00000000,00000000,00000003,40000000,00000000) ret=0043ddf8 trace:file:CreateFileA COM1 GENERIC_READ GENERIC_WRITE OPEN_EXISTING trace:file:CreateFileA opening device 'COM1' trace:file:DOSFS_CreateCommPort COM1 c0000000 40000000 0806d898:Ret kernel32.CreateFileA() retval=00000060 ret=0043ddf8 0806d898:Call kernel32.SetCommTimeouts(00000060,406150f0) ret=0043de48 trace:comm:SetCommTimeouts (60,0x406150f0) 0806d898:Ret kernel32.SetCommTimeouts() retval=00000001 ret=0043de48 0806d898:Call kernel32.BuildCommDCBA(42fbb0f4 "COM1 96,n,8,1",406150ac) ret=0043dfc3 trace:comm:BuildCommDCBAndTimeoutsA (COM1 96,n,8,1,0x406150ac,(nil)) trace:comm:COMM_BuildOldCommDCB (COM1 96,n,8,1), ptr 0x406150ac trace:comm:COMM_BuildOldCommDCB baudrate (9600) trace:comm:COMM_BuildOldCommDCB parity (N) trace:comm:COMM_BuildOldCommDCB charsize (8) trace:comm:COMM_BuildOldCommDCB stopbits (1) 0806d898:Ret kernel32.BuildCommDCBA() retval=00000001 ret=0043dfc3ü 0806d898:Call kernel32.SetCommState(00000060,406150ac) ret=0043e017 trace:comm:SetCommState handle 96, ptr 0x406150ac trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS warn:comm:SetCommState DSR/DTR flow control not supported 0806d898:Ret kernel32.SetCommState() retval=00000001 ret=0043e017 'flow control not supported'. This could be the reason. I have no idea why it's not supported - I suspect a system-related reason, if there is no api available to managed this stuff in the Linux Api, for example. Gerard
