#1016 Growing hard disk images severe interoperability errors!
We are Ioannis Barkas and Nick Barkas.
Growing hard disk images of the same size in MB have
problems that prevent bochs from being a truly cross-
platform (OS portable) emulator.Such errors are
completely unacceptable.
On one hand, bochs 2.2.6 on GNU/LINUX such as FC5
cannot identify growing hard disk images made from
bochs 2.2.6 in windows 2003 SP1 at all.As usual the
log prints irrelevant things,this time about problems
at the redolog and does not point out the error.For
this reason we needed some time to realise what was
wrong as we could not imagine that an incompatibility
issue was possible in such a cross-platform
program...The error is identified when trying to write
to the hard disk image.So when we started fdisk from
win98 startup disk we got:
"Error reading fixed disk.",after which fdisk exits
and returns to command prompt.The fdisk runs perfectly
when we use an image made on GNU/LINUX.
On the other hand, bochs 2.2.6 on windows 2003 SP1
cannot identify growing hard disk images made from
bochs 2.2.6 in GNU/LINUX such as FC5.The log again
prints irrelevant things about problems at the redolog
and does not point out the error.Again the error is
identified when trying to write to the hard disk
image.So when we started fdisk from win98 startup disk
and chose new partition,we got:
"No space to create a DOS partiton.",on a 32GB
patition!After that it prompted us to press ESC in
order to continue.The fdisk runs perfectly when we use
an image made on windows.
NOTE THAT THE EMPTY FC5 GROWING HARD DISK IMAGE HAS A
DIFFERENT MD5 CKECKSUM COMPARED TO THE WINDOWS EMPTY
GROWING HARD DISK IMAGE.THIS DOES NOT OCCUR ON sparse
OR flat IMAGES,WHICH HAVE THE SAME CKECKSUM ON BOTH
PLATFORMS...That difference forced us to reverse
engineer the images...The differences between the disk
images are seen at the following parts below which are
at the first two lines of the images:
€ èß ,in windows
€ èß ,in GNU/LINUX,
as you can see the windows image has 4 spaces(hex
number 20) more than the GNU/LINUX image!!!If the
above characters from the disk images are not
displayed from your browser just reverse engineer the
images yourself!
This serious error is a double error!It is double
because bximage makes different images on one hand and
because the disk image interpreter is unaware of this
situation!FIRST OF ALL BXIMAGE MUST BE FIXED.ONCE THIS
IS DONE YOU HAVE TO MAKE THE DISK IMAGE INTERPRETER
ACCEPT BOTH IMAGES FOR COMPATIBILITY WITH ALREADY
CREATED VIRTUAL MACHINES OR GIVE THE INTERPRETER THE
ABILITY TO CALL BXIMAGE IN ORDER TO MODIFY THE IMAGES
TO THE CORRECT GROWING DISK IMAGE FORMAT, WHICHEVER
WAS MEANT TO BE THE CORRECT OR WHICHEVER YOU DECIDE
NOW IS THE CORRECT ONE(2 spaces OR 6 spaces).Such a
decision,is very unpleasant as newer bochs images will
be incompatible with older bochs releases of windows
or GNU/LINUX depending on your decision.We would
choose as correct the 2 spaces one.Also you must
inform everyone in the next version release notes that
one of the two disk images will not be used from that
release on and that the corrected image will not work
with older bochs versions!.If it was up to us,we would
release a new bochs version as soon as a fix for this
error and a bximage which would modify the original
wrong images were ready!
NOTICE HERE THAT BOTH IMAGES HAVE EXACTLY THE SAME
SIZE.THAT MEANS THAT THE WINDOWS IMAGE HAS 4 LESS
SPACE CHARACTERS BETWEEN THE:`èß UNTIL THE FIRST ÿ
CHARACTER,COMPARED TO THE GNU/LINUX IMAGE WHILE BOTH
IMAGES HAVE THE SAME NUMBER OF ÿ CHARACTERS!
We have not tested it on any UNIX variant but we are
afraid that things will just get worse there.Also we
are afraid that in BIG endian machines there may be an
even bigger mess,which we can't test as we do not have
such a cpu.
Logged In: NO
The original message does not show the line difference we
want you to see.
It appears that web browsers do NOT show the difference of 4
spaces between the two lines.So we rewrite them in order not
to confuse you.
€
èß ,in windows €èß ,in GNU/LINUXIf you see the above lines the same before the "," ,then we
inform you that there is a sf server or web browser issue!
Logged In: YES
user_id=1226167
Ok it was an ie6 sp1 issue,even though it has all the
updates...It seems one service pack is not enough for
them!Luckily firefox 1.5 did the job right as it should on
the comment!!!
Logged In: YES
user_id=376477
I can confirm that this bug exists. The reason is the
different data alignment of 64-bit values on Windows and
Linux. The bug seems to appear in the first hdimage mode
implementation in Bochs 2.1 and nobody tested this special
case.
I'll try to fix this ASAP. Backward compatiblity should be
no problem, since the data structure contains a version
field. I cannot test the big endian case, but I guess it's
okay, since the code contains macros for endianness
conversion.
Logged In: NO
Why did you delete bug #1488348 ? We sent a report to the
web site tracker to delete this one #1488335 as it did not
logged me in on this bug report.
Logged In: YES
user_id=376477
This bug is fixed in CVS now. New images created with
bximage are now really portable. Existing images are still
support, but there was no way to fix this bug without
changing the data structure. In the logfile new images
will be reported with header version 2.0.