Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: "Beth" <BethStone21@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Mar 2005 12:35:45 GMT
Brad "Wannabee" Pok wrote:
> Frankie say:
> >> > Comment out the call to the "default" message handling, and
> >> > see how your app runs. X *has* no default process.
>
> Frank, I did this, and posted about it about a year ago. It ran fine for
> most situations. At that time I felt two lazy to test out what wore the
> exact messages that had to be passed on, but it is fully possible. In my
> app, all messages that are handled by me, is ended right there. I just
> checked for < http://szmyggenpv.com/downloads/MMEXBlue.Zip >. If i
replace
> the call with "mov eax &true" It run fine fine. Just a few exceptions.
Then this application will fall over whenever Windows changes its default
processing...
....and you contradict yourself anyway: "It ran fine FOR MOST
SITUATIONS"...then that is not "all", is it? There are some "messages" that
must be delivered to "DefWindowProc", yes? Well, you confirm this with
"what wore [sic] the exact messages that had to be passed on"...
Right, read Frank's statement again:
"X *has* no default process."
Are you comprehending things yet? You're trying - in a thoroughly "future
expansion incompatible" way - to locate a "path" through the messages you
must send and those you mustn't to get away with as little "default
processing" as possible...
With X, that's achieved every single time...no need to play games, trying
to work out which "messages" you can and can't send (which is "version
specific" and, thus, will make your program fall over, should Microsoft
implement any major "user interface" changes...and Microsoft _LIKE_ to
implement "user interface changes", so you play with fire)...as Frank says:
"X *has* no default process"...you never send any events onto some
"DefWindowProc" for "default processing"...
Indeed, thank you, though, for exposing the inherent _FLAW_ in Microsoft's
design here...for correct operation, it depends on the application passing
on the messages...if it does not, then the application cannot be relied
upon to fit into the "user interface style"...
And this has ramifications elsewhere:
When an application is too busy to inspect its "message queue", the window
becomes "suspended" and "unpainted"...meaning that a window in this state
cannot be moved or resized...that's a pretty major design flaw, right
there...if a program becomes "busy" or goes AWOL to not return to its
"message queue" then it becomes "stuck" in the middle of the screen...
Oh, I know, I know...you run XP...and you're going to say "but this doesn't
happen here with XP"...yes, it does...but Microsoft - shamed by their crap
design - have introduced an "optical illusion" for XP (prior to XP,
Windows - such as Win98 - will operate as mentioned above and the window
will become "stuck", the user unable to grab the titlebar and move it out
the way or resize it)...
>From the Microsoft XP Platform SDK:
"Windows XP: If a top-level window stops responding to messages for more
than several seconds, the system considers the window to be hung. In this
case, the system hides the window and replaces it with a ghost window that
has the same Z order, location, size, and visual attributes. This allows
the user to move it, resize it, or even close the application. However,
these are the only actions available because the application is actually
hung. When in the debugger mode, the system does not generate a ghost
window."
Yeah, Microsoft realised that their "model" was _POOR_ that it didn't allow
windows to be moved or resized or closed while "too busy" (or possibly
"hung")...so, they introduced this "cheat" with XP - using a "ghost window"
that _PRETENDS_ to be the application window in appearance but is actually
a completely different window "masquerading" as the application window, in
order to make it look like XP doesn't have this _FLAWED MODEL_ that depends
on applications to be responsive before even basic move, resize or close
operations are possible - to "cover over" the fact that this isn't just
about "redundent messages"...thank you for making this point and reminding
me that Windows choice of method here is also _INHERENTLY FLAWED_ because
it depends on application "responsiveness" before even basic operations are
possible...
There is no need to "cheat" with "ghost windows" in X...it simply does it
_properly_ in the first place, to have no need of such "terrible illusions"
and "visual trickery" to fool the user into thinking it uses a better
windowing model than it actually does...
Yeah, this kind of thing is probably why Windows feels "unsafe",
Wannabee...instead of using a proper "windowing model", Microsoft choose
instead to "dupe" you into thinking you've got one by using "optical
illusions" and "ghost windows"...they are always concerned with "saving
face" more than actually doing things properly...hence, yes, this attitude
could be a little "unsafe"...you know, if it's discovered that Windows has
a massive security flaw, then Microsoft might just "pretend" it isn't
there, so they look good and "save face", rather than actually admitting
it's there and getting to fixing it...put some "ghost window" to patch over
it...to hide the "ugliness" underneath...yeah, that has a lot of potential
to generate "unsafe" behaviour...when you know they'll prioritise their own
egoes and "saving face" - also, no doubt, because so long as _no-one knows_
it's got flaws and problems, then this won't effect "sales" and "profits",
which is all that matters to Microsoft - over doing things properly...very
"unsafe" indeed...your intuition is sharp to pick this up because Microsoft
do everything they can to "hide" these behind "ghost windows" and other
"optical illusions"...
Sorry, but we weren't just saying it to annoy Rene, without meaning
it...Rene _HAS_ picked the entirely wrong OS for RosAsm
"ethical-ness"...you are dancing with the devil that you claim to be
fighting...you are knee-deep in their "terrible illusions"...and, by
sighting RosAsm on Win32, Rene has - as was warned would happened - now
started generating "Microsoft defenders and apologists"...students who will
defend their beloved Microsoft at all costs...who tell everyone how
"excellent" Windows is...who are _PROMOTING_ the "enemy", even against the
truth and all logic to the contrary...
I mean, just stop and look what Rene's made you do...you're _defending_
Microsoft...you're defending them when they clearly are in the wrong,
even...fighting tooth and claw to defend your "Monsanto Nazi" pals, eh?
Indeed, he so brilliantly "duped" you into defending Microsoft and Windows
tooth and claw, even against the truth that it's crap, so well...that,
well, are Microsoft paying Rene to do this? Because he's the very best
"recruiting agent"...without even realising it, he's managed to "dupe" you
into defending the "enemy"...helping "Monsanto Nazis" fulfill their
plans...
Just stop for a second and realise that just because Rene _says_ he's
"anti-Microsoft" means absolutely nothing unless his _ACTIONS_ match his
words...and his _actions_ have been quite the opposite to create tools
specifically for Microsoft technologies, to promote Microsoft methods and
Microsoft products...
As Annie would say, Rene "talks the talk"...but he doesn't "walk the
walk"...in fact, Rene's "walk" is often completely opposite to his "talk":
"Come with me to an anti-Microsoft Utopia", he says...but then introduces
Microsoft technologies, has you defending Microsoft from all criticisms
and, as you act as Rene's "lapdog", you're now acting as Microsoft's
"lapdog" through him...now you know how Tony Blair probably feels, as
Bush's "poodle"...
Beth :)
.
- Follow-Ups:
- References:
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: Frank Kotler
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- From: BradPok
- Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Prev by Date: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by Date: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Previous by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Next by thread: Re: Linux, X, ld, gcc, linking, shared libraries and stuff
- Index(es):
Relevant Pages
|
|
