Re: RosAsm Team is Still Making Excuses

Rene wrote:
> But, well, yes, 5 Data Bytes, with RosAsm "consume" :))
> 8 Bytes, and there is only an definitive idiot like
> you, who coul care of "consuming" 1, 2, or 3 Additional
> Byte(s) for each Data Block, in a System where the
> Sections are aligned, in Files on 512 Bytes Boudaries
> and, in Memory on 4096 Bytes Boundaries, with, usualy,
> 3 Sections per Files, that "consumes" and average of:

Wolfgang: Rene appears to be calling you a "definitive idiot" here...


Personally, if Windows is, unfortunately, so _AWFUL_ at using memory and
disk properly then this would seem _MORE REASON_, to me, for being
concerned to looking after it better, as far as one is allowed to do so
(well, actually, more like a reason for switching to Linux and ELF files,
where such stupidities are not enforced...yeah, there are things on Linux
which aren't much better but that's caused mainly by "bloatware" C coding,
not by Linux or ELF files themselves ;)...

Anyway, yes...you're not the only one who thinks like this, of course,
Rene...but if we put the rationale into words then it's perhaps easier to
see how somewhat "backwards" this kind of thinking is:

"Windows is awful, so we should make things WORSE!"

....which doesn't add up as making too much sense, really, does it?

Surely, _BECAUSE_ Windows is so bad, then this really should mean that a
programmer takes as much _care_ as possible for these things to try to
"compensate" for how bad Windows can be...

_BECAUSE_ Windows has the "file alignment" and "section alignment"
requirements then, well, this seems itself cause to attempt to keep the
"section" count low...ideally, just one section...because though Microsoft
say "Resource Section" and such, the actual references to the "entry point"
and "import table" and "resource table" are actually made via RVAs in the
"data directories"...hence, it is possible to "merge" all such sections
together into a single section (MS's LINK.EXE, as was pointed out to me by
someone here (thanks), has a poorly documented "-merge" option, where you
can actually get MS LINK to automatically put all the various "sections"
together...this tends to confuse the Hades out of OllyDbg, mind you, but
squeezes it all together :)...

