| Return-Path: [email protected]
Received: by asimov.mro.dec.com (UCX V4.1-12, OpenVMS V6.2 VAX);
Fri, 21 Feb 1997 12:09:20 -0500
Received: from ics.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV)
id MAA13690; Fri, 21 Feb 1997 12:01:45 -0500 (EST)
Received: from teapot ([140.186.40.160]) by ics.com with SMTP id AA18714
(5.65c/IDA-1.4.4); Fri, 21 Feb 1997 11:45:14 -0500
Sender: [email protected]
Message-Id: <[email protected]>
Date: Fri, 21 Feb 1997 11:48:54 -0500
From: Andy Ross <[email protected]>
Organization: Integrated Computer Solutions
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: "[email protected]" <[email protected]>
Subject: ATTN: Gerrit, XmResolveAllPartOffsets() problem
Content-Type: multipart/mixed; boundary="------------45ABF73A6F4CE654F2B10E4"
This is a multi-part message in MIME format.
--------------45ABF73A6F4CE654F2B10E4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Gerrit,
Hi, this must have gotten lost. Attached is the mail I sent after we
spoke. I explained the problem as best I could, though I did not
include sample code. The symptom can be seen by creating a new widget
class derived from a Motif class (Primitive, for instance), then setting
up an offset table for it by calling XmResolveAllPartOffsets(). If you
then look at the offsets that are placed in the table in a debugger,
they do not synch with where the compiler has placed the structures in
memory. This is because Motif was not compiled to use ALIGN_SUBPARTS,
as I describe.
I hope this is helpful, the man page for XmResolveAllPartOffsets()
covers the essence of the problem, if you need background. If sample
code really is needed (I'd have to send a complete, dummy widget class)
I'll see what I can scrape together.
Thanks,
Andy
--
Andrew J. Ross Integrated Computer Solutions, Inc.
[email protected] 201 Broadway
(617)621-0060x136 Cambridge, MA 02139
--------------45ABF73A6F4CE654F2B10E4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <[email protected]>
Date: Fri, 14 Feb 1997 14:45:01 -0500
From: Andy Ross <[email protected]>
Organization: Integrated Computer Solutions
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.27 i586)
MIME-Version: 1.0
To: [email protected]
Subject: ATTN: Gerrit, XmResolveAllPartOffsets() problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The API in question is XmResolveAllPartOffsets(). This builds a table
at runtime of byte offsets into the widget instance structure of each
subpart. That is, for a hypothetical widget whose record struct looks
like:
typedef struct _MyWidget {
CorePart core;
XmPrimitivePart primitive;
MyPart me;
} MyWidgetRec;
XmResolveAllPartOffsets would build a table of where in the structure
primitive and me begin. Then all access into the structure will be done
using this table, and the widget will remain binary compatible with
future versions of the motif library (e.g. CDE) which might change the
size of the XmPrimitivePart structure.
Unfortunately, on 64 bit processors, this becomes more complex. Because
the structure subparts are aligned on 64 bit boundaries, the offset (for
instance) of the XmPrimitivePart is _not_ simply sizeof(CorePart) bytes
into the structure, but the next 8-byte boundary _higher_ than that.
The Motif 1.2.4 source contains a provision for making the alignment
issues work, but this requires that Primitive.c be compiled with
ALIGN_SUBCLASS_PARTS #defined. It appears that the libXm libraries
provided with DEC Unix 3.2 and 4.0 (Motif 1.2.4 and CDE Motif,
respectively) were not compiled with this macro defined, and are
therefore generating incorrect offsets in the offset tables and resource
structures.
Thanks for your attention,
Andy
--
Andrew J. Ross Integrated Computer Solutions, Inc.
[email protected] 201 Broadway
(617)621-0060x136 Cambridge, MA 02139
--------------45ABF73A6F4CE654F2B10E4--
|