Re: Linux, X, ld, gcc, linking, shared libraries and stuff

\o/annabee wrote:
> Excellent programming, Beth, but how does this show anything that isnt
> otherwise known, via ws32.exe or the program posted by Kroll ??

Oh, it doesn't...but Phil suggested writing a program to test it out and I
just thought "why not?"...just have some "fun" programming it...

Also, it was me who "clued you in" on the "Winsight" program being in your
Delphi package, anyway, lest we forget ;)...

> What I
> find is that when I do not move the mouse, no messages arrive. So how can
> this be terrible? Isnt this exacrly what we want?

This is the point I think you're not understanding...

It doesn't matter what GUI we're talking about, _NONE OF THEM_ will produce
a "mouse move event" when the mouse isn't moving...for slightly obvious
reasons that it would be patronising to labour over...

So, there is NO distinction to be made between any GUI on that point...you
will find this to be true _WHATEVER_ GUI you're using (and note that I'm
being fully "generic" that this holds just as true on "Mac OS X" as Windows
or X...because it's "inherent": You only receive "event messages" when
"events" actually happen :)...

_ALL_ GUIs are "event driven"...again, this is "inherent" in the GUI
interface style itself...users can click on things in any old order they
like, so programs have to be regulated by these "user events"...and there
is _NO DISTINCTION_ to be made with _ANY_ GUI on this point either...they
are _ALL_ "event-driven"...

Another commonality - related to "multi-tasking", actually, but GUIs all
tend to be running on a "multi-tasking" OS that this holds true for most
GUIs in general (note: "co-operative" or "pre-emptive" is immaterial, in
this case, so 16-bit Windows was equally the same in principle, if not
entirely so in implementation :) - is that they follow a "blocking" scheme
too...note, as I've mentioned, that "blocking" is a _multi-tasking_ /
"scheduler" thing...GUIs simply "make use" of this _scheduler_
capability...

Hence, all GUIs on "multi-tasking" systems (which, generally speaking, is
usually the case :) will "block" on waiting for a message...

Thus far, on _NONE_ of these points can we draw a single distinction
between _ANY_ GUIs, much less specifically between Windows and X...these
are all general "commonalities" that you will find on _ALL_ GUIs...this is
true for them all...

Following so far?

Now, of course, a GUI - any GUI - will offer a range of "events" that can
be reported...mouse movement, keyboard input, particular "conditions" such
as initial entry of the mouse pointer into a window ("enter / leave"
events), etc....and these "events" are reported to an application so that
it may respond to them, as appropriate...

Related to this - but actually part of general "multi-tasking" operations
rather than anything GUI-specific - is where an application "blocks" on the
condition of receiving an "event notification" rather than "polling" for
it...

So far, we've not mentioned anything that doesn't apply to _ANY_ GUI out
there...so, yes, Windows has these things...but there's not the slightest
thing "unique" in that...they _ALL_ do have this general design and
implementation...

Where we begin to see a difference between Windows and X (actually, there's
loads more than just this, such as "network transparency", "distributed"
functionality and such...but this is the specific point we've been talking
about), is a small, simple difference in "event notification":

With Windows, it will deliver a message to the application's queue for
_EVERY_ "event" that transpires...

With X, an application specifies what classes of event it is interested in
receiving, then X delivers an "event" the application's queue for _EVERY_
"event" that transpires _WITHIN THOSE SPECIFIED CLASSES OF EVENT_...the
application may "qualify" what "types" of event notification it receives
and this limits the events reported by X to the application to within these
specified classes of events...note that _ALL_ events of those classes as
fully reported every time they happen (unless you change the "event mask"
to include / exclude classes of event dynamically)...but you can restrict
it to just the "events" the application finds _USEFUL_ to have reported...

And if you _STILL_ don't get this difference by now, Wannabee, then you're
beyond all Hope...and if you _STILL_ think it's inaccurate then I'll pull
out the documentation from Microsoft and for X which confirms it, I'll
write the programs that outrightly demonstrate it categorically without any
room for dispute and so on and so forth...this is quite correct, so, you
know, we can "play games" all year long but, in the end, these are the
actual facts here...

> Beth wrote:
> > I _WAS_ going to put in a "PlaySound" API call that would play a
> > "gunshot.wav" every time a message appeared, just so that you could not
> > only see the "machine gunning" but actually hear it...unfortunately,
> > RosAsm
> > doesn't yet support "PlaySound" (I did try putting "call
> > 'mmsystem.PlaySound'" but RosAsm reported that "mmsystem.dll" does not
> > exist on my system...
>
> Try using : 'winmm.PlaySoundA' instead. Tip I got from one of the Rosasm
> forum members a year ago.

Yeah; I just tried it out...it works...thanks for the "tip"...I don't
regularly visit the RosAsm forums myself, you see...and I don't see
anything about this in B_U_ASM (well, it might be there but I couldn't find
it :)...

Also, there's some Microsoft nonsense involved here...as they've got a
strange set-up where "mmsystem.dll" is a 16-bit NE...and then "winmm.dll" -
or, so it appears...but more "investigation" might show even more
weirdness - is the same thing but in 32-bits...if Microsoft make this
difference clear in any of their documentation, then it's all the
documentation I haven't read yet...like they are trying to "keep it quiet"
or something...

Nevertheless, Microsoft weird crap to one side...now that you've told me of
the _REAL_ DLL to call, it does, indeed, work just fine...see the other
post with Rene about what code to pop into my example...although, well, you
could work it out yourself probably, as it's only adding in one "PlaySound"
call to the right place in the program...hardly that complicated :)...

> "machine gun"...
>
> > Wannabee :), then I suppose I could have used DirectSound for the
> > "machine gun"...oh well, there's a "project" for someone else...
>
> Indeed.

Actually, after getting "PlaySound" to work, then I think only DirectSound
or something would actually do the "sound effect" properly...it doesn't
quite work with "PlaySound" because the next gunshot cuts off the last
gunshot...I was expecting this, mind you...but I was not expecting it to be
so quick that you can't really hear anything...you know, it "stutters" the
start of the WAV so quickly that we don't hear enough of it to get the
"BANG!" of the gunshots...so, to get the "sound effect" to really work
100%, you probably would need to code DirectSound...as DirectSound can play
_MANY_ of the "gunshot" sounds simultaneously, so that each "gunshot" would
play independently (up to the maximum amount your soundcard can handle but
if that's 32 or 64 or more voices then that'll be more than enough :)
without the thing that spoils it with "PlaySound" that not enough of the
WAV file is played because it is cut off to start playing the next
"gunshot" sound far too rapidly...

Anyway, that all sounds like too much work for what was, after all, just a
"passing comment"...BUT there's 5 Euros on the fact that if you did set it
up to fire a single "gunshot" sound every time a message arrived, then
moving the mouse or resizing the window would produce a noise akin to a
"machine gun"...thus, _literally_ demonstrating that my "metaphor" of
calling it that _isn't_ an unreasonable description at all :)...

> > Also, it's a very "cheap" implementation because it's "quick and
> > dirty"...there's about 1MB of RAM allocated to the edit control at the
> > top (virtually, though, shouldn't make the EXE any bigger :)...there
> > are NO checks for "overflow" on this, though...if all the text exceeds
> > 1MB then...well, as manuals like to say: "undefined behaviour may
> > result" ;)...
>
> I think your app is excellent, even learned a trick.

Glad it was useful...

I was just pointing out here, though, that because it was a "quick and
dirty" program, there are a few "crap bits" in it...such as the application
doing absolutely nothing to keep the data in the "edit control" at the top
of the window "overflowing"...it'll just keep on going regardless...but I
thought 1MB was more than enough (you'd have to run it for a while,
generating a lot of messages to "overflow" that limit :)...but, well, just
to point out that I do _know_ that it has "bugs" in it like this...it just
wasn't worth the time and effort for such a simple demonstration to bother
"doing it properly" :)...

> > It only bothers reporting the messages of the actual window itself...a
> > more
> > complicated "message viewer" would do better than that, of course...but
> > this is "quick and dirty" ten minute coding, just to "demonstrate"...
>
> A real messageviwer was posted by Kroll some days ago. Thats much more
> work. noone is expecting you to do all that work for nope.

Yes, I realise that...I'm just pointing out that this program _ISN'T_ a
real "message viewer"...just being "informational" about what it is I was
posting...you know, so people don't post "Beth, this doesn't work here and
that function isn't there and...and..." or something...to point out that I
know it's crap and it's supposed to be crap, as it's only to demonstrate a
point...not really to be generally useful for anything...

> > Of course, it's a "personal opinion" whether to call the rate at which
> > the messages appear "machine gunning"...but, when you see it, you
> > shouldn't find my little description too out of whack with what's
> > going on...
>
> Your description is 100% crap,

Put the "PlaySound" into the program and a "gunshot" sound into the
directory with it...run the program and resize the window...now,
"PlaySound" doesn't quite work properly for the correct "effect" (because
it stops one gunshot dead in order to play the next one and, for a proper
"machine gun" sound, they should really be "overlapping") but it's near
enough to sounding like a "machine gun" _LITERALLY_ when you do
that...hence, as this was only meant as a "metaphor", the fact that it can
be made to _sound_ literally like a "machine gun", shows that my
description is NOT far off the mark at all...

> just like your ??? description of the resizing of the window
> caption, ad many others. I can assure you, that
> there is _no_ way to avoid redrawing of that. However you are correct
> about the flickering.

You don't actually comprehend my point, I think, and you're
misunderstanding what I'm saying...

You're too eager for "confrontation" that you're not listening properly and
jumping in with "you are 100% wrong and evil and bad and nasty" before your
brain has "engaged" properly on what's being said...

My point was that the "flicker" is being caused by "overdraw"...and
"overdraw" is when the same pixel is written to more than once with
different colours...

Effectively, what is happening is that sometimes - when the monitor is
tracing the beam down the screen - it is "catching" the colour of the first
write to the pixel...when we only want the second write to be displayed...

Hence, to "cure" this flicker, we must ensure that this doesn't
happen...there's a few ways to do that:

1. Synchronise with the vertical retrace and make sure to write all the
graphics inside the vertical retrace period...this way, it should never
"catch" the first writes to the pixels and only the final, finished
graphics, when the monitor is actually tracing its beam down the
screen...this, though, requires accurate timing to get right...if there's
too much graphics to be draw within the vertical retrace period, then this
method just won't work because you can't get the graphics done in time
(now, if only GDI had more optimal performance, eh? ;)...