Basically, "section alignment" is _between sections_...and, hence, if you
only have _ONE_ section, then you only suffer "padding" once...an
uninitialised data section does not need to be stored beyond a section
header with no data but an appropriate "virtual size"...and Intel's
warnings about code and data distinct for better cache performance refers
to CS: and DS: / ES: / FS: / GS: because, of course, we're in "flat mode"
and the CPU has no comprehension of Windows' "sections"...hence, so long as
code is assembled in one location and data in another (which will be
naturally accessed by CS: and DS:, going into the various caches properly_,
which are distinct and non-overlapping (pad to 4KB to be sure?) then the
x86 CPU won't care for whether you use one or more Windows' "sections"
because it has no idea what that (pointless)OS abstraction is all about...

So, the "file / section alignment" thing only goes so far...there are
certainly means for an assembly language programmer - with a good enough
tool to allow them to do this - to do an awful lot better with
Windows...and it's exactly because Windows is so bad that this is exactly
what we should be aiming for...

After all, if a shop is expensive, then this is reason to look for the
_CHEAPEST_ items they sell, right? If a car is broken, then this is reason
to take it to a mechanic to get it _FIXED_, yes?

So, how come the rationale defies all logic and common sense when Windows
is involved? As, for some odd reason, many seem to think that because
Windows is "bloated" then this is reason to _MAKE IT WORSE_!

This is like walking into the expensive shop and finding the _most
expensive_ item and then paying _TWICE_ its actual price, just because the
prices aren't cheap...yeah, that makes sense...because you can't get the
items cheaply, you should proceed to unnecessarily bankrupt yourself and
pay the shop far, far more than they are actually asking for...why, the
prices in that store are far too high...so, of course, "twisted logic"
dictates that you should _MAKE IT WORSE_!! You should actually pay
_TWICE_ - no, _THREE TIMES_ - more to the shop than the item actually
costs!! Yes, they aren't expensive enough! Like it or not, we're going to
pay them _MORE_ than they are actually asking for...

Sounds like absurd logic, doesn't it? If you saw someone doing that, then
you'd think they were ever-so-slightly certifiably insane, right?

Well, yeah...exactly...

And what do you think goes through my thoughts when I see people using the
exact same rationale with Windows: "Windows is terribly, terribly
bloated...it's so, so monsterously big and slow that, of course, every
programmer should endeavour to MAKE IT WORSE!! Yes, it's not bloated
enough! We must add more and more bloat...so, you think you can make it
smaller? Save a few bytes? Are you mad?!? We don't want this! We want more
and more bloat...make it worse! Make it worse!"...

Sorry, but the opposite should be true...you are pointing to how bad
Windows is...exactly...so, _DON'T MAKE IT WORSE_...indeed, if you do, then
aren't you exactly just as much guilty of "bloating" as Microsoft
themselves are?

After all, why do you think Windows itself is so bad? Because its
programmers also started thinking: "Oh, it won't matter to lose a few bytes
using C...oh, it won't matter if that small thing isn't efficient...oh, it
won't matter if...oh, it won't matter if..." and, to an extent, it's quite
true that, in the individual cases, it's all pretty "immaterial"...alone,
these "small things" don't really mean a great deal...

BUT we're NOT actually talking about "individual cases", are we? The _WHOLE
SYSTEM_ needs to be considered...and all the "who cares?" bytes lost here,
all the "it doesn't matter" kilobytes lost there, all the "machines'll be
better tomorrow" CPU cycles lost over there...all of
it...little-by-little...byte-by-byte...cycle-by-cycle...

It's like, in the 1970s, someone poured a can of "goodness" into
computers...and, over the years, a small "leak" developed...drip, drip,
drip...there goes the "goodness"...ah, it doesn't matter...look, it's only
a byte...it's only a cycle...who cares? A single lost drop of "goodness"
doesn't matter, yes? Drip, drip, drip, drip...

Until, in 2005, someone else pulls off the lid on their PC to look into the
"fuel tank of goodness"...and, oh crap, the tank's running completely on
"empty" now...

Yeah, an "individual drop"? Who cares? So, you just stand there watching:
Drip, drip, drip, drip...no need to act...all of these are just
"drops"...none of which mean a single thing individually...so, you just let
them go: Drip, drip, drip, drip...no, the big pool of liquid on the floor,
it's no kind of "clue" about what's going on...that the pool of liquid on
the floor from all the "drops" is clearly far, far more than just
"individual drops"...no, nothing to worry about...because, you see, all I'm
seeing dripping out the side are "individual drops" and we're all in
agreement: "Individual drops lost are meaningless", right? Drip, drip,
drip, drip...

It's basically a case of "attrition"...a slow and gradual "decay"...

"What's in a byte?", you say...

The entire world...a byte can be colours, numbers, conditions, events,
pixels, sounds, notes, co-ordinates, characters, words, locations,
languages, etc., etc....basically, a byte can be _anything_ you want it to
be...the most "polymorphic" entity available to humankind, basically...

So, quite literally: "what's in a byte?"...absolutely _EVERYTHING_ is in a
byte...both literally and metaphorically...

Hence, I'm with you on this, wolfgang...don't surrender a single byte or
cycle without at least putting up a fight for it...as the programmers of
the past were capable of doing so much with so little simply because the
hardware _forced_ them to adopt that attitude...they could not choose
anything else...but now that we have the alternative option? Nah, we
_STILL_ should choose the exact same choice...this time, though, it's
_willingly_ because now we've learnt the _COST_ of our decision...

I point again to the obvious and blatant "connection" that surprisingly few
people ever make...on the one hand, they advocate "time to market"...they
advocate all these "sloppy programming" habits...they say this is a Good
Thing...but, then, such "theory" does not live inside a "bubble"...there's
a simple measure of whether these ideas and techniques actually work...most
software these days is written by following these "philosophies"...and what
do we see?

Are we stunned and awestruck by the speed, by the brilliance, by the
professionalism of the leading Microsoft Windows operating system? Well,
Microsoft, if anything, are the "poster child" for these "who cares?"
philosophies...they do it better than anyone else...

So, you know, make that "connection" between the "cause" and its
"effect"...the piles of crap software that we're all using? Well, _THAT IS
THE RESULT_ of following these attitudes...obviously, of course...because
that's the dominant attitude of programmers and that is what directly
results from them following that attitude...

It's hardly rocket science, yes? Simply a case of "look before you
leap"...before "leaping" to copy Microsoft's practices, before "leaping" on
a "theory" that such-and-such sloppy programming "doesn't matter"...well,
_LOOK_ at what it produces..._LOOK_ at the heap of crap that is software
that's foistered upon you today...and, before you "leap" to copy, realise
_exactly_ what it is that you are duplicating...

Sorry, Rene...but you claim to be a "real assembly programmer"...and then
claim that this stuff "doesn't matter"...and, well, you might use assembly
mnemonics (sometimes, in between lots of "IF" statements) in your
programs...but I don't recognise an actual assembly language programmer
there at all...

On the other hand, I very much see an assembly language programmer in
wolfgang...and it's not because he uses "hex coding" (though that _IS_ a
kind of "symptom") but because of his _ATTITUDE_ to every byte and cycle in
the program...they _DO_ matter...you can't always save every single
one...sometimes, we simply just don't have the time available to do it
absolutely...but the attitude should be that we _TRY_ to save every single
byte and cycle but, regrettably, it cannot all be done...

