Message-ID: <200409251435.i8PEZUOU018500@pop-9.dnv.wideopenwest.com>
From: mvp at joeware.net (joe)
Subject: Windoze almost managed to 200x repeat 9/11

Definitely some interesting theories Ron.

> 1> the code was better done under the original OS, unix

While possible, nothing actually points at this as being the case. Anyway, I
would be curious as to the functionality of the system when it was first
launched on UNIX versus the end-result. Put this on Windows and run it 10
years and then port to UNIX or *nix and there will almost certainly be
screwups there as well. In fact, I would be pretty confident. I have dealt
with poor ports to and from Windows and *nix. I have even dealt with bad
ports from Mainframes to UNIX where the whole time the Mainframe people were
saying the same types of things about UNIX that you like to say about
Windows. Being a good coder for one OS doesn't make you one for all Oses
when dealing with system level components and interfaces. 


> 2> considering "how often" you seems to run into this same 
> issue with other coders in the windows realm, windows coders 
> tend to be especially lazy/clueless as compared to coders in other OS'

I would expect the issue is the same as always. Sheer volume. There are good
and bad coders period. Microsoft has surely drawn more poor coders than any
other OS with its pushing of the RAD/simple coding environment such as VB.
Additionally the Windows environment as a whole has more inexperienced users
and admins and people likely to try and code. There are also many good ones
as well, they are just well buried in the poor ones.


> 3> tools to code with in the windows realm are not as 
> 3> developed/functional
> as they are in other envs

I would say this opinion is uninformed.


> 4> M$ does not properly provide developers with clued information with
> which to do their jobs

This is another opinion which I would call rather uninformed. 

Even if there was poor function documentation, if you have a function, any
function returning a constantly increasing counter you know, as a skilled
programmer, that eventually it has to do something other than increase. If
the value is signed the sign bit will flip or if it is unsigned it will roll
to 0. How can a good programmer think any other thing? The compiler could
have inserted exception handling code but at best that is simply going to
bounce the program out of a normal running state. That is a compiler thing
though, not an OS thing. I do hope you aren't trying to tell me that UNIX
can magically and infinitely maintain a counter on a variable with a fixed
bit size. I try to consider you to be a bit more intelligent than that.



To put it in anotehr way, if you have a set of tires on a car that are rated
for 75 MPH (say off road truck tires) and some person goes 90 and the tires
fly apart or the vehicle flips or both, is the issue the driver, the vehicle
manufacturer, the tire manufacturer, or the tree that produced the rubber
for the tire? This is the same sort of case. You have it in your mind ahead
of time who you want to be at fault because you have a bug up your bum about
it and work to prove that stance. 

Poor coding is a result of poor coders. I have seen amazingly bad code on
all OS/RTS platforms I have worked on from RSTS to BSD to Linux to Windows
to DOS to VMS. I have also seen some amazingly good stuff on the same
platforms. Someone who doesn't understand basic data types and how to handle
their limits is going to do a shitty job on all of the platforms. 

Is the ratio of good admins to bad admins better in UNIX versus Windows?
Absolutely. Is the ratio of good programmers to bad programmers better in
UNIX versus Windows? Most certainly. Does this mean all Windows admins are
bad admins, obviously not. Does this mean all Windows programmers are bad
programmers, obviously not. I specifically say UNIX versus *nix because I
think *nix is one or more steps closer to Windows in this discussion and
getting closer as its popularity grows with Windows users. Switching to *nix
doesn't make the admins or coders switching (or just using in tandem) any
better simply because they switched.





 

-----Original Message-----
From: Ron DuFresne [mailto:dufresne@...ternet.com] 
Sent: Friday, September 24, 2004 11:25 PM
To: joe
Cc: mcw@....se; full-disclosure@...ts.netsys.com
Subject: RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11

On Fri, 24 Sep 2004, joe wrote:

> Again, there are valid uses of GetTickCount and there are safe ways of 
> doing so. If there is concern, I do recommend testing functionality 
> associated with each of the DLLs. You might find a bug you can report for
kudos.
>
> On the incident, I would guess the vendor never had a clue it would do
that.
>
>
> That function can't return more than 49.7 days without breaking every 
> app that currently uses it. MS can not do that. That is why there is 
> another function to get the info with a different datatype. See my other
posts.
>

What seems to read clearly from your replies to this thread is that either;

1> the code was better done under the original OS, unix

2> considering "how often" you seems to run into this same issue with
other coders in the windows realm, windows coders tend to be especially
lazy/clueless as compared to coders in other OS'

3> tools to code with in the windows realm are not as 
3> developed/functional
as they are in other envs

4> M$ does not properly provide developers with clued information with
which to do their jobs


>From which you can combine any or all of the above for a correct
interpretation of the total of your replies.

Thanks,

Ron DuFresne
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
	***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

Powered by blists - more mailing lists