Re: [ros-dev] [ros-diffs] [tkreuzer] 44508: updates EFLAGS definitions

[Alex Ionescu]

There is a reason this set and names was chosen, please don't change them. It is for
SDK compatibility.

On 2009-12-10, at 3:22 PM, tkreuzer(a)svn.reactos.org wrote:

>   Author: tkreuzer
>  Date: Thu Dec 10 02:44:42 2009
>  New Revision: 44508
>  
>  URL: http://svn.reactos.org/svn/reactos?rev=44508&view=rev
>  Log:
>  updates EFLAGS definitions
>  
>  Modified:
>     branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
>  
>  Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
>  URL:
> http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu…
>  ==============================================================================
>  --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1]
> (original)
>  +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1] Thu Dec
> 10 02:44:42 2009
>  @@ -82,19 +82,24 @@
>  //
>  // EFlags
>  //
>  -#define EFLAGS_CF               0x01L
>  -#define EFLAGS_ZF               0x40L
>  -#define EFLAGS_TF               0x100L
>  -#define EFLAGS_INTERRUPT_MASK   0x200L
>  -#define EFLAGS_DF               0x400L
>  -#define EFLAGS_NESTED_TASK      0x4000L
>  -#define EFLAGS_V86_MASK         0x20000
>  +#define EFLAGS_CF               0x01
>  +#define EFLAGS_PF               0x04
>  +#define EFLAGS_AF               0x10
>  +#define EFLAGS_ZF               0x40
>  +#define EFLAGS_SF               0x80
>  +#define EFLAGS_TF               0x100
>  +#define EFLAGS_INTERRUPT_MASK   0x200
>  +#define EFLAGS_DF               0x400
>  +#define EFLAGS_OF               0x800
>  +#define EFLAGS_IOPL_MASK        0x3000
>  +#define EFLAGS_NESTED_TASK      0x4000
>  +#define EFLAGS_RF               0x10000
>  +#define EFLAGS_VM               0x20000
>  #define EFLAGS_ALIGN_CHECK      0x40000
>  #define EFLAGS_VIF              0x80000
>  #define EFLAGS_VIP              0x100000
>  +#define EFLAGS_ID               0x200000
>  #define EFLAGS_USER_SANITIZE    0x3F4DD7
>  -#define EFLAG_SIGN              0x8000
>  -#define EFLAG_ZERO              0x4000
>  
>  //
>  // IPI Types
>  
>   
Best regards,
Alex Ionescu

[Love Nystrom]

Alex Ionescu wrote:
>   There is a reason this set and names was chosen,
> please don't change them. It is for SDK compatibility.
>     
I see mostly additions that reflect Intel flag identifiers.. ergo, no 
major panic.
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.
Ergo, we may define them to correctly reflect the EFLAGS register.

However, but I think Alex is right that the compatible identifiers 
should be retained.
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).
As for any MS EFLAGS_xx definitions, I'm not privvy and can't say.

Best Regards // L

>   On 2009-12-10, at 3:22 PM, tkreuzer(a)svn.reactos.org
> wrote:
> >   Author: tkreuzer
> >  Date: Thu Dec 10 02:44:42 2009
> >  New Revision: 44508
> >
> >  URL: http://svn.reactos.org/svn/reactos?rev=44508&view=rev
> >  Log:
> >  updates EFLAGS definitions
> >
> >  Modified:
> >     branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
> >
> >  Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
> >  URL:
> > http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu…
> >  ==============================================================================
> >  --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1]
> > (original)
> >  +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1] Thu Dec
> > 10 02:44:42 2009
> >  @@ -82,19 +82,24 @@
> >  //
> >  // EFlags
> >  //
> >  -#define EFLAGS_CF               0x01L
> >  -#define EFLAGS_ZF               0x40L
> >  -#define EFLAGS_TF               0x100L
> >  -#define EFLAGS_INTERRUPT_MASK   0x200L
> >  -#define EFLAGS_DF               0x400L
> >  -#define EFLAGS_NESTED_TASK      0x4000L
> >  -#define EFLAGS_V86_MASK         0x20000
> >  +#define EFLAGS_CF               0x01
> >  +#define EFLAGS_PF               0x04
> >  +#define EFLAGS_AF               0x10
> >  +#define EFLAGS_ZF               0x40
> >  +#define EFLAGS_SF               0x80
> >  +#define EFLAGS_TF               0x100
> >  +#define EFLAGS_INTERRUPT_MASK   0x200
> >  +#define EFLAGS_DF               0x400
> >  +#define EFLAGS_OF               0x800
> >  +#define EFLAGS_IOPL_MASK        0x3000
> >  +#define EFLAGS_NESTED_TASK      0x4000
> >  +#define EFLAGS_RF               0x10000
> >  +#define EFLAGS_VM               0x20000
> >  #define EFLAGS_ALIGN_CHECK      0x40000
> >  #define EFLAGS_VIF              0x80000
> >  #define EFLAGS_VIP              0x100000
> >  +#define EFLAGS_ID               0x200000
> >  #define EFLAGS_USER_SANITIZE    0x3F4DD7
> >  -#define EFLAG_SIGN              0x8000
> >  -#define EFLAG_ZERO              0x4000
> >
> >  //
> >  // IPI Types 
>  Best regards,
>  Alex Ionescu

