[gdi] bug reading/writing metafiles on sparc

[Eric Frias]

Due to little-endian/big-endian differences, winelib on Sparc can't read 
windows metafiles generated on a PC (or on Wine on x86), and conversely 
PCs can't read metafiles created on a Sparc.  It looks like there are a 
few ways this could be fixed, and I wanted to make sure we don't go 
about it the wrong way (and that nobody else is working on it).

I think the right thing to do is make the on-disk and in-memory formats 
always be little-endian.  We would only convert the data to big-endian 
format when it is generated or used.  GetMetaFileBitsEx and 
SetMetaFileBitsEx would return & take the raw data in little-endian format.

The implementation we're considering involves:
    - in PlayMetaFileRecord(), convert endianness of paramters as 
they're used:
        LineTo(hdc, (SHORT)mr->rdParm[1], (SHORT)mr->rdParm[0]);
    becomes
       LineTo(hdc, (SHORT)convert_word_from_little_endian(mr->rdParm[1]),
            (SHORT)convert_word_from_little_endian(mr->rdParm[0]));
    - in MFDRV_MetaParam2(), convert endianness
       *(mr->rdParm) = param2;
    becomes
       *(mr->rdParm) = convert_word_to_little_endian(param2);
    - some similar conversions necessary for anything that reads/writes 
the header
    - anything that calls MFDRV_WriteRecord() would need special 
handling.  These seem to be the functions that embed bitmaps or text in 
the METARECORD, so we'll have to be selective about what gets converted 
and what gets written as-is.

Is this the right way to go about fixing the problem?  Anything we 
should look out for?

Thanks,
Eric