Re: OT: my new PC rocks!!

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 11:27:05 -0000

Ben Yates wrote:
> Beth wrote:
> > Mind you, I _still_ can't get Linux installed on my "Linux box"
second
> > machine...it's only a 450MHz...I checked the jumper settings and
they
[ snip ]
> > then I can't get any Linux version (not even the old one I still
kept
> > on CDs) to get back on there...
>
> Well, if you ask a Linux expert (or in a Linux group), they are
likely
> to tell you that you are a Windoze user who doesn't understand
Linux,
> and they have never had any issues, and there machine uptime
measures
> in years, not months, and etc...... ad nauseam.

Yeah, well, there is a _reason_ why I've not bothered to ask a Linux
"expert" on a Linux group...they are very pre-occupied with their
"voodoo black magic" stuff, aren't they?

"Install problems, you say? Ah, did you sacrifice a chicken and pour
its blood all over the CDs first? What?!? How can you claim to
'understand' anything when you don't even comprehend this simple
MXYZLYQPTIK ritual? What's 'MXYZLYQPTIK', you say?!? Why, that's the
'intuitive' command name for the chicken sacrifice utilities you
should run (oh, just remember NOT to say the word backwards aloud...or
else all your data disappears back to the 29th dimension ;) - in a
_specific sequence_, dictated by the passage of the Moon and planets
at the time of the summer equinox - before reversing the polarity of
your anti-matter warp drives...what's that? Yes, I am also a Trekkie,
as it happens...how did you guess? Sorry, I don't understand...what
does this 'meaningless techno-babble' phrase mean, as I'm unfamiliar
with it? Anyway, you should easily fix up your install problems by
following the rituals...oh, and you have to edit a few configuration
files too...about a hundred of them, that's all...ah...yes...then
there's also the tachyon re-calibration procedure...but it's all
pretty much fool-proof, as long as your particle accelerator is
aligned...what?!? You don't have a particle accelerator in your
basement? What sort of clueless newbie are you?!? What's that? No, I
don't think I am familiar with the term 'assembly language' and who on
Earth are all these computer companies you mention? Computers didn't
exist before 1995, _everyone_ knows that!! Really? You have to
'program' the things, eh? No, no...I don't recognise any of
this...anyway, it's _you_ who's the 'clueless newbie' in not
appreciating that - for no particular reason that I can mention or
even, really, comprehend - computer systems _must_ be this complicated
and convoluted"...blah-blah-blah...unfortunately, I started to fall
asleep at this point - even though it _is_ just a fictious Linux
expert I've just made up rather than a real one - so can't continue
this "enthralling" monologue any further ;)...

> That is the reaction I got when I asked about the same issue with
Red
> Hat.

You got off lightly...now, if they'd _actually_ tried to help you then
_that_ is when the real punishment begins; Make sure to stock up on
ritual chickens for sacrifice, have a gigantic notepad to jot down all
the bizarre "intuitive" utility names and don't forget to pop down to
"Radioshack" to see if they've got "tachyon emitters" before you begin
;)...

> I'm not saying they are wrong, but I've gotten use to operating
> systems that don't crash during installation... Like Windoze,
OpenVms,
> etc...

No, they _all_ crash on occasion, to be fair...Windows just tends to
do better than most, simply because they have all the hardware
manufacturers working specifically for them, as part of their
"protection racket" Maffia thing they've got going (for example,
Microsoft basically "owns" the ACPM thing and has the hardware
manufacturers dancing to their tune...Linux and others, though, have
to attempt to unravel and reverse engineer badly written documentation
to fathom what drugs Microsoft are on today...which, understandably,
isn't the most reliable process in comparison to what Microsoft are
doing...heck, _by definition_, Microsoft can't be wrong...if you ain't
complying with the "PC 2027" specifications then it's the _hardware
manufacturer_ who's "in the wrong" for not complying, Microsoft are
blameless by definition ;)...

