[NTLUG:Discuss] OpenOffice - winword formatting error issues -- sending "to" MSOff/Win is difficult
Bryan J. Smith
b.j.smith at ieee.org
Fri Jul 23 08:29:22 CDT 2004
Understand any issues with sending documents _to_ MS Office for Windows
is rather difficult. It doesn't matter if you're running
OpenOffice.org, StarOffice or even MS Office for Mac on the other end.
Why?
MS Office uses block record reads and writes. No one in the
cross-platform development world would _ever_ do such a thing, as
byte-by-byte (character) reading is the key to cross-platform
compatibility. But Microsoft's own application division in their grave
and massive x86 ignorance still uses records reads/writes to write
files.
This is why an upgrade, sometimes something as small as a patch, can
render MS Office unable to read many of its own documents saved with an
earlier version on x86. That's because slight changes in the
Intel/Microsoft compilers can totally shift the organization of the
records, even if the code remains unchanged. This happens all the time,
at least through MS Office XP. So when the code tries to do a record
read, and assumes an exact bit organization, it fails at different parts
of the file.
Going the other way is not an issue, because even if MS Office for
Windows writes out new, changed format, the byte-by-byte import in
OpenOffice.org, StarOffice and even MS Office for Mac will read it. If
you _ever_ meet an MS Office for Mac developer, talk to him awhile and
get his feelings on how _ignorant_ Microsoft's own Windows application
developers are of data alignment.
As someone who has supported dual-Windows/Mac environments, it really
used to piss me off when the Windows users blamed the Mac for the
problems. Sigh. You have to worry about data-alignment on the PowerPC
(or any non-x86 architecture), which is why it _forces_ applications to
be written correctly. With x86-only Windows, far too many Windows
developers have _never_ heard of data-alignment, endianness and byte
(network) order. Heck, Microsoft's own C compilers didn't even offer
the macros/functions to support them for the longest time!
Microsoft has now switched to a "binary XML" format option in MS Office
2003, which does a byte-by-byte read. Much better, but I don't think
it's the standard format (not sure). Their history of using record
writes/reads instead of character writes/reads is why virtually _no_
applications have been ported to IA-64 Itanium, and why you won't find
true Win64 applications for even AMD x86-64 for the longest time.
32-bit, data-alignment ignorant x86 code is what Microsoft has been
producing for a long time. Portability issues between even MS Office
itself on Windows and Mac is a perfect example of this issue
first-hand. Again, if you ever get to meet an MS Office for Mac
developer, ask him about all the code they have to add beyond the
Windows version. Not because of the OS or architecture, but because of
the _horrendous_ programming practices (or, rather, lackthereof) by
Microsoft's own application developers.
--
Linux Enthusiasts call me anti-Linux.
Windows Enthusisats call me anti-Microsoft.
They both must be correct because I have over a
decade of experience with both in mission critical
environments, resulting in a bigotry dedicated to
mitigating risk and focusing on technologies ...
not products or vendors
--------------------------------------------------
Bryan J. Smith, E.I. b.j.smith at ieee.org
More information about the Discuss
mailing list