[Alex Ionescu]

On 2009-12-11, at 10:10 AM, Love Nystrom wrote:

>   Alex Ionescu wrote:
> >   There is a reason this set and names was chosen,
> > please don't change them. It is for SDK compatibility.
> >   
>  
>  I 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.

>   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. 
LOL!

Reminds me of an argument I had a couple of days ago: "I never heard of HGH being
added to foods in the US, so it must not be true".

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?

Why would ReactOS developers be using "inofficial" headers? What's a
"privileged" developer?

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.

>   Ergo, we may define them to correctly reflect the
> EFLAGS register. 
Who is "WE"? You're not even a DEV for this project!

>   
>  However, but I think Alex is right that the compatible identifiers 
>  should be retained.
>  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).
>  As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. 
Then shut up and don't post completely USELESS and wrong information.

>   
>  Best Regards // L
>  
> >   On 2009-12-10, at 3:22 PM,
> > tkreuzer(a)svn.reactos.org wrote:
> > >   Author: tkreuzer
> > >  Date: Thu Dec 10 02:44:42 2009
> > >  New Revision: 44508
> > >  
> > >  URL: http://svn.reactos.org/svn/reactos?rev=44508&view=rev
> > >  Log:
> > >  updates EFLAGS definitions
> > >  
> > >  Modified:
> > >    branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
> > >  
> > >  Modified: branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h
> > >  URL:
> > > http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu…
> > >  ==============================================================================
> > >  --- branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1]
> > > (original)
> > >  +++ branches/ros-amd64-bringup/reactos/include/ndk/amd64/ketypes.h [iso-8859-1] Thu Dec
> > > 10 02:44:42 2009
> > >  @@ -82,19 +82,24 @@
> > >  //
> > >  // EFlags
> > >  //
> > >  -#define EFLAGS_CF               0x01L
> > >  -#define EFLAGS_ZF               0x40L
> > >  -#define EFLAGS_TF               0x100L
> > >  -#define EFLAGS_INTERRUPT_MASK   0x200L
> > >  -#define EFLAGS_DF               0x400L
> > >  -#define EFLAGS_NESTED_TASK      0x4000L
> > >  -#define EFLAGS_V86_MASK         0x20000
> > >  +#define EFLAGS_CF               0x01
> > >  +#define EFLAGS_PF               0x04
> > >  +#define EFLAGS_AF               0x10
> > >  +#define EFLAGS_ZF               0x40
> > >  +#define EFLAGS_SF               0x80
> > >  +#define EFLAGS_TF               0x100
> > >  +#define EFLAGS_INTERRUPT_MASK   0x200
> > >  +#define EFLAGS_DF               0x400
> > >  +#define EFLAGS_OF               0x800
> > >  +#define EFLAGS_IOPL_MASK        0x3000
> > >  +#define EFLAGS_NESTED_TASK      0x4000
> > >  +#define EFLAGS_RF               0x10000
> > >  +#define EFLAGS_VM               0x20000
> > >  #define EFLAGS_ALIGN_CHECK      0x40000
> > >  #define EFLAGS_VIF              0x80000
> > >  #define EFLAGS_VIP              0x100000
> > >  +#define EFLAGS_ID               0x200000
> > >  #define EFLAGS_USER_SANITIZE    0x3F4DD7
> > >  -#define EFLAG_SIGN              0x8000
> > >  -#define EFLAG_ZERO              0x4000
> > >  
> > >  //
> > >  // IPI Types 
> >  Best regards,
> >  Alex Ionescu 
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Javier Agustìn Fernàndez Arroyo]

i hope you dont mean we no-devs cant discuss stuff and even learn from you

On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:

>  
>
> >   Ergo, we may define them to correctly reflect the
> > EFLAGS register. 
>  Who is "WE"? You're not even a DEV for this project!
>
> >  
> >  However, but I think Alex is right that the compatible identifiers
> >  should be retained.
> >  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).
> >  As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. 
>  Then shut up and don't post completely USELESS and wrong information.
>
>

