When we started looking into the details of the problem, we printed out the
messages in hex, and tried to find all of the class contents that we knew
about for a couple of the shorter messages. We decoded everything except
for the first two bytes on the Win32/Linux systems. On the QNX system, we
noticed the same effect, but the unknown bytes were towards the end of the
message, actually it appeared to be between the base message, and the
inherited message data elements.
We also changed the structure of the message by adding, removing, and
re-arranging the elements. All of which affected the values in the
positions of the message that I described previously. Another note of
interest, is that these messages, which are new’ed an destroyed many times
per second, always contain the same values within those positions, from
message type to message type during a given trial run. This was true for
all of the OSes we tested this on.
Bill Caroselli <QTPS@Earthlink.net> wrote in message
Myguess is that it has nothing to do with clases per se.
Take your class and dump the bytes in hex to the screen. Are they what
expect? I’ll bet not. First thing to look at is the packing of your
Otherwise, post a simple class and the bytes that were dumped.
If the hex dump IS what you expect, receive it at the other end and dump
the same bytes and post them here.
“Kevin White” <> email@example.com> > wrote in message
news:bgdsok$r38$> firstname.lastname@example.org> …
I am trying to get some information regarding how classes get defined
handled in QNX, in comparison to other OSes. We currently have a
this area, and it is only appearing in one of several OSes that we are
developing in – QNX.
At any rate, we are utilizing socket communications, and we are sending
information by transmitting a class across the wire. This works rather
in Windows, VxWorks, and Linux, but on QNX it seems to work much
differently. When we print out all of the data from the class that we
sending, on the other operating systems, there is 4 bytes of information
the front of the socket message that seems to be related to the class
information – if we remove or re-arrange variables or methods within
class, these numbers change. For the QNX system, these numbers seem to
close to the end of the socket message, or between class and subclass
boundaries, perhaps. Whatever the case, we can communicate using
within the context of the PC, but when we actually try to talk to
box (PC, Linux or whatever), the comms fails because the data is not
the same as the other three OSes, and the class information that is
sent from another operating system is mis-interpreted as data.
Has anyone seen anything like this before, or know how to correct for