[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Win2003 server/SMB -- a "meatball chart" was impossible for



On Fri, 2004-12-31 at 08:59, Robert G. (Doc) Savage wrote:
> Bryan,
> Would it be possible for you to put together a "meatball chart" that
> shows version vs capability support for all this.

Microsoft found it couldn't support all the variations.  That's why
NT5.1 (XP/2003) is a "clean slate" feature implementation with only
limited SMB feature support of prior versions.

The Samba team constantly finds more every day.  They are the only ones
accommodating them.  This is a _massive_ effort, reverse engineering
style.  It's not easy.

Yet you want me to put together a "meatball chart"?  ;->

> I'm getting confused by all these details,

Blame Microsoft, they are the ones that _lacked_ the control over their
own protocol.  Most of it is due to the fact that the "Chicago" (DOS)
team did what the hell they wanted, and the "Cairo" (NT) team ended up
being unable to do anything new as they couldn't even keep up with what
"Chicago" was up to with 1/10th the resources.

> but I think it's important that this information be made available in
> a compact, easy-to-follow format.

Honestly, it would take me 5 years to dump the info.  And I would be
"questioned" at every step of the way, just like I was here with the
"FUD" comment.  I've been supporting every NT version since the NT 3.1
_beta_.  Besides being their OS/2 expert at the time**, the reason is
that I was working at the company with largest installed based of the
very first native NT application, Bentley Systems Microstation, and had
prototype Integraph PCs to play with.**

Right now I've got Microsoft's ear again.  Sure enough, it ain't doing
any good.  In dealing with Microsoft over the years, I have consistently
stated they need to "change their attitude" on how they develop
software.  I've try to detail everything from SMB to how MAPI, ESMTP and
other Exchange services work, to the lack of following the Win32
security model in a majority of the DLLs that are in the clients (from
MS IE, written for "Chicago" not NT).  I constantly get "brick wall" and
other "FUD" arguments.

Which is why I consider "Longhorn" a joke.  Just as much as "Cario"
was.  It doesn't matter how good the OS and core VS/library developers
are, the application and RAD tool vendors keep using "Chicago" code. 
which makes the whole Win32 and .NET--er, now "WinFX" APIs useless. 
I've known numerous and _good_ people at Microsoft, and they _do_ their
best.  But the management is focused on what will sell or, worse yet,
how they can use the distribution channel to force adoption, and not
what is good for the OS and consumers.

BTW, the reason Microsoft has "re-engaged me" is over current and major
security issues with Exchange 2003 -- stuff that hasn't been fixed since
I found a lot of issues with with the Exchange 5.5 parser for its ESMTP
service.  A new parser is due for Exchange 2005, but its release now
been pushed back.  A new "pack" for Exchange 2003 is going to be
released shortly, which means that Microsoft is really concerned with
the massive number of buffer overflows in the current product.  Long
story short, back in 1999/2000, when I first found the issues (18 months
before the first exploits, and 30 months before the first
0-day/administrative-privilege hack directly over network), I basically
got laughed at and then threatened not to go to CERT (which I didn't out
of fear).  My how times have changed.

No current shipping Microsoft OS or service has _ever_ been checked for
buffer overflows _before_ release, only post-release and only in
mid-2003+.  It took about 6 months after SQL Slammer for Microsoft to
"get serious" about security (long story), but it has to do with the
fact that they can't even manage patching their own systems internally. 
E.g., they rely on Altaris and other 3rd parties to resolve inter-patch
conflicts -- which was the #1 reason why SQL Slammer hit so hard -- you
were vunerable if you _were_ "current" (i.e., two latter patches
uninstalled the fix from 4 months earlier that would have prevented SQL
Slammer).

Some of the changes are good, as they are trying to address security. 
In fact, XP SP2 is quite easy to understand.  The reason for
incompatibility wasn't the new firewall and other security features,
it's that Microsoft had to _reverse_ all the "hacks" it added to the
NTkernel.EXE and network DLLs that by-pass the NT/Win32 security model
for application compatibility.  These were added into NT5.1 from NT5.0,
hence why pre-SP2 XP was more compatible with "Chicago" (DOS7 aka
95/98/ME) applications.

But a lot of the changes are because Microsoft has _no_ control over the
previous and endless variants.  But when it would completely break
something, they still haven't fixed the problem.  This includes details
like the DLLs provided by Internet Explorer (which Microsoft previously
required for _all_ new applications in order to "force" adoption of MS
IE) written for "Chicago" that bypass NT/Win32 security, as well as the
Outlook automation right down to how the Windows executive works.

The big one is how the Windows executive works and if they changed that,
nothing would work.   ;->

> You seem to know a lot more about this than most of the rest of us.

That's because I lived it -- from the NT 3.1 beta on-ward.  I was an
OS/2 and Solaris guy who also adopted NT and Linux in 1993.  I thought
Linux was a cute project but nothing feasible and NT was going to be the
future.  In 1994, when Gates move the reins from the NT to "Chicago"
group, while saying "Cario" would solve everything with 1/10th the staff
as "Chicago," I knew it was externally fsck'd versus even basic POSIX
security in UNIX.  And that was at the same time Linux finally got its
"killer app" in "A Patchy CERN httpd."

It was then I _knew_ Linux was the future.

Especially when Ray Noorda, the man who basically _made_ Novell, left
Novell to start Caldera, after Novell dismissed Linux and bought UNIX(R)
from USL.  Noorda knew what was coming.  Unfortunately, Novell wouldn't
license what Noorda needed and the rest is history -- Novell was just 10
years beyond Noorda.

BTW, Bill Gates deserves the title "Architect" -- because some of these
decisions he made that have resulted in the non-sense were directly by
him.

-- Bryan

**NOTE:  Talk about _stupid_ choices made directly by gates, unlike
OS/2, NT can't boot into CMD.EXE without the GDI -- especially since the
GDI is in the kernel NT4+.  Which is why when you can't get the GDI to
boot, your own option to fix the registry and other files is to boot
Linux.  Even the new NT5+ command console (would have _never_ been
necessary had the GDI not be required) doesn't have _junk_.  The GDI is
also why Citrix had to come up with the "MultiWin" hack (virtualized
GDI) so WinFrame and, later, Terminal Services and MetaFrame were
possible.

Not surprising this was based on Citrix's previous, proprietary
integrations of MIT-licensed (i.e., leechable) X-Window code atop of
OS/2, which doesn't need such a hack.  But in the end, I do have to
admit that Citrix's ICA is pretty damn good improvement over even the
latest X11 low-bandwidth implementations.


-- 
Bryan J. Smith                                    b.j.smith@ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.




-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.