Plus, knowing Microsoft, it's _still_ DOS (which itself uses the BIOS
for practically everything ;) doing all the work and the "Windows" bit
is merely the pretty graphics and mouse pointer routines to stare at
while it installs...and they've had almost two decades to perfect that
same old DOS code...I, again, point to the mouse pointer itself as a
clear example that Microsoft employ "code re-use" to silly levels,
while - in their marketing hype - pretending that they've re-coded the
whole thing from scratch...

The Windows 3.x mouse pointer (it might even have been present for
Windows 2.x, mind you...I just never saw anything but screenshots of
that version, though, as I "joined the PC" at this point, so haven't
actually seen it up and running to test if this "bug" is even older
than I'm crediting it for ;) had a pretty pathetic cosmetic
"bug"...when you moved it to a window edge, then the pointer would
change...now, for one frame, the mouse pointer changes shape but
_still_ is displayed at the old mouse pointer's "hot spot"...then, the
frame after that, it corrects itself and displays it at the correct
new "hot spot"...and this happens each and every time the mouse
pointer is changing shape...it's only a "cosmetic bug" and doesn't
really cause any problems, except for a distinctly amateurish "jerk"
when the mouse pointer changes shape (and I mean "amateurish", as this
is almost certainly easily fixed in a matter of five minutes, just to
make sure that the "hot spot" changes at the same time as the cursor
shape...I've always foudn the "amateurishness" of this and other
Windows visuals - such as the titlebar that flickers as you're
resizing (this one is still present; Select "show contents while
dragging" - which is the default these days - and then grab the
bottom-right corner and just move that mouse pointer around with wild
abandon, keeping it constantly moving...now, look at the
titlebar...it'll be flickering every so often...the reason for this is
that Windows GDI is directly writing the graphics straight onto the
screen - no "off-screen" buffer, despite this being a _clear case_
where "overdraw" will occur - and it first wipes out all the pixels of
the titlebar with the background then goes back and _overdraws_ the
titlebar text...this is a case of "overdraw" - writing to the same
pixels multiple times on the actual visual screen the user can see
(rather than hiding this away on an "off-screen" buffer so that the
user doesn't suffer seeing it) - and can be solved in two ways: either
use a small off-screen buffer to draw the graphics completely
off-screen and then blit it into view...or, if you prefer, ensure that
the titlebar drawing routine _only_ ever writes to a particular pixel
_once_...that is, don't just clear the whole thing with the background
but write the background and text at the same time...some sort of "is
this pixel part of the text? Yes, draw it in the text colour...No?
Then draw the background" routine...note that calculating the new
"anti-aliased" edge would be completely in-keeping with doing both at
the same time...rather than writing, reading, modifying, writing...to
cut a long story short, these many, many "cosmetic bugs" throughout
Windows and the dreadful operation of GDI and how switching back and
forth to DirectX often corrupts graphics (both the desktop and / or
the DirectX full-screen game you're running)...well, all these
conspire to tell me that they either don't have a graphics programming
specialist...or the ones they've got are simply crap and should be
sacked...this stuff is "graphics 101" and they can't get any of it
right...in fact, I've been watching and the pattern is clear: they
don't sit down and work out what's needed...instead, you can watch
them "trial and error" the whole thing over successive versions until
there's a "oh, crap...this'll have to do" solution sitting on your
desktop ;) - fills me with zero confidence in their programmers'
abilities ;)...

Anyway, this same mouse pointer problem appears in Windows 95 and
Windows 98 and, basically, covers at least a decade of their
products...now, I simply don't believe that they were "recoding from
scratch" and, coincidentally, making the same simple, idiotic mistake
every single time (and, if they were, that's _more condemning_ rather
than less so..."consistent repeated coincidental incompetence" (which
is so highly unlikely as the reason, you'd need a few hundred decimal
places to write out all the zeroes in the odds of this actually
happening "by accident" ;) would be the only "defence" and that's
actually _worse_ than what I am going to accuse them of ;)...hence,
the mouse pointer code's little "cosmetic bug" shows that those
routines responsible for this were NOT altered (even though there is
clearly a "bug" inside them, just looking at the visual output ;) for
at least a decade...the titlebar dragging has been there from Windows
95 (note that only with the Windows 95 "Plus" pack could you actually
select "show contents while dragging"...hence, the titlebar has
probably been "overdrawn" since the very first Windows version but
only with 95 could you _visually expose_ their amateurishness for all
to see :) and this one _still_ isn't fixed even today...

And the mouse pointer "bug" has only been fixed, not because Microsoft
wanted to remove the bug...but, in order to allow for the "mouse
pointer shadow" effect they've introduced, they must have re-coded the
mouse routines and, this time, not made that same idiotic "hot spot"
mistake...so, it _is_ fixed in XP now but only because of the
introduction of "shadows" (a case of "keeping up with the Joneses"
because other GUIs were introducing such features...I doubt they'd
have bothered at all unless there wasn't that small bit of "pressure"
on them...so, yes, some _competition_ to keep Microsoft on their toes
and stopping them being complacent does exist...but, unfortunately,
not in sufficient measure, I don't believe, that they can cite this as
some sort of "defence" that they aren't a monopoly...but you can
understand them trying that one on with the judges in the DoJ
case..."worth a try", I suppose, right? ;)...

What gets to me most is not just that Microsoft have a string of such
"incidents" to mention (you could start up a _daily_ magazine on the
issue and never run out of contributions ;)...but the much more
sinister side of it...that people have been trained to be "tolerant"
of such amateurishness..._everyone_ who's used Windows between 3.x and
XP, at least, must have - even if only subconsciously because they
aren't looking directly for it - _seen_ their mouse pointer doing this
bizarre little "dance" whenever they tried to move the mouse pointer
near the edge...heck, there must be a heck of lot of "newbies" out
there, struggling to learn how to use a mouse and getting used to the
delicate positioning needed to be on the small 3-pixel or so "border"
where the mouse pointer changes, only to have been startled to find
the mouse jumping around the screen willy-nilly...

Unfortunately, indeed, humans have an amazing capacity to "get used
to" practically anything...so, everyone moves the mouse pointer and
their mind "edits out" these quite appalling visual "glitches"...well,
I used GUIs before coming to Windows and when I saw that happen, I was
shocked by...well, there's no other way to describe it...the complete
incompetence displayed...mouse pointers, of all things, should not
suddenly do little "dances" because the pointer is changing shape...in
fact, when the pointer is changing shape, this is a visual signal that
the area the mouse is hovering over has some significance...thus, for
it to start "jerking" about the place at the very point when it's
supposed to be signalling the significance of an area as small (3
pixels or so) as the border, it's a complete betrayal of all the
principles of human / machine interaction and good interface
design...to me, this signals a complete abandonment of any care for
quality whatsoever...I mean, you've got to make sure to change the
"hot spot" at the same time as you change the image so that the new
image is drawn in the right place (but, consistently, with this bug,
there's _always_ a frame displayed where the mouse is in the wrong
place...it's not even an intermittent visual bug...so, literally, it's
changing the "hot spot" in a _completely different_ frame to changing
the pointer shape...there's _no legitimate excuses_ here that can
explain it, other than simply: Microsoft don't give a crap :)...fixing
this took a decade, while it almost certainly - being a minor
"updating the variables" timing problem - would have been a "five
minute job" to fix...

The code is being "re-used" to extreme levels without doubt here...the
"going 32-bit" sounds impressive but really just meant feeding the
same _BUGGY_ C source code into a 32-bit compiler rather than a 16-bit
one...so, all the same logical bugs are alive and well...as the fact
that the Windows 3.x mouse pointer bug transferred perfectly to
Windows 95 / 98 / NT without a single error being fixed...the bugs are
now 32-bit bugs rather than 16-bit ones...but, if you look at the
screen, the exact same incompetence is displayed with faultless
precision (literally, the bug is logical and the bug in the logic has
not been altered one bit by "going 32-bit" so it's _exactly the same
bug_, just the code that faultlessly implements the bug uses "EAX"
rather than just "AX", while it happily does everything wrongly all
over again ;)...

Hence, the fact that installs are somewhat generally less prone to
crashing (but certainly not "guaranteed not to do so" by any
means...Windows _does_ crash on install too, I can assure you
;)...well, that's all down to religious "code re-use" and simply lots
of "trial and error" hacked "quickfixes"...after all, even starting
with the most incompetent code you can imagine, having two decades
worth of "hack here, hack there" and religious "code re-use" _will_
eventually get you something "mostly" reliable (bloody awful code with
no proper structure, mind you...but after coding in the 900th
"exception to the rule IF statement" into it, you eventually have code
that ducks and dives practically all potential problems ;)...

But this sword is double-edged...because, by the same token, this
religious "code re-use" (or more commonly known as "laziness"; Bill
Gates said it outright: "if the bug isn't profit threatening, then
we'll leave it alone"...so, as long as no-one switches over to Linux
because of the repeated Blue Screens of Death, then Bill ain't going
to do a blessed thing to remove those BSODs at all...XP desparately
tries to fix all these bugs _two decades too late_ because, yes,
Windows really had begun to have such a bad, bad reputation that a
small "exodus" over to Linux was beginning...without that threat, we'd
probably _still_ be wondering when Microsoft would make good on their
promise to "merge the 9x and NT streams with a reliable NT kernel" to
this day...they delayed it once because things died down a little on
the DoJ case front...if the threat had vanished then MS would have
returned to what they always do: "The Line of Least Resistance"
(A.K.A. "laziness"...if they can still make money selling crap then
they'll carry on blissfully selling crap without a second
thought...the simple mantra: "aim for _no_ costs but total
profits"...maintenance _costs_ so do as little as is possible...and,
you can bet they'd do _NONE AT ALL_, if it weren't for the fact that
people would certainly then "wise up" to Microsoft's tricks and all
install OS/2 or something instead...so, "new" versions where they've
changed the graphics and added a whole bunch of useless API that
no-one needs or wants anyway, just to give them something to show and
say: "hey, look! We really have changed it"...but this "change" is no
more useful than if Microsoft just dumped an extra 3 Gigbytes of
random data in files into the "Windows" directory that does nothing
useful at all...I often suspect with Windows' gargantuan size if,
indeed, they actually _really did_ do that once or twice...is there
any actual code inside some of these DLLs or are they just files full
of random data loaded by Microsoft applications merely to "give the
appearance" that they are OS components? For instance, what _does_
"cnbjmon.dll" or "ixsso.dll" actually do? Are they really "important
system components" or just "printf" and "strlen" bundled into a DLL
full of junk to pad it out to an impressive-looking size, just to make
you think Microsoft have been doing lots of "really important but
difficult to understand" work all this time? I mean, there's bloody
thousands of the things...are there really that many "important system
things" to be done that _requires_ so many gigabytes and tens of
thousands of API? Especially when we know that _drivers_ are the sole
components responsible for _actual hardware access_ (otherwise, you'd
have "violated" the principles of "safe", "protected" layered OS
design...again, a case of "either I'm right and it's awful...or, in
fact, the alternative actually suggests things are _even worse_ than I
imagined"...damned if they do, damned if they don't ;)...so, again,
what are these things actually doing? What use are they providing?
Does any software not written by Microsoft ever load in the
"cfmondhfke.dll" file? If not, then isn't this taking major Liberties
with our hard drive space just to accomodate Microsoft applications?

Hey, there may be a use for Rene's "re-assembler" after all in
answering such questions...not that I'd, of course, suggest that
anyone should in any way breach their EULA which specifically - in a
highly paranoid way (what they hiding? ;) - prohibits reverse
engineering...phrased in such a way that it sounds like you'd get the
death penalty simply for thinking about doing it...but, well, you know
what these "cracker" types are like...I'm not encouraging or condoning
such actions at all...it's just that if someone does do it anyway off
their own backs of their own freewill, unrelated to any comments I may
have made, then simply answering "Yes, it _is_ full of useless junk,
merely to impress people" with no more details than that given, it
wouldn't really be a breach of their intellectual property rights at
all to provide a simple "yes" or "no" answer to the "are we all being
shafted big-time by a bunch of crooks?" question...

Beth :)