Alex Ionescu wrote:
On 2009-12-11, at 10:10 AM, Love Nystrom wrote:
lex Ionescu wrote:
There is a reason this set and names was chosen,
please don't change them. It is for SDK compatibility.
see mostly additions
that reflect Intel flag identifiers.. ergo, no major panic.
I created the NDK -- who are you to comment on whether or not I should panic?
These changes are wrong.
You created the NDK.. Oh whoopie doo!
I just LOOVE these self-inflated attitudes.. They are SOOOO appropriate
in a OSS project. ;-)
-"I'm Mr such and such.. Who are You to even have an opnion?"
None of the
EFLAGS_xx show up in my public MS headers, which must mean
that they are inofficial identifiers only known to priviledged devs.
Tell me, did you download ALL the Microsoft headers? ALL of them? Do you even
know where to get them all? Do you have, for example, the WMP 11 SDK? Or the ADAM SDK?
Enlighten me !
Precisely where are the EFLAGS_xx defined in public MS headers ?
In what package, and which file, because I would just LOVE to get it !
It would be most useful for my (non-ROS) projects.
Why would ReactOS developers be using
"inofficial" headers? What's a "privileged" developer?
Your ignorance in this regard surprise me!
A privileged dev is one who is privvy to the source of Microsoft Windows.
And to enlighten You, there is a tangible possibility that someone who
submits
patches to the project could in fact be tainted without ROS leaders
knowledge.
Nobody who was tainted would be so stupid as to use MS privileged
headers or source
verbatim, but code from such headers or source could leak in to the
project sideways
by simple rewrites.
I just LOVE the "I can't find these
definitions in some arbitrary set of headers I somehow obtained, so they must not
exist" argument.
I didn't say the don't exist, I said they don't seem to exist in
PUBLIC
resources.
> Ergo, we may define them to correctly reflect the
EFLAGS register.
>
Meaning, any EFLAGS_xx definitions that don't correctly reflect
the bits in the EFLAGS register are NUTS, no matter who made them.
Who is "WE"? You're not even a DEV for
this project!
You suprise me again.. What could WE possibly be but a reference to the
whole project.
May I remind You this is an OSS project, and ANYONE who wants to,
can work with the code ... Publicly or otherwise.
Are You really so naive that You think everything that happens
with this code base becomes public in the source tree ?
Your attitude is an incentive for "independent" devs to NOT submit thier
code to the project.
The humbling fact is, there will always be someone who's brighter than You,
no matter how bright You are. (And I don't mean myself, since I've
accepted the fact).
Stop thinking You're the best programmer in the world.
EFLAG_SIGN and
EFLAG_ZERO are used to compare flags in AH after LAHF,
and should be retained verbatim, since they are public (in NTDDK.H).
Then shut up
and don't post completely USELESS and wrong information.
Wrong ??
EFLAG_SIGN and EFLAG_ZERO are defined in NTDDK.H
and are accompanied by a most telling comment..
I quote <ddk>\inc\ddk\wxp\ntddk.h, Lines 6747-6755:
// Flags loaded into AH by LAHF instruction
#define EFLAG_SIGN 0x8000
#define EFLAG_ZERO 0x4000
#define EFLAG_SELECT (EFLAG_SIGN | EFLAG_ZERO)
#define RESULT_NEGATIVE ((EFLAG_SIGN & ~EFLAG_ZERO) & EFLAG_SELECT)
#define RESULT_ZERO ((~EFLAG_SIGN & EFLAG_ZERO) & EFLAG_SELECT)
#define RESULT_POSITIVE ((~EFLAG_SIGN & ~EFLAG_ZERO) & EFLAG_SELECT)
Meaning they are used to mask a var holding content of AX reg
after an LAHF instruction followed by a MOV tmpAX,AX.
Shape up man!
Best Regards // L
/"Being paranoid does not mean the world is not out to get you" / Unknown
author
/