Re: Win2000 has 63,000 'defects'

["Mike Dimmick" <mike@dimmick.demon.co.uk>]

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
news:38AC41FE.73461614@earthlink.net...
> Well, they may be design errors, but they aren't all merely
unimplemented
> features  (partially implemented, perhaps) as some of them are
designated
> as potentially serious problems.

My take on this is as follows:

There's a lot of legacy stuff in Windows 2000 that's still written in C
(as opposed to C++).  Microsoft programmers seem not to take account of
the much better features of C++ as regards correctness (if you've
studied MFC, they tend to use the older (int) style casts as opposed to
the new static_cast<int> () syntax).  They also have a habit of writing
what might be considered odd memory allocation routines and
strategies -- look at CPlex in MFC for an example.

However, for an operating system, at least for the kernel-mode levels,
C++ is probably the right choice.  It doesn't have large run-time
overheads, the disadvantage being if you want bounds-checking etc you
have to write it yourself.  With the advent of a lot of the standard
library, especially standard collections, a lot of the work is done for
the programmer; it's just a shame that they're so often ignored.

Windows has to remain compatible with C programming.  There's just way
too much legacy code out there.  This often means that design choices
are limited.

The newer Windows stuff is mostly based on COM.  COM is really a C++
API; while you can write COM objects in other languages, forcing them to
produce an in-memory layout for vtables can be very difficult.  COM
looks like it could be a lot better for getting software interaction
right first time -- it's surprisingly strongly typed.

I did an analysis of some of the competition -- the one the press are
all hyping, Linux -- when I first heard about this article, and read it.
I examined kernels only, versions 2.0.0 thru 2.0.38.  These releases
occurred over 38 months, an average of one a month.  It's interesting to
note that 2.0.36 - 2.0.38 appeared six months apart, so some of the
releases occurred far more frequently.

What I did was as follows:
Obtained all the patches;
Ran them through 'grep' looking for the '@@@' sequence to mark the
beginning of a patch hunk.  I then used 'wc' to count the number of
hunks in each patch.
I don't have the complete listing available, but I do remember the final
figure was of the order of 16,000 fixes.  Given that the total source
for kernel 2.0.38 was around 5Mb, I'm quite worried by that statistic.
It also appears the trend is worsening; kernel 2.2 has been out for six
months and is on something like patchlevel 20 right now.

Yes, I know it was a crude measure, but I suspect some of the Win2000
errors are very superficial.  For example, there's something I've
noticed on Internet Explorer 5: sometimes when changing windows, the
menus no longer work.  And the correct button on the toolbar isn't
always pressed (doesn't always correspond to the selected window).
Opening a new folder window usually leaves the bottom row of icons
partially obscured, when it's supposed to fit the window to the size of
the icons (this has been present since IE4.0).  And I'm sure everyones
who's used Windows has spotted it sometimes gets its icon cache in a
twist.

If a defect is a user-interface glitch like those, I'm relatively happy.
Annoying, but not work-threatening.  63,000 listed defects is not a huge
amount, but I'll be waiting for the first service pack, I think.  And
some of them will be like Novell's big shout about security flaws in
Active Directory, for which you should see
http://www.microsoft.com/windows2000/news/bulletins/novellresponse.asp,
where a 'defect' means a customer has misunderstood how to use
something.  This particular set of dialogs does appear quite confusing,
so I'm not sure which way to side on this one.

[I'd be interested to know how many of those defects are in
Microsoft-supplied device drivers, actually -- Microsoft-written because
the hardware supplier has decided they'll no longer support the
device -- my SoundBlaster AWE32 falls into this category.  If some of
the defects are in drivers for devices I don't own, I'm even happier].

Now, before you all shout about being off-topic *grin*:

Ada is a very good language for some things.  Tasking and protection of
objects for concurrent programming are very easy to do.  Object
persistence is easy to support with the 'read, 'write, 'input and
'output attributes and Ada.Streams.Stream_IO.  However the tools really
aren't there to write applications like Word -- and it would be slow in
many cases, because of the amount of run-time overhead Ada adds.
Security doesn't come cheap.

Hope this doesn't offend people,

--
Mike Dimmick
BSc Computing Science level II
Aston University, Birmingham, UK