Win client tantrums

rienred "at" my-Deja.com
Wed, 26 Jan 2000 22:12:27 +0000


Howdy all.

First of all, I've RT'd the FAQ and the FM, but I've found nothing,
so if the answers /are/ there, please point me in the right
direction...

I'm trying to write a VNC server for my platform, but I'm having
some difficulties talking to a Win client. I believe I'm conforming
100% to the RFB protocol v3.3, but the client keeps dying. This
is what happens :

I connect to my server.

The client window opens to a grey background and the message 'Please
wait - fetching initial screen'.

My server sends the screen (16bit raw).

Nothing appears on the client, and selecting 'Request screen refresh'
forces the client to die with a GPF.


Now, I've examined the logs from my server, a Win server, the client
(connecting to my server) and the client (connected to a Win
server), and I can't see that I'm doing anything different.

Here's some of the client log (connected to my server) :


Started and Winsock (v 2) initialised
bufsize expanded to 4352
Registered connection with app
Connected to ---.---.---.--- port ----
  reading 12 bytes
RFB server supports protocol version 3.3
  writing 12 bytes
Connected to RFB server, using protocol version 3.3
  reading 4 bytes
No authentication needed
Clipboard changed
Don't send initial clipboard!
  writing 1 bytes
  reading 24 bytes
  reading 4 bytes
Read a 4-byte string
Desktop name "test"
Geometry 128 x 128 depth 16
Screen work area is 1024 x 740
  writing 20 bytes
  writing 28 bytes
Update-processing thread started
Request full update
  writing 10 bytes
  reading 4 bytes
  reading 12 bytes
bufsize expanded to 33024
  reading 32768 bytes
Losing focus - cancelling modifiers
  writing 8 bytes
SendKeyEvent: key = xffe9 status = up
  writing 8 bytes
SendKeyEvent: key = xffe3 status = up
  writing 8 bytes
SendKeyEvent: key = xffe1 status = up
  writing 8 bytes
SendKeyEvent: key = xffea status = up
  writing 8 bytes
SendKeyEvent: key = xffe4 status = up
  writing 8 bytes
SendKeyEvent: key = xffe2 status = up


The point at which the log ends is where I 'Request screen refresh'.

Here's the GPF message :

VNCVIEWER caused a divide error in module VNCVIEWER.EXE at
0167:00408eb5.
Registers:
EAX=00000000 CS=0167 EIP=00408eb5 EFLGS=00010246
EBX=00cafed4 SS=016f ESP=00cafe3c EBP=00000000
ECX=00000006 DS=016f ESI=00000000 FS=4777
EDX=00000000 ES=016f EDI=00884240 GS=0000
Bytes at CS:EIP:
f7 7c 24 78 8b d6 d3 ea 8b 4c 24 18 d3 ee 8b 4c
Stack dump:
008843fc 00884240 00caff58 00000000
0000000b 00000006 00000000 0000001f
00000000 00cc000c 0000000b bff70000
8165bf06 00000000 0040dc00 0088001f


Again, as far as I can tell, I'm following the 3.3 protocol
perfectly - but when the client says 'requesting intial screen', it
looks like it's waiting for more data - but I've already sent it all!
For a 128x128 screen, I send 32768 bytes, which is what I should
send, and is what the client reads. Does the 3.3.3r2 Win client
conform to v3.3 completely?


I'm at a loss... any suggestions of where to look would be
greatly appreciated!

RR



--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.

---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------