Re: Why RosAsm Breaks on a large number of symbols

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/12/04 

Date: Mon, 12 Jul 2004 03:22:36 GMT

Randy wrote:
> The Wannabee wrote:
> > Who gives a shit. Those waitstates takes a scarce few splits
of a seconds,
> > but the GetMessage might never return. Its unpredectable
when it returns.
> > its a totally diffrent thing. Stuff you old useless
pedantery up your ars.
>
> What on earth makes you think that?
> I've used lots of hardware where the CPU is put on hold
indefinitely
> until the hardware releases the hold line.

No, sorry, it _IS_ a totally different thing...this is because
the "hold line" may be held indefinitely but it is released at
some point...you're absolutely right that the length of time is
immaterial...the fundamental difference with "GetMessage",
though, is that it may NEVER return (theoretically, at
least...in practice, you'll shutdown your machine at some point
;)...this isn't a case of "inserting wait states" but a case of
_total surrender_...

> Just because in your limited experience you've never seen this
doesn't
> mean it doesn't happen. That's all I'm trying to point out
here.

Ah, but this is not about "experience", it's about
_design_...that is, "GetMessage" is _BLOCKING_...in a blocked
state, a thread is not given any CPU time whatsoever...and the
"block" is based on a particular event...

This "blocking / unblocking" scheme _IS_ a form of "asynchronous
notification"...implicitly, if you like, but it's still an
asynchronous notification...

> And just to be technical about it, the Windows message loop
*does*
> returns lots of uninteresting information to an application
(that it must
> pass on), hence your characterization that GetMessage only
returns with
> valid data for the application to use isn't entirely correct
either. Many
> messages get ignored or thrown out until the message
processing loop
> finds one that it wants. A very classic example of polling.

Ah, ah...and here we see the failing of the terminology to
capture things properly...

Let's get this sorted out properly...we're NOT talking about "a
particular message", we're talking about _ANY_ message...and
here's where we see the terminology fall down in capturing the
essence of this properly...

Bizarrely, it _IS_ "polling" when you're waiting for a
_particular_ message...but it is NOT "polling" when you're
waiting for _ANY_ message (yes, including the NOP of "WM_NULL"
and so forth too ;)...

And this is actually the _FLAW_ in the design of Windows and
most GUIs that I've been talking about before...the _WHOLE
THING_ should be "asynchronous notification" throughout...it's a
total waste of time sending "uninteresting information" that is
ignored or simply sent back "return to sender" with "default
processing"...an application should actually be capable of
_specifying_ exactly what messages are "interesting" and which
aren't...but that is, indeed, another topic...

Thus, the "GetMessage" message loop is NOT a "polling" loop is
correct from the characterisation that this loop is NOT about
retrieving a particular message, it's about retrieving _ANY_
message...

Mind you, this is further confused because "GetMessage" takes
"filter" parameters...so, even in the case of wanting a
particular message, it's still capable of NOT being "polling"
whatsoever...

For example, I solely want keyboard input messages and call
"GetMessage" with the "filter" set to only return on keyboard
messages...any other "uninteresting information" is not returned
and doesn't cause the application to unblock until these
particular messages show up...

Indeed, I have to concur with Wannabee that taking this
particular definition of "polling" is distinctly unhelpful -
albeit useless - because we've got a bizarre situation that it
is or isn't "polling" depending on how you look at it...if you
want _ANY_ message, it's not "polling"...if you want a
particular one, it is "polling"...UNLESS you use a "filter" on
"GetMessage" to only return on that particular message, in which
case, it's not "polling" once more...

If the terminology here is so fickle and fragile as this in
describing the situation then is the terminology useful at all?
On that point, Wannabee has struck a chord...with ill-fitting
terminology like this, who needs enemies?

Indeed, perhaps a fundamental problem with the term "polling" is
that it originates from a single-threaded perspective of the
system...

Anyway, "GetMessage" is implicitly "asychronous
notification"...consider the act of simply moving the mouse...

An application starts and then enters its "message loop"...it
hits "GetMessage"...

At this point, the scheduler moves the application from the
"active" list - which gets scheduled CPU time pre-emptively -
onto the "blocked list"...threads on the "blocked list" are not
scheduled CPU time...rather, they are "blocked" on a particular
condition...in this case, the condition is being sent a message
_from an external source_...