[Alex Ionescu]

I hope you can read English.

You no-devs are not supposed to challenge a coding change argument made by the person who
wrote the code with the argument being "I have no idea what I'm talking about but
you're wrong about how your own code should look like" and state "*we*
should do this instead."


On 2009-12-11, at 3:57 PM, Javier Agustìn Fernàndez Arroyo wrote:

>   
>  i hope you dont mean we no-devs cant discuss stuff and even learn from you
>  
>  On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>  
>  
> >   Ergo, we may define them to correctly reflect the
> > EFLAGS register. 
>  
>  Who is "WE"? You're not even a DEV for this project!
>  
> >  
> >  However, but I think Alex is right that the compatible identifiers
> >  should be retained.
> >  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).
> >  As for any MS EFLAGS_xx definitions, I'm not privvy and can't say. 
>  
>  Then shut up and don't post completely USELESS and wrong information.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Timo Kreuzer]

Relax, dude ;-P

The changes I made were the following:
1.) removed EFLAGS_ZERO and EFLAG_SIGN as they are part of winddk. Any
reason to have them in the NDK, too?
2.) added EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF, EFLAGS_IOPL_MASK,
EFLAGS_RF, EFLAGS_ID just for completeness.
3.) renamed EFLAGS_V86_MASK to EFLAGS_VM, as this is what it is in long
mode (there is no V86 mode)

The rest is still the same, although these definitions don't match
ksasm64.inc

Anyway, there's probably room for improvements. For example some
definitions are duplicated in asm.h and ketypes.h
I also wonder if there is any chance to make our assembly stuff
MSVC/MASM compatible and if we can still use #defines.

Further constructive suggestions appreciated.

Regards,
Timo


Alex Ionescu wrote:
>   I hope you can read English.
>
>  You no-devs are not supposed to challenge a coding change argument made by the person who
> wrote the code with the argument being "I have no idea what I'm talking about but
> you're wrong about how your own code should look like" and state "*we*
> should do this instead."
>
>
>  On 2009-12-11, at 3:57 PM, Javier Agustěn Fernŕndez Arroyo wrote:
>
>    
> >   i hope you dont mean we no-devs cant discuss
> > stuff and even learn from you
> >
> >  On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
> >
> >
> >      
> > >   Ergo, we may define them to correctly reflect the
> > > EFLAGS register.
> > >         
> >  Who is "WE"? You're not even a DEV for this project!
> >
> >      
> > >   However, but I think Alex is right that the
> > > compatible identifiers
> > >  should be retained.
> > >  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).
> > >  As for any MS EFLAGS_xx definitions, I'm not privvy and can't say.
> > >         
> >  Then shut up and don't post completely USELESS and wrong information.
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >       
>  Best regards,
>  Alex Ionescu
>
>
>    
>  ------------------------------------------------------------------------
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

On 2009-12-11, at 8:37 PM, Timo Kreuzer wrote:

>   Relax, dude ;-P
>  
>  The changes I made were the following:
>  1.) removed EFLAGS_ZERO and EFLAG_SIGN as they are part of winddk. Any
>  reason to have them in the NDK, too? 
1) Assembly code can't access winddk.h
2) They are in ks386.inc so they must be in asm.h (PSDK compat)

>   2.) added EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF,
> EFLAGS_IOPL_MASK,
>  EFLAGS_RF, EFLAGS_ID just for completeness. 
Problem is these aren't in ks386.inc -- hence we lose PSDK compat. Put them in an
internal ntoskrnl header or something.

>   3.) renamed EFLAGS_V86_MASK to EFLAGS_VM, as this is
> what it is in long
>  mode (there is no V86 mode) 
Again, same issue.

>   
>  The rest is still the same, although these definitions don't match
>  ksasm64.inc 
That's the problem!

>   
>  Anyway, there's probably room for improvements. For example some
>  definitions are duplicated in asm.h and ketypes.h
>  I also wonder if there is any chance to make our assembly stuff
>  MSVC/MASM compatible and if we can still use #defines. 
The real problem is asm.h needs to be 100% compatible with ks386.inc and moved to
include/psdk.

Anything that was used in asm.h and is not in ks386.inc needs to go to some internal
header.