Even in Herbert I can see the right attitude...yes, he advocates using HLLs
when it "doesn't matter"...but when it does matter, it's time to even get
obseseed with "hand-coding headers"...my only point of disagreement with
Herbert would be to say that it _ALWAYS_ "matters", in fact..._EVERY_
redundency, _EVERY_ inefficiency _IS_ a "wound"...but, as "doctors" here,
we do, regrettably, have to accept that we can't save every single
"patient"...but we will _TRY_ to do so...and, as our time is not infinite,
then HLLs and HLLisms can be used to speed through "non-emergency
cases"...BUT only in the pursuit, if you will, of supplying _more time_ in
order to deal with the "emergencies"...

The difference in attitude might be subtle but I think it's all
important...it's the difference between "good enough" and _GOOD_
software...it's all "in the details"...that attitude of pushing it _just
that little bit further_ than you strictly need to do so...not because it's
"needed" but simply because it's _wanted_...

Good painters take a paintbrush and use their natural artistic talents...

But someone like Da Vinci took the time to compose his paintings first...to
calculate in his little scrapbooks where the light would land
mathematically...to measure out "golden sections" and geometric shapes on
which to "hang" his painting in compositional terms...to study the biology
of the humans and animals he had to portray to understand the muscle
structure beneath their skin...and _THEN_ he picked up his paintbrushes...

It is the difference between merely "okay" and "a work of genius"...it's
all in the details...in taking it just that little bit further than you
strictly need to do...in popular saying, it's interesting to note that both
God and the devil are attributed to being "in the details"...I suppose
that's because if you _care_ for the "details", you find the good of
God...but if you do not care for the details, then you'll only find the bad
of the devil...that this is the difference...that the "battle" is waged at
that level...

Beth :)


.

Relevant Pages

  • Re: The Microsoft Way (OT)
    ... > yet there isn't one single original thing about Windows that didn't appear ... MS did in the beginning, and cash in on support, and later improvements? ... Its left to the programmer. ... This card stated, ...
    (alt.lang.asm)
  • Re: Copy Right Protection
    ... | So that technique provides some protection but not total. ... the Windows solution only works for Windows. ... | what images to protect and which images not to protect. ... | make it available for free, but the programmer using codeguru.com was told ...
    (microsoft.public.frontpage.client)
  • My "Search" function in Win XP suddenly stopped (Totally)
    ... I have used PC's for 10+ years and I've used Windows since 1989. ... not even close to being a computer expert or a programmer. ... GUI or Command thousands of times in various permutations. ...
    (microsoft.public.windowsxp.configuration_manage)
  • Re: "Access is denied" on local machine
    ... That is exactly what every other programmer in every other language ... We have windows service WMI ... it fails with the "Access is denied" error code. ... > fix it. ...
    (microsoft.public.win32.programmer.wmi)