Hmm well it is a posibilty, the weird thing here is that the Thinkboxx does not use hardware flow controll, this i know since the serial cabel suplied only has three pins where two are data and one is ground. I think that the lacking support may be conusing the error, but why does it work under windows when hardware flow controll is not available. The program must be relaying on software flow controll, does windows use software flow controll that emulates DTS/DTR signals. The fact that it is the lacking 1024 bytes that couses the problem strongly supports the teory that the problem resides in the serial communication. Maybe that when the thinkboxx sends an request, this request for some reason does not rach the comm port or that the answer dont, maybe i hawe a wronlgly configured flow controll. On windows the program does not hang ewen when nothing is connected to the comm port so it cant be getting the 1024 bytes there either but it dosnt hang, maybe windows suplyes the program with the 1024 bytes. Wow this was a lot of sh..., i just poured out my thoughts here. So, does anyone know anything, this program is important to me, so i would be greatful for any help. The1trex -- Philosophers have tried to interpret the world in different ways; the important thing is to change it. - Karl Marx >From: g.patel@wanadoo.fr.invalid (gerard patel) >Reply-To: wine-users@winehq.com >To: wine-users@winehq.com >Subject: Re: Resource temporarily unavailable >Date: Wed, 05 Dec 2001 12:35:30 GMT > >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 >_______________________________________________ >wine-users mailing list >wine-users@winehq.com >http://www.winehq.com/mailman/listinfo/wine-users _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
