[VW7.4][BOSS] Platform-Transparency Problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[VW7.4][BOSS] Platform-Transparency Problem

Andre Schnoor
Hi all,

My VW application creates BOSS files which are used on Windows and MacOS
X platforms alike. The files are rather large, divided into a separate
header and content part.

Because the files are maintained on Windows for both platforms, they are
originally written in little-endian byte order. Anyway, MacOS X
(big-endian) needs to eventually  update the headers only, without
loading and decoding the content part (simply because the processing
image can't handle the objects therein). This is done by loading the
content part as a series of "dumb" bytes and write them back unterpreted.

On MacOS X however, this won't work, because the new header is written
in big-endian format, while the content part is kept unchanged in
little-endian format. This causes a crash when loading the file.

Question:

a) Is it possible to switch the byte order while reading a file, i.e.
use mixed byte orders within the same file? I guess that changing the
instance variable of the BOSSReader alone won't do it, so where is a
good point to check this out?

b) Or: When creating files, can the byte-oder be forced to either format
- regardless of the current platform?

Thanks in advance.
Andre


Reply | Threaded
Open this post in threaded view
|

Re: [VW7.4][BOSS] Platform-Transparency Problem

James Robertson-3
Umm, BOSS files should be platform neutral, unless you've customized
something.  I move BOSS files between Windows, Mac, and Linux on a regular
basis w/o issues

At 01:07 PM 3/12/2006, you wrote:

>Hi all,
>
>My VW application creates BOSS files which are used on Windows and MacOS X
>platforms alike. The files are rather large, divided into a separate
>header and content part.
>
>Because the files are maintained on Windows for both platforms, they are
>originally written in little-endian byte order. Anyway, MacOS X
>(big-endian) needs to eventually  update the headers only, without loading
>and decoding the content part (simply because the processing image can't
>handle the objects therein). This is done by loading the content part as a
>series of "dumb" bytes and write them back unterpreted.
>
>On MacOS X however, this won't work, because the new header is written in
>big-endian format, while the content part is kept unchanged in
>little-endian format. This causes a crash when loading the file.
>
>Question:
>
>a) Is it possible to switch the byte order while reading a file, i.e. use
>mixed byte orders within the same file? I guess that changing the instance
>variable of the BOSSReader alone won't do it, so where is a good point to
>check this out?
>
>b) Or: When creating files, can the byte-oder be forced to either format -
>regardless of the current platform?
>
>Thanks in advance.
>Andre
>

Reply | Threaded
Open this post in threaded view
|

Re: [VW7.4][BOSS] Platform-Transparency Problem

Andre Schnoor
James Robertson wrote:
> Umm, BOSS files should be platform neutral, unless you've customized
> something.  I move BOSS files between Windows, Mac, and Linux on a
> regular basis w/o issues
>
There is nothing wrong with BOSS. I subclassed BOSSReader and BOSSWriter
and a few other classes to achieve a more flexible behavior for handling
large documents. This includes digital signatures, encryption and
compression.

I'm looking for a possibility to control the byte order programmatically
(i.e. write in little-endian format on MacOS X), so I can update
portions of a file ("header") without the need to actually parse and
load all the objects in the rest of the file,  which were created on a
different platform.

This is not for performance reasons. I've got utilities which simply
can't load the documents as a whole, because the required superclasses
and subsystems don't (yet) exist.

Maybe somebody already knows a good place to start from. If not, I've
got to poke around in the BOSS package with a trial and error approach.

Andre