[Pc_Support] Re: Bryan, the media is finally catching on to what you said about Longhorn

[Bryan J. Smith <b.j.smith at ieee.org>]

From: Damien McKenna <dmckenna at thelimucompany.com>
> http://www.eweek.com/article2/0,1759,1820686,00.asp
> Basically the media is finally catching on to the fact that Longhorn
> will *not* be based on the .NET platform, as was promoted a few years
> ago and thoroughly discussed by TheBS last year.
 
Adopting .NET is virtually impossible.  Microsoft will never get rid of
it's Chicago-infested Win32 codebase and make a clean break.  They
continue to proliferate a Visual Studio 6 Win32 API for everything
except the Avalon persentation and Indigo services model which are
"atop" of the Win32 base.  At that means the underlying OS
implementations continue to be flawed -- despite the original Win32
and .NET models actually being very, very good designs.

Now more than ever it is apparent that Microsoft is not bothering to
fix it's inherent product issues.  They know compatibility is what sells,
and they are going to milk it for as long as they can until companies
finally realize that security is only achievable with a break from a
platform.  So far, 90% of companies have not, so I don't blame
Microsoft for continuing to milk it's 12 year old "Chicago" codebase.

The result is that Microsoft is attempting get programs to run in
"secure sandboxes" while the underlying OS is rather pathetic from
a security model, while maintaining compatibility.  While this works
very well with Java desktop and services atop of UNIX, it does not
under Win32 because Win32 does not have inherent multiuser and
even the ultra-simple, legacy concepts under UNIX that everything
always has an owner, group and permissions -- even processes and
devices.  Especially Win32 code that is from Chicago -- which is
basically everything since the mid-'90s.

The main thing driving this, as always, is Microsoft Office and
applications built around it.  Microsoft Office 2005 is still Chicago-
code infested, and that is not likely to change.  It also means that
a 64-bit native version of Office 2005 is impossible, and many things
are breaking under XP 64-bit because of Visual Studio 6 libraries
even when running 32-bit atop of WoW.

As far as .NET 1.1 v. .NET 2.0, compatibility is shot because .NET 2.0
is based on Java 1.4 (thanx to Microsoft's recent re-license), whereas
.NET 1.1 is based on Java 1.1.  It doesn't take a rocket scientist to
realize that things like serialization that has always affected Java
updates also affects .NET updates.  But unlike the Java world, where
it is taught to avoid serialization at all costs, Microsoft has not done
the same, and has actually falling back into its "assume binary 
organization never changes on x86" trap that is why MS Office doesn't
have much inter-OS (e.g., Windows v. MacOS X) compatiblity (at least
when "sending files back" to x86).

This is the Windows platform.  It's not going to change.  Not with
Cario, not with Longhorn.  Microsoft architects come up with some
outstanding designs -- and then they are either dropped because
they break things, or they are polluted and basically do the same
thing.  Pretty much anyone who was critical to Microsoft's R&D hasn't
bothered to stick around.

Once again, I will re-iterate, once Marc left last year, I think that
was the sign that Microsoft is over as a software company.  They are
now merely an outsourcing and investment company who continues
to milk their non-evolving platform that was never designed for the
Internet.  And Longhorn is no different -- it attempts to "sandbox"
the Internet in Avalon (desktop) and Indigo (services).



--
Bryan J. Smith   mailto:b.j.smith at ieee.org