2. Re-arrange your graphics routine to ensure that it simply does not ever
write to any pixel more than once...this can often be highly complex to
arrange, granted, depending on what graphics you're attempting to
draw...but it's one way to avoid "flicker"...if you need to change the
"background" behind a "sprite" in the foreground then, yeah, this can be
complicated to make happen...but you'd recode the routine to "mask out" the
foreground object while drawing the background...this becomes even more
complicated with "anti-aliasing" to deal with...but, you know, there is
_always_ a way to recode a graphics routine in order to deliver "write
once" on every pixel only...it _isn't_ necessarily easy to code and, yes,
it can be so complicated that it's better to, instead, use one of the other
methods because it might be too slow or just too darn complicated that it's
giving you headaches...but it _can_ always be done...note, for example,
that most "ray-tracers" inherently follow a "write once" method (this is
"coincidence", though, from how they work...most ray-tracers are far too
slow, in practice...but, well, they _DO_ tend to follow "write once", while
producing some of the most complicated and photo-realistic graphics
computers can manage...so, you know, if they can manage it with something
so complex, then it _surely_ can be done with boxes and gradients and other
"primitives"...that is, _IF_ the coder knows what the frack they are doing
properly :)...

3. The easiest method that it's the most used one: Write the graphics to an
"off-screen buffer" and then copy it across when finished...as all the
graphics are actually drawn "off-screen", there's no way that the monitor
could "catch" graphics half-way through drawing...so, you can "overdraw" as
much as you like, it won't ever "flicker"...this is basically, of course,
what's going on with "double buffering", where it simply keeps two buffers
for the screen...one that's being displayed, one that's having graphics
drawn on it...and then, when the graphics are complete, the two are
"flipped" around...but it can also be used more generally with smaller
sections of a screen (you know, "double buffering" is just the "special
case" when you apply this idea "full-screen" :)...

....and, well, any other way that either avoids "overdraw" or avoids the
"overdraw" being _seen_ will work (the flicker is caused by "overdraw"
being "caught with its pants down" half-way through being rendered...that's
the problem...so, any solution that prevents that happening will get rid of
the flicker...the above are the three most "obvious" and generally used
ways of doing this :)...

Now, I do understand what you're saying...what with the "gradient" effect
and "anti-aliased" titlerbar text, it's not going to be easy to come up
with a "write once" algorithm...BUT...BUT pay attention to what my
criticism _EXACTLY_ was: That it _IS_ possible to do so (not "easy", sure,
but always _POSSIBLE_, if they really tried)...and that the fact that
Microsoft have not bothered and gone for the "easy" route was a "lack of
professionalism"...that this is "amateurishness" on the part of
Microsoft..._THAT_ was the accusation...

If going for "method 1", then they could synchronise the writes with the
"vertical blank" so as to avoid the "overdraw" being "caught" by the
monitor refresh (assuming GDI is able to render the graphics fast
enough...but, if it isn't, then Microsoft are _ALSO_ responsible for GDI,
so they still do not escape "blame" here...for sure, the _HARDWARE_ can
easily do it...so, if Microsoft's software isn't up to the task, it's not
the hardware to blame, it's them)...requires strict "timing" but, if done
properly, that's all it requires...make sure that you can "fire" the
background and the "overdrawn" text on top of it within the period from the
scanline below the titlebar to the scanline just above it...

If going for "method 2"...well, this isn't at all easy (the other methods
would be preferrable, as this is quite complex :)...

But they could call the API "GetGlyphOutline" for the font for the
titlebar, on each character that makes up the titlebar text (you'd do this
just the once, whenever the titlebar text or font changes and then store
the results, so as not to go through the whole cumbersome process every
time)...through this, they can retrive the TTPOLYGONHEADER and each
TTPOLYCURVE that makes up each character...translating these co-ordinates
into pixels, then they can work out which pixels to draw and which to "mask
off"...then simply render the gradient background _avoiding_ writing to any
of the text pixels...as fonts are "anti-aliased" at the edges, then this is
slightly more involved once more, in that some pixels may be part gradient
and part text _BUT_ these would, indeed, be pixels that change...so these
pixels would be written too...

Also, GDI's performance may simply not be fast enough because it's a slow
and crap API...but, then again, Microsoft also wrote that, so they only
have themselves to blame...and, indeed, there is a case that Microsoft
could write a _dedicated_ "DrawCaption" API (note: This API exists already
:) that works at a low-level - integrated with the TrueType renderer and
the low-level graphics access - to do this all in one, without simply being
"lazy" and using other GDI routines to do it...

They _ARE_ Microsoft, after all...so, unlike us, they _CAN_ alter GDI's
"DrawCaption" to directly work with the TrueType renderer (as this is
inside GDI too...so, it could even perhaps directly access the TrueType
renderer's internal tables for rendering the text itself in order to get
the information to correctly "mask off" those pixels that don't need
"overdraw" ;) in order to do this all-in-one, at a low-level...rather than
be "lazy" and have "DrawCaption" just call other GDI API that produces
crap, amateurish "flicker"...

If going for "method 3", then this is the easiest at the cost of a little
RAM...simply, create an "off-screen" buffer an appropriate size for the
caption, render the entire thing onto this and then copy that to the front
buffer...

It _IS_ possible...certainly so for Microsoft because, for frack's sake,
they could _re-write_ GDI itself to specifically cater for this titlebar
effect, if they wanted to...

The "flicker" is simply a lack of professionalism...they thought "ah, who
cares?" and did a sloppy job of it, to save them the bother of coding it
properly...indeed, the proper way to have done this was to place the
"DrawCaption" API inside GDI itself (in fact, it's a bit of a nonsense -
seeing as its a _graphical_ API - that it's in USER32 instead), that it
could access its pixels, the TrueType renderer and work at a low-level to
specifically cater for their new "special effect" with a low-level routine
in GDI itself...

Come on, Wannabee...it's you with the silly assertion here: That it is
somehow "impossible" for Microsoft - with access to everything - to code
these graphics without "overdraw"...of course it is possible...in the end,
the screen is an array of pixels...it's only a matter of calculating what
colours to make them...and if the TrueType renderer in GDI can work out
which pixel _TO_ draw in rendering text, then you only have to take the
"inverse" of that to know which pixels to avoid when rendering the
"gradient"...

> There so many errors in all your posts here + drivel, that if i wore to
> answer each and everyone, using nothing but this osk.exe, until I have
> bought a new keyb, that would just take to long.

Okay, you want to stick by this "party line"...ah, perhaps I should program
a few more "graphics demos" for you to realise how completely stupid you
are to think I don't know what I'm talking about on these issues...

But, whatever, this has nothing to do with me personally, really, does it?
It's all to do with "worshipping" RosAsm and refusing to hear a single word
against it...and - watch out Rene! - you've become so confused by the
contradiction of "fighting Microsoft" while using Windows (perhaps Rene
himself intends this to be "ReactOS" but it seems you've confused things
and are fighting _FOR_ Windows here..."master Rene", I think your "student"
has not learnt his lessons properly and has wrongly turned into a Microsoft
_DEFENDER_, of all things! Surely, Rene, this is NOT what you'd want your
RosAsm "students" learning from you? Quick, get Wannabee onto the
psychatrist's couch to remove this "mental disease" before it goes too far
and he starts using MASM and hanging around with hutch on the MASM32
forums!! Arrgh!! ;)...that you've become "muddled" into a contradictory
position of defending Microsoft...

First, this will no doubt make Rene have kittens to see one of his
"students" moving towards the "Dark Side of the Force"...

Second, if you want to take up the case of defending Microsoft, be aware
that this is an inherently losing position because Microsoft aren't just
insulted through "jealousy" or their "immoral position"...they also
completely deserve every single insult on _technical_ grounds too...after
all, think about it: If Microsoft were actually any good, then they
wouldn't need to illegally "bribe" manufacturers and dealers and such, yes
(As they were found guilty of in that legal case against them, that this is
neither libel nor conjecture but the ruling of a law court from _evidence_
of a "beyond all reasonable doubt" level)? If Microsoft had nothing to
fear, then why would we see these leaked documents with plans for "FUD
tactics" and "de-commodisation"?

If Microsoft were any good, then the "incident" where Microsoft were found
running _FreeBSD_ on their web servers - they didn't trust their own
products and were using FreeBSD, no doubt, because of its reputation of
placing "security" high on its priority list - that caused them
embarassment (and a quick "change" to Windows servers, as fast as possible
;) would never have happened...

And so on and so forth...Microsoft are NOT where they are because of
technical competence but simply because of "market forces", "good luck" and
good / clever / sneaky (/ sometimes illegal with the "bribery" they were
found guilty of...it would be "speculation", though, of course, to wonder
if this was the only illegal practice they've been engaged in or just the
only one a law court caught them out on ;) business practices to get on top
and then stay on top...

This is why - though I support the attempt to "break monopoly" - ReactOS is
still problematic for me...because my concern isn't only that Microsoft are
a "monopoly" but that Windows is a pile of crap...you know, ReactOS will
still be based on Microsoft technologies...and, for me, this is just as
much a reason for being against Microsoft's "monopoly" as anything
else...their strategies ("monopoly"), their policies ("de-commodisation"),
their technologies and so forth _ARE_ the problem for me..._THAT_ is the
actual "enemy"...if Microsoft were to, instead, go off and make ice creams
(in a non-monopolistic, non-immoral, non-destructive fashion) instead,
then, fine, I don't see any problem with that...let Microsoft go make ice
creams...or, indeed, if Microsoft _let go_ of the "monopoly", stopped
destroying competition, started really making good technology, become
"moral" and "ethical" in their practices and so forth, then I see no reason
why they can't - as one of _equals_ - carry on in the industry...and the
people who work for Microsoft don't deserve to be in poverty, any more than
anyone else...they are just doing their jobs...it's the arseholes at the
top that set "policy" that are the real "enemy" because they go beyond
"food on the table" and actively seek the destruction of others...

Do you see what I mean? There's nothing inherently wrong with being an OS
manufacturer...or an applications manufacturer...or making consoles and
wheel-mice...other companies do these things too...the problem is not that
but the _WAY_ Microsoft do it..."monopoly", "de-commodisation"...using
"monopoly" to foist utter crap onto everyone because there's no alternative
choices in the matter...blah-blah-blah...

And, as such, this is the "issue" with ReactOS...it might break
Microsoft...but then, afterwards, it _BECOMES_ the OS pushing inadequate
and crap Microsoft technology...it reminds me of the saying: "The King is
dead! Long live the King!"...is ReactOS about making the computer industry
better or just "revenge" on Microsoft? Well, personally, I'm not interested
in the "revenge", just the "make things better" aspect...

We'll have to see how things "pan out", though...ReactOS will "evolve" and
may head down its own "path" (if Microsoft get the "trusted computing"
stuff working, then that might be forced upon them)...and, hence, it could
"grow out" of its initial Windows inheritance...I don't know...as I say,
we'll have to see what happens...it's perhaps too early to know what's what
with it...but - though I support everything they are doing in general - the
fact that it'll just be "Microsoft Windows written by someone else" is a
worry from the perspective that "Windows" is as much a woresome word for
me, as "Microsoft" is for creating it...

This is why I'd prefer a _true alternative_, like Linux...and, though, yes,
it might not be "up to scratch" yet, it's "open source" and that can be
worked on and improved...plus, in a sense, perhaps there should be _NO
FIGHT_ between ReactOS and Linux on this...instead, for us to think of it
as a "pincer move"...to battle on two fronts...this defeated the actual
Nazis, after all...to give them too many "enemies" from too many directions
simultaneously to be able to "counter" them all...you know what I mean?
ReactOS can work "from within", while Linux works "from without"...and that
this very fact itself might be the actual thing that could screw Microsoft
up: Too complicated to "counter" many "offensives" on their "monopoly" at
the same time...in a sense, if we "divide" then that just makes it easier
for Microsoft to "conquer" each individually...you know, Aesop's "bundle of
sticks" and everything like that ;)...

> That said, your code is very nice.

You think? I thought it was slightly crap, to be honest...geuninely...not
"modesty" but that I really didn't take the time to do it properly
(delibrately, of course, in this case: It's only to "make a point" and not
actually do anything useful besides that...no sense wasting time doing
anything beyond simply getting it working :)...

As I said to Rene, the "window procedure" was actually ripped out of a HLA
program I'd written before and I just changed the syntax...which is what's
so silly about these "wars": If you can create "DB" data and you've got
access to the "machine instructions" then all assemblers are
identical...the "other crap" that they might offer is great and
helps...but, you know, at this low-level, there's no distinction at all but
for "syntax"...and, to me, I don't see that as any kind of "big
deal"..."you say poe-tay-toe, I say poe-tah-toe", as the song once said
:)...

> > And to get back to the main point: The application is constantly being
> > "unblocked" for every one of these messages...this is how Windows does
> > it...
>
> This seems to me true. Thats why we can use peekmessage as well, when we
> need the full juice.

"PeekMessage"? That makes it _WORSE_, not better...because that's a
"non-blocking API"...

Okay, you must not be getting my point exactly...we _want_ the applications
to be "blocked", when there's nothing specific for them to be doing...

And this is what's "problematic" about the way Windows works...the
application is being regularly "unblocked" for messages that it doesn't
have any useful work to be doing for...by not being "selective" like X,
then it's somewhat "defeating the purpose" of "blocking" because
applications are being "re-awoken" all the time for messages they don't
process and don't care about...

> with X, you could specify that you wanted "mouse messages only" and
> > then it would only bother reporting those...or "keyboard and mouse
> > messages" or just "paint messages"...and so on and so forth...
>
> You _can_ spesify this using a hook.

No, you aren't getting how X works on this, I don't think...this is
different to a "hook"...

Okay, perhaps some better detail on how X works will help you see the
difference...

There's the "XSelectInput" API call:

XSelectInput(display, window, event_mask)

"display" and "window" are just handles to the X server and the window to
identify which window we're setting the "event_mask" for...

The "event_mask" is actually a bitfield...each bit represents a different
"class" of "event" and then you set the bit "on" or "off" to say which
events you do or don't want...this is simplified, of course, with some
equates and "OR"ing them together...

But, for example: "KeyPressMask" (bit 0), which relates to the "event" of
the user pressing a key...or "KeyReleaseMask" (bit 1), which relates to the
"event" of the user releasing a key..."ButtonPressMask" (bit 2), which
relates to mouse button pressing "events"..."ButtonReleaseMask" (bit 3),
which is mouse button release events..."EnterWindowMask" (bit 4), which
relates to the "enter" event, when a mouse "enters" a
window..."LeaveWindowMask" (bit 5), which relates to the "leave" event,
when the mouse pointer "leaves" the window...and so on and so forth...there
are a whole bunch of these "masks" which relate to various "classes" of
"event" that could happen...

So, when you call "XSelectInput(display, Window, EnterWindowMask ||
LeaveWindowMask || ButtonPressMask || ButtonReleaseMask)", this is telling
X that it should only report the events of the mouse pointer entering the
window, leaving the window and any mouse button presses or releases on that
window...

