Resource temporarily unavailable

[T REX]

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 at wanadoo.fr.invalid (gerard patel)
>Reply-To: wine-users at winehq.com
>To: wine-users at 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 at 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 at winehq.com
>http://www.winehq.com/mailman/listinfo/wine-users


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp