Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!amadeus.UUCP!mdb
From: mdb@amadeus.UUCP (Mark D. Baushke)
Newsgroups: comp.windows.x
Subject: XCreateBitmapFromData() bug/feature question
Message-ID: <8802042049.AA06105@amadeus.silvlis.com>
Date: 4 Feb 88 20:49:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Silvar-Lisco, 1080 Marsh Road, Menlo Park, CA 94025-1053
Lines: 78

I have a question about XCreateBitmapFromData().

I have a sequential stream of bytes which I want to make into an icon.
(c.f., GNU Emacs src/sink.h or X.V10R4/xshell/scallopshell.h).

On my Sun, I need to 'swap' the bytes on each 'short' word in order to
make the image look correct. However, I am told that the image is ok
"as is" on uVAX so changing the data to make it look good on a sun
will break it for a VAX... Requiring the application to alter the bit
data depending on the hardware in use is not something I am very fond
of doing.

The behavior occurs because XCreateBitmapFromData() asumes that the
byte_order=FSBFirst.  This assumption works on a uVAX since the words
are stored in LSBFirst. This assumption does not work on a Sun or IBM
RT (and many others as well see list below for BIG_ENDIAN machines)
since the words are stored in MSBFirst order.

My question is this, can we alter the behavior of XCreateBitmapFromData()
by either:

	A) modify XCreateBitmapFromData() to make byte_order
	   assumptions based on whether the hardware is MSBFirst or
	   not by adding '#ifdef BIG_ENDIAN' code (a la GNU Emacs) to
	   lib/X/XCrBFData.c .

or	   

	B) modify the calling sequence of XCreateBitmapFromData() to
	   accept a byte_order argument.

My personal favorite is "A" as this would do the "right thing" most
often without the application writer having to know about which
hardware his code is running on.

From GNU Emacs the following machines are BIG_ENDIAN (lowest-numbered
byte in a word is the most significant byte):

	sun 1	   
	sun 2
	sun 3
	apollo
	amdahl uts
	AT&T UNIX PC model 7300
	Silicon Graphics Iris 2500 Turbos
	ISI 68000's
	targon31
	IBM RTPC
	AT&T 3b
	Celerity
	alliant
	Mips
	Stride Micro System-V.2.2
	Altos 3068 Unix System V Release 2
	Masscomp 5000 series running RTU, ucb universe
	tahoe
	WICAT machines
	Gould with UTX/32 2.0
	TI Nu machines using system V
	NCR Tower 32 running System V.2
	pyramid
	Plexus running System V.2
	Megatest 68000's
	hp9000 series 200 or 300
	gec63
	Dual machines using unisoft port

The following machines are not BIG_ENDIAN (lowest numbered byte is
least significant):

	Vax
	SEQUENT BALANCE machines
	ns16000
	Elxsi machine (running enix)
	HLH Orion

Mark Baushke
silvlis!mdb@sun.com