And X _ONLY_ reports these "events" to the application...so, for example,
I've NOT specified "PointerMotionMask" (bit 6), which relates to receiving
"mouse move" events...

Hence, if the mouse moves over this window, then X does NOT generate any
"mouse move" events for that window...if this were Windows, then what I'm
saying is that we don't get any "WM_MOUSEMOVE" messages...and I mean they
don't even exist...X does not generate them at all...they will NEVER be on
the "event queue" at any point...

I'm not talking that the application doesn't process "WM_MOUSEMOVE"
messages, I'm saying that - with this method - "WM_MOUSEMOVE" messages
aren't even reported to the application _AT ALL_...they don't happen...

When you call "XNextEvent" (which is X's verions of "GetMessage"), then it
"blocks"...but if I move the mouse over that window (but haven't specified
"PointerMotionMask" in the window's "event mask" - haven't explicitly asked
for "mouse move" events), then the application _REMAINS_ "blocked"...X does
not place any "PointerMotion" (X's "WM_MOUSEMOVE") onto the queue _AT
ALL_...we're not talking that the application doesn't process them, we're
talking about X _NOT EVEN DELIVERING THEM_ in the first place...

X only delivers the "events" that the application specifies in its "event
mask"...you can be "selective" of what "events" you want X to report to the
application...and those events you don't specify are not even
reported...not put on the queue at all...they just don't happen...X only
reports that which the application says it wants to be reported...

So, for example, I want to create a simple "button"...it has "hot
tracking", so it "highlights" when you move the mouse onto it and
"de-highlights" when the mouse moves off it...and you can "click" on it...

BUT we don't need any "mouse move" messages: It is immaterial where the
mouse is located on the button..."hot tracking" only cares that the mouse
is or isn't over the button, it's exact location is of no use to the
application...and "clicking" also doesn't care where on a button the user
clicks, so long as it's _somewhere_ over its surface...

So, we could specify "EnterWindowMask || LeaveWindowMask || ButtonPressMask
|| ButtonReleaseMask" as the "event mask" for this "button" window...and
this tells X to _ONLY_ report back these specific kinds of "events"...the
"event queue" for this "button" window will NEVER have any "PointerMotion"
(same as "WM_MOUSEMOVE" :) events on it ever...not a single one...the
application will NEVER "unblock" for mouse movement over the window...

_ONLY_ the "Enter", "Leave", "ButtonPress" and "ButtonRelease" events can
ever be on this "button" window's queue...these are the only "events" the
"button" window cares about, it's the only "events" that it asks to be
reported, it's the only events that X puts onto the "queue"...

Do you see the difference now?

There is no "DefWindowProc" with X because you're simply never passed any
"event" that you didn't specifically ask for...

This "event mask" can be specified individually for each window (the "event
mask" is one of the "attributes" that every window has :)...

The application will "block" on "XNextEvent" and it will only "unblock"
when a _USEFUL_ "event" happens...that is, an "event" that the application
has _EXPLICITLY ASKED FOR_...if an "event" - like the mouse moving over the
window - happens and this is NOT an "event" that's in the window's "event
mask", X does not even report it...X does not even put any "event" onto the
queue for this...the application _STAYS_ "blocked" until one of the actual
"events" it specifically asked for happens...

Comprehend: Microsoft did NOT invent the GUI...they turned up "late"...and
then didn't implement it properly...the first version of Windows couldn't
"overlap" windows...they did not implement a proper "desktop" (where you
could place icons onto the desktop surface itself) until Windows
95...Microsoft are _FOLLOWING_ everyone else...they are _BEHIND_ everyone
else...they turned up _LATE_...and when they do "catch up", they tend to do
so with an _inferior_ implementation...

This might come as a "shock" to some people who've been living inside
Microsoft's "propoganda bubble", inside which Microsoft are responsible for
all "good" in the entire universe...it might be a "shock" to see that
something else could actually have a better implementation than
Microsoft...

But, well, prepare for the "shock of the new"...because that is _exactly_
what's going on...Microsoft are making everyone "live a lie" every day that
they are somehow "superior"...absolutely not true...Microsoft are where
they are because of "good fortune" to be in the right place at the right
time at the birth of the PC...and for _BUSINESS STRATEGY_ ever since, to
keep them on top (falsely, it could be said) ever since...they NEVER got
where they are for being "better"...on the contrary, it's taken all their
"underhand business practices" of "bundling" and "bribing" and
"record-breaking marketing campaigns" to _HIDE_ the fact that they are
hoodwinking the world...

Some may find this incredible to believe...to find the "god" that's been
worshipped all this time is nothing but a statue, which never had any
"powers"...the reaction _IS_, indeed, to believe it cannot be true...this,
though, in no way makes it untrue...

> > As for the second program to demonstrate how X does it? Well, yeah,
> > maybe...if the nonsense persists...but I want a rest now...RosAsm is a
> > lot
>
> Please do. This will be a great value. The "nonsense" I can assure you,
> will continue until we have debunked your every halftruth, as soon as I
am
> up to speed on a new keyb.

If you wish to waste your time, then please continue...there is nothing to
be "debunked"...simply because you do not want to believe the truth,
doesn't make it any less true...just makes you more of an idiot for still
failing to see with your own eyes, allowing people like Annie and Rene -
with their clear "political" motivations - to define your every thought,
halfling...

Although, the program I've already posted - with suitable modifications -
can already be used to demonstrate this:

--------------------------------------

; Example2a.asm
;
; assemble:
; nasm -f elf -o example2a.o example2a.asm
;
; link:
; ld -s -o example2a
example2a.o -L/usr/X11R6/lib -lX11 -I/lib/ld-linux.so.2
;
; run:
; ./example2a
;
; handy constants
;
NULL equ 0

; make entry-point "global" so linker can see it
;
global _start

; Xlib API functions
; (Xlib is a C library for programming X)
;
extern XOpenDisplay
extern XDisplayName
extern XCloseDisplay
extern XDefaultRootWindow
extern XCreateSimpleWindow
extern XDestroyWindow
extern XSelectInput
extern XMapWindow
extern XNextEvent

; First few "event mask" values:
;
%define KeyPressMask 1
%define KeyReleaseMask 2
%define ButtonPressMask 4
%define ButtonReleaseMask 8
%define EnterWindowMask 16
%define LeaveWindowMask 32
%define PointerMotionMask 64

%define KeyPress 2

; data section
;
section .data

StringMessage db 0Ah, "Message received!"
StringOpenFailed db 0Ah, "Error: Cannot open display!"
Display dd 0
Window dd 0
event times 24 dd 0

; code section
;
section .text
_start:
push byte NULL
call XOpenDisplay
add esp, 4

cmp eax, byte NULL
je near OpenFailed

mov [ Display ], eax

push byte 0
push byte 0
push byte 0
push 300
push 400
push byte 50
push byte 50

push dword [ Display ]
call XDefaultRootWindow
add esp, 4
push eax

push dword [ Display ]
call XCreateSimpleWindow
add esp, 36

cmp eax, byte NULL
je near CreateFailed

mov [ Window ], eax

push KeyPressMask ; <-- changes made here
push dword [ Window ]
push dword [ Display ]
call XSelectInput
add esp, 12

push dword [ Window ]
push dword [ Display ]
call XMapWindow
add esp, 8

MessageLoop:
push event
push dword [ Display ]
call XNextEvent
add esp, 8

mov eax, 4
mov ebx, 1
mov ecx, StringMessage
mov edx, 18
int 80h

cmp dword [ event ], KeyPress
jne MessageLoop

push dword [ Window ]
push dword [ Display ]
call XDestroyWindow
add esp, 8
CreateFailed:
push dword [ Display ]
call XCloseDisplay
add esp, 4

jmp Terminate

OpenFailed:
mov eax, 4
mov ebx, 1
mov ecx, StringOpenFailed
mov edx, 27
int 80h

Terminate:
; exit program
;
mov eax, 1 ; function (sys_exit)
xor ebx, ebx ; exit code
int 80h ; make Linux system call

--------------------------------------

Right, assemble the program per instructions in comments...then open a
"console" window (as that's where the output will appear) and run it from
there with "./example2a"...

The simple change I've made to the program is that it prints "Message
received!" to the console window you run the program from, whenever
"XNextEvent" unblocks on _ANY_ kind of "event" being received...

Run the program and the window will appear...move over it, enter / leave
the window area, click on it...absolutely nothing in the console
window...press a key (the _ONLY_ event it is programmed to receive) and
_ONE_ "message received!" string will appear in the console...the
application told X that it only wanted a "KeyPress" event (with
"KeyPressMask" as its "event mask") and this is the _SOLE_ "event" that X
has reported to the application...

Okay, time to make some changes at the line with the "; <-- changes made
here" comment on the right side...it says "push KeyPressMask"...let's
change that to:

push KeyPressMask + EnterWindowMask + LeaveWindowMask

....then re-assemble, re-link and go back to the console (type "clear" first
to get a clear console window, just to keep things "tidy" :)...

This time, we've specified that we also want "enter" / "leave" events, as
well as the "KeyPress" (which is the only event actually processed, just to
end the application properly :)...

If we run the program with our new "event mask", you'll see that you get a
"Message received!" output in the console window, whenever the mouse moves
into or out of the window...but moving the mouse over the window produces
no output and neither does clicking...

Let us change the "event mask" again (same line needs alteration):

push KeyPressMask + PointerMotionMask

....then, again, re-assemble, re-link, type "clear" to get a new console
window (important this time: We'll get a lot more output ;)...then type
"./example2a" to run it from the console...

This time, we'll be getting "PointerMotion" events whenever the mouse moves
over the window - equivalent to WM_MOUSEMOVE on Windows - in a stream...

Again, change that line once more:

push KeyPressMask + ButtonPressMask + ButtonReleaseMask

....and re-assemble, re-link and what-not all over again...this time you'll
see that it only reports output when you press or release a mouse button
(and, of course, the "KeyPress" event, which is always there as a means to
exit the program properly)...

There, as you can see for yourself, X is only reporting (and, thus, only
"unblocking" the application on) the _specific_ "events" that you specify
to "XSelectInput"...we are not getting reports of other "events" (which
also means the application is not "unblocking" at all either) because the
application has not specified that it wants them...

[ Oh, minor note: If you end the program with the "close" button on the
window rather than pressing a key, then you'll see some "connection
explicitly killed" or some such error message appear...again, this is a
consequence of the program being "quick and dirty"...a real X program would
deal with the "close" button properly...my program here doesn't...and, as a
consequence, the server closes the "connection" from its end (but the
application is still in the "message loop")...

This is "detected", though, and the program "stuck" in the message loop is
"killed" (risking you freaking out again by mentioning: Something Windows
does NOT do and it would leave a windowless program "stuck" forever in its
message loop to sit there forever...you can prove this to yourself simply
by removing the call "PostQuitMessage" from a simple Windows program and
then closing it...then hit Alt + Ctrl + Del and look at the process list:
There's your program sitting there, doing nothing..."stuck" in a message
loop to receive messages for a non-existent window! X, on the other hand,
"detects" this buggy application that fails to shutdown properly and prints
up that "connection explicitly killed" error message and then sends a
"kill" to that application to stop it pointlessly wasting RAM...if you
don't believe that one - Geez Louise, you're annoying recently - then feel
free to assure yourself of this by typing "ps -A" (which lists all running
processes) and noting that "example2a" does not appear in the process list
because it's been killed automatically)...it would be a potential "memory
leak", of a kind, if the process were simply to sit there forever in a
"message loop" it would never exit...so, X has a means to "detect" this
situation and automatically "kill" processes "stuck" in that
situation...while - and feel free to try it out in Windows yourself -
Windows just leaves those processes there...forever...doing
nothing...wasting RAM...

Anyway...so, don't be alarmed by the error message...it is a consequence of
the program being "quick and dirty"...it only bothers to look for a
"KeyPress" event to end itself...so, if you use the "close" button instead,
then my program isn't properly written to look for this too and deal with
it properly...it then would get "stuck" in the "message loop" forever but X
has a means to "detect" this accidental situation and forces a "kill" on
the process and prints an error message to explain that it was forced to
"kill" the process, just so you realise that the application itself didn't
shut itself down properly, but that X had to force a "kill" because it had
got itself "stuck" in an "event loop"...see? X doesn't just offer extra
features like the "event mask", it's got a more "intelligent" way of
dealing with things to avoid "frozen processes" and such...

Anyway, if you end the program properly with a key press then this error
will not result...and though the "close" button creates this situation and
the error message, it's not a "disaster" either because of X's more
intelligent "error recovery" (it can "detect" that the program has got
itself "stuck" and, thus, forces the connection to close from its end of
things and reports an error message explaining that it had to do this,
which is useful for spotting that your program has a "bug" like this in it
:)...BUT I thought I'd explain just why the error message appears...use the
"KeyPress" to end it, though, and this shouldn't happen...as I say, a
"real" X program would deal with also recognising the "close" button as
another legitimate way to end the program and closes itself properly...this
program is "quick and dirty" so it just doesn't bother :)... ]

> > of hard work to use because I find the editor a little "non-standard"
and
> > "awkward" (before Rene freaks out: _I_ find it that way...others who
are
> > used to it don't...I perfectly understand that...given more time, I'd
> > probably get used to it all too and then wouldn't have any problems, I
> > fully understand and respect...but, until then, it's awkward _for me_,
> > so I
> > don't feel like writing any more code after using that editor
> > tonight...it's exhausted me! :)...
>
> Of course, you are very new to programming,

New? Around 20 fracking years, more like it!

> and to use your brain,

....says he who's repeatedly demonstrated throughout this thread and
everywhere else that he has no brain to use, even if he wanted to use
one...

[ No, no...getting Rene to do all your thinking for you doesn't count ;) ]

> so its only natural that you are felling exhausted.

Truth is, I was exhausted by your rentless tirade of ignorance...having to
deal with a whinging child who had no idea what the heck they are talking
about is exceedingly exhausting...

"Waaah! Waaah! You're wrong! Waaah! Waah! Microsoft are perfect and I Love
them! Waah! Waaah!"

Oh, please, someone...stick a fracking dummy (US: pacifier) into his mouth
or something...and he's _STILL_ fracking doing it right now, as
well..."Waaah! Waah!"...

I am NOT accountable to you, arsehole...as I've demonstrated clearly with
actual examples, what I was saying was _ENTIRELY CORRECT_...if you're just
too much of a whinging, annoying little brat, then my patience will be
exhausted very soon...and, by the way, take that deadly seriously...it's no
idle threat...I really, really, really am seriously fucked off by your
behaviour in this thread, which genuinely has exhausted me...jokes
aside...persist and I will simply drop you into the "ignore
file"...possibly _PERMANENTLY_...understood? And, note, you've _HAD_ your
second chance already...don't test if I'll give a third because I won't...

In short: An apology and proper behaviour from now on...or, simply, I ain't
_ever_ replying to your arse ever again...don't test my seriousness on
this, by making silly jokes or stupid comments or I will take that in
itself as sufficient reason to "plonk" you right to the bottom of the
"ignore file"...

Remember, I "owe" you absolutely NOTHING and I have ZERO accountability to
you in any regard...if you piss me off that one step too far and I won't
hesitate to ignore your arse forever more...because, you see, _YOU_ gain by
me talking to you...at the moment, I'm gaining _ZILCH_ talking to you...so,
I lose absolutely NOTHING by never talking to you ever again in my entire
life...be under no illusions: THAT is the situation...it takes a lot to get
me really pissed off but, when you do, comprehend that I am utterly
merciless at that point...because if after giving many opportunities to
someone to stop with the "arsehole" act and they still persist, it's got to
be _delibrate_...and, hence, you're asking for it and your fully compos
mentis in what you're doing...zero "guilt" on my end of things...I gave
full chance and you wouldn't take it...fine, you made the bed, you sleep in
it...

> But very good work here. Keep
> it up, and I promise you you will one day understand why your attack on
> the decent works, are so wrong.

You stupid ****...keep that up and I promise you that I'll roast your
arse...

> > Why did I use RosAsm? Plus, it'll piss them off, that I used RosAsm for
> > the example code ;)...
>
> If this isnt the truth, straight from the horses mouth....

Yeah...exactly right, little munchkin...that's why I said it...

Nothing for me to be ashamed of there...you and Rene have spent _YEARS_
pissing off an entire newsgroup full of people...you've got off very
lightly indeed...

Beth :)


.