>   
>  Further constructive suggestions appreciated. 
Same arguments apply for amd64/asm.h -- needs to match ksamd.inc
>   
>  Regards,
>  Timo
>  
>  
>  Alex Ionescu wrote:
> >   I hope you can read English.
> >  
> >  You no-devs are not supposed to challenge a coding change argument made by the person who
> > wrote the code with the argument being "I have no idea what I'm talking about but
> > you're wrong about how your own code should look like" and state "*we*
> > should do this instead."
> >  
> >  
> >  On 2009-12-11, at 3:57 PM, Javier Agustěn Fernŕndez Arroyo wrote:
> >  
> >  
> > >   i hope you dont mean we no-devs cant discuss
> > > stuff and even learn from you
> > >  
> > >  On Fri, Dec 11, 2009 at 9:42 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
> > >  
> > >  
> > >  
> > > >   Ergo, we may define them to correctly reflect the
> > > > EFLAGS register.
> > > >   
> > >  Who is "WE"? You're not even a DEV for this project!
> > >  
> > >  
> > > >   However, but I think Alex is right that the
> > > > compatible identifiers
> > > >  should be retained.
> > > >  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).
> > > >  As for any MS EFLAGS_xx definitions, I'm not privvy and can't say.
> > > >   
> > >  Then shut up and don't post completely USELESS and wrong information.
> > >  
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >   
> >  
> >  Best regards,
> >  Alex Ionescu
> >  
> >  
> >  
> >  ------------------------------------------------------------------------
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Timo Kreuzer]

Alex Ionescu wrote:
>   1) Assembly code can't access winddk.h
>     
True, but this was ketypes.h, not asm.h!

>   2) They are in ks386.inc so they must be in asm.h
> (PSDK compat)
>     
So you fucked it up in the first place. :-P

> >   2.) added
> > EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF, EFLAGS_IOPL_MASK,
> >  EFLAGS_RF, EFLAGS_ID just for completeness.
> >       
>  Problem is these aren't in ks386.inc -- hence we lose PSDK compat. Put them in an
> internal ntoskrnl header or something.
>     
Ok, will do.


> >   The rest is
> > still the same, although these definitions don't match
> >  ksasm64.inc
> >       
>  That's the problem!
>     
They haven't been correct before this commit. And They are also not
identical to ks386.inc, as far as I can see.

>   The real problem is asm.h needs to be 100% compatible
> with ks386.inc and moved to include/psdk.
>
>  Anything that was used in asm.h and is not in ks386.inc needs to go to some internal
> header.
>     
Ok, I will create such a header. I suggest to rename the files to
ks386.h and ksamd64.h instead of asm.h and instead create
include/reactos/i386/asm.h containing additional

[Alex Ionescu]

On 2009-12-12, at 5:51 PM, Timo Kreuzer wrote:

>   Alex Ionescu wrote:
> >   1) Assembly code can't access winddk.h
> >   
>  True, but this was ketypes.h, not asm.h! 
:( Oops! Yes, ketypes.h should have all of them you want, but in an MS-compatible name if
they already exist in ks386.inc

>   
> >   2) They are in ks386.inc so they must be in asm.h
> > (PSDK compat)
> >   
>  So you fucked it up in the first place. :-P 
I did... I did not think ks386.inc would be in the PSDK forever, I thought it was a
mistake the first time they published it (this was 4-5 years ago).

I didn't want someone to make the mistake worse...

>   
> > >   2.) added
> > > EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF, EFLAGS_IOPL_MASK,
> > >  EFLAGS_RF, EFLAGS_ID just for completeness.
> > >   
> >  
> >  Problem is these aren't in ks386.inc -- hence we lose PSDK compat. Put them in an
> > internal ntoskrnl header or something.
> >   
>  Ok, will do. 
Thanks!

>   
>  
> > >   The rest
> > > is still the same, although these definitions don't match
> > >  ksasm64.inc
> > >   
> >  
> >  That's the problem!
> >   
>  They haven't been correct before this commit. And They are also not
>  identical to ks386.inc, as far as I can see. 
Yeah, that's not your fault, I was just letting you know :)

>   
> >   The real problem is asm.h needs to be 100%
> > compatible with ks386.inc and moved to include/psdk.
> >  
> >  Anything that was used in asm.h and is not in ks386.inc needs to go to some internal
> > header.
> >   
>  Ok, I will create such a header. I suggest to rename the files to
>  ks386.h and ksamd64.h instead of asm.h and instead create
>  include/reactos/i386/asm.h containing additional 
Excellent, thanks!

>   
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Love Nystrom]

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
/

[James Tabor]

TAINT!

On Sat, Dec 12, 2009 at 2:02 AM, Love Nystrom <love.nystrom(a)gmail.com> wrote:
>   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.
>  
NO PLEASE TELL ME HE DID NOT WRITE "TAINT!"!!!!!
NOOOOOOOOOOOOooooooooooooooooo,,,,,,,,,,,...........~!!!!!!!!!

T-A-I-N-T !!!!

Watch out! This might cause your taint to drop on to the floor!
James