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@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/includ... ============================================================================== --- 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 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@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/includ... ============================================================================== --- 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
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@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/includ... ============================================================================== --- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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@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.
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Alex Ionescu wrote:
- Assembly code can't access winddk.h
True, but this was ketypes.h, not asm.h!
- 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
On 2009-12-12, at 5:51 PM, Timo Kreuzer wrote:
Alex Ionescu wrote:
- 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
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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 /
TAINT!
On Sat, Dec 12, 2009 at 2:02 AM, Love Nystrom love.nystrom@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
-
Alex Ionescu -
James Tabor -
Javier Agustìn Fernàndez Arroyo -
Love Nystrom -
Timo Kreuzer