[KLUG Members] Re: Calling all Linux novices: -- MS Office on non-Windows platforms ...

[Bryan J. Smith]

--=-Tlt/elehqkt/SRKjA0G8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-01-15 at 22:38, Justin Buist wrote:
> IE on the Mac is not IE at all really.  It doesn't behave -anywhere- clos=
e to
> what IE on the Win32 platform does.

Correct.  It's actually a fairly standards-compliant browser on the Mac
platform.

You see, at the "core," MS IE 5.x is a _very_ standards compliant
browswer.  The "problem" is that it not only has support for
non-standard tags and Win32 interfaces, it _prefers_them_ by default.=20
And there's really no way to disable that behavior either -- nor in
various Microsoft web development products.  And that's where the
problem is, but only on Windows.

I don't know how many times I've heard people say "why is that page
different on your screen?" when they see a page rendered in
Galeon/Mozilla that they are already familiar with in IE.  I've also got
a friend who works at Harcourt and they have had to unofficially adopt a
Mozilla-based variant on Mac, because some of their own company's
IE-only pages don't render correctly on IE for Mac.  Very humorous
indeed.  ;-p

> To the best of my knowledge there is -still- no way to get
> VbScript running client-side on a Mac.
> No, the VBScript decision wasn't made by me ... and I wasn't around
> when it happened either.

Obviously not.  You sound like your Mac knowledge is probably far, far
beyond mine.  In fact, I'm not a Mac guru, but have had to support
interoperability with Windows PCs over the years, hence my familiarity
with the issues.

> At any rate, after looking into the details of Mac IE I found out that it
> really doesn't share any common code with the Win32 IE at all, or at leas=
t
> not any significant portion.  It's basically a re-write of the rendering
> engine from what I gather.

I understand differently.  It's just that the Mac version is not only
missing the Win32-only components, which are the default preference on
Windows.  Again, MS IE 5.x at the core is very standards compliant.  It
just refuses to use them unless it absolutely has to.

> As the above poster noted, it's far more likely that Mozilla on the Mac
> will act more like IE on a Win32 platform than Mac IE will.

Yes, again, per a colleague of mine who runs into it everyday in a
production Mac environment.

> I saw that happen plenty of times, which resulted in a total port of
> the application in question.  How did I (and the other member tasked with=
 this)
> go about it?  Code it to JavaScript/DOM2 standards, test on every browser=
,
> and then pray that Mac IE handled it right.  So long as IE, Mozilla (PC &=
 Mac)
> worked it was very likely that Mac IE would too - and we were right.

Mozilla is a great standards-tester.  Even old Netscape 4 stuff fails.=20
Netscape took some heat from developers when they decided to drop
support for those proprietary mechanisms in Mozilla.  I applauded it.

> In the end the client ended up with a very standards compliant site that =
worked on
> more than they originally had asked for simply because that was the only
> way to be sure it would work on every platform we had originally promised=
.
> As I understand, IE 6.0 for the Win32 platform actually pulled a fair num=
ber
> of ideas, or implementations, from the IE 5.0 on the Mac due to it having=
 a
> better security model.  That's kind of scarey to me -- why weren't the Ma=
c IE
> writers involved with IE all along?  Oh well. =20

For the same reasons as MS Word.  Not only is a Mac port
"after-the-fact," on the Mac (and most RISC platforms), you've gotta
worry about a number of things that most Windows developers never
consider.  Byte endian and, more importantly, alignment are just two
things to start.

> This is my anecdotal evidence showing just how portable MS formats are be=
tween
> Mac and Win32.  This alone leads me to beleive that there's no way in the=
 world
> that MS software on Mac will ever be compatible with the Win32 counterpar=
ts.

If the ports started on RISC, then moved back to x86, it would be
different.  But they are hacked together after the x86 release, which
results in so much naivety.  So even if the non-x86 port is perfect, it
doesn't matter when you try to send files back to x86.

> So, in short, even when MS is trying to interpret a known standard they g=
et it
> wrong when going from platform to platform.  I don't see any reason to be=
leive
> that it would be any better when they code to an internal, and often chan=
ging,
> standard either.

It's because most Windows-only developers simply don't know nor care to
learn.  I cringe everytime I hear a "programming instructor" talk about
directly reading/writing binary records from files without a thought as
to their actual, in memory / on disk organization.

That's 50% of MS Word's document longevity problem, even when just
looking at the x86 platform on its own.  A minor, but quite common,
change in the Visual Studio suite can render portions of Word documents
incompatible with even a patch.  And because of the lack of any
attention to this detail at all in the development itself, there is no
formal testing to check if these things occur before it is released.=20
There are just too many variables to test.

--=20
Bryan J. Smith, E.I. (BSECE)       Contact Info:  http://thebs.org
[ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ]
------------------------------------------------------------------
* A lecture on software piracy from Bill Gates is like a lecture *
* on adultry from the owner of a brothel of other people's wives *


--=-Tlt/elehqkt/SRKjA0G8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA+JjPNDjEszaVrzmQRAhamAJ9zcHJBCYzmPSUMCJuSkxc/UhAoXgCfcEZP
Sr39mO8vMvni0j+MBOFuL5E=
=sB8J
-----END PGP SIGNATURE-----

--=-Tlt/elehqkt/SRKjA0G8--