The user moves the mouse...this generates an _INTERRUPT_...the
mouse device driver catches this interrupt...this information is
propogated upwards inside Windows until it determines that the
mouse has moved over the application's window...it, therefore,
has a "message" to provide the application about this
_INTERRUPT_...this _asynchronous event_...it compiles the
message and delivers it...the blocking condition is now
satisified and the application is unblocked...

"GetMessage" returns a MSG structure with WM_MOUSEMOVE and the
appropriate parameters in wParam and lParam about the nature of
the mouse movement...the application deals with this message by
"dispatching" it to its "window procedure"...code is executed to
respond to this "event"...we return to the "message loop" and
hit "GetMessage" once more...the application is, again, returned
to the "blocked list", dependent on the condition that it
receives another message...

Despite all the complication of it being propogated around
Windows, the application _IS_ waiting on an interrupt
here...ultimately, in fact, all the messages come from
interrupts...though it can, indeed, be so complexly "indirect"
at times that this is not entirely obvious at first...for instan
ce, looking at WM_SETTINGSCHANGE, this appears to be not related
to any hardware at all...but, indirectly, every message
ultimately is...that is, it's part of a "chain" of messages and
events that originate from the user moving the mouse or pressing
keys - things that are run on interrupts - in a dialogue box,
which triggers a series of messages in a "chain reaction"...or
perhaps it comes from a timer interrupt...

This is actually what I was talking about before when I said
that the lack of some "vertical blank" / "scanline" video-based
interrupt on the PC in general is actually an oversight that
makes a "perfect" asynchronous system impossible...

As I was saying before, GUIs are, in fact, wrongly designed in
this regard...too much "excitement" in moving from a sequential
concept to an event-driven one that it's typically
over-specified in most cases...all that's required is API to
deal with _asking_ for particular event notifications and then a
means to pull off these events from a "queue"...

Anyway, Randy, you should look into how X operates...seeing a
different GUI in action prevents "Windowsisms" from being
confused for more generalised concepts...I'm working on some
HTML documentation for X with regard to LuxAsm...but, of course,
HLA is also a Linux capable assembler so with an appropriate
".hhf" file and such documentation (and having the "-w" option
also work under Linux to say "please link to the X libraries",
as the Linux equivalent of the currently "Windows only" option
to specify GUI or console ;) then you could compliment your
"Windows programming in assembly" with a "X Windows programming
in assembly" alternative for Linux / X...then, as I was
suggesting a long time back, the concept of extending the
"standard library" to also provide "portability" for GUI
applications becomes a reality...an impressive reality when you
consider that not even C / C++ can guarantee "portability" at
this level (about only Java bothers, "out of the box", to even
attempt this level)...and all from assembly language...and by
basing it on individual Windows GUI support and X GUI support
means that you get a whole range of possibilities: Writing
Windows specific code, writing X specific code or writing
"portable" code that employs GUI capabilities in the "standard
library"...

Beth :)

Relevant Pages

  • Re: Why RosAsm Breaks on a large number of symbols
    ... polling loop. ... Polling simply means that while the ... "GetMessage" accurately: ... all...it is requesting an _asynchronous notification_ when data ...
    (alt.lang.asm)
  • Re: Polling, Interrupts, DMA, Synchronous, Asynchronous I/O Definitions
    ... > and against it being polling, so I'm not going to comment on that; ... GetMessage loop because, quite frankly, I'm not that interested in ... If the only other things in the queue ... If I understand how WaitForSingleObject works, ...
    (alt.lang.asm)
  • Re: The basics of Windows messages
    ... But deeep inside the call to GetMessage(), if there is no message to be ... then the calling thread will wait. ... it will saturate the CPU onlty until the thread's quantum is up. ... if there is no other more pressing thing for Windows to deal with, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: f0dders Fabulous Wait States.
    ... > f0dder wrote: ... This means not polling for a message, ... the GetMessage loop might *actually* be ... No sense, for example, having the WndProc ...
    (alt.lang.asm)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >>>incoming windows messages. ... >>juju that calls GetMessage until such time as your application does. ... user's desktop without either being the user, or having the privilege to ... privilege escalation attacks are so devastating. ...
    (comp.security.misc)