sync defines style with sdk/wdk about systeminformer

[dmex]

So it would be possible to same macro defines for r0/r3, w/o splitting via "#if (PHNT_MODE == PHNT_MODE_KERNEL)" and w/o "#ifndef XXX" guard.

They're already supported for both modes but PHNT_MODE ifdefs exist to guarantee only types available with the WDK are available by default.

E.g. #define FILE_READ_DATA ( 0x0001 ) - this has extra spaces inside braces; they can't be removed.
However, spaces before the first token and after the last one are ignored. The presense of comment on the line is also ignored (naturally).

Are you using /std:c++latest and /std:c17? none of these defines and values should be generating a warning or causing issues unless something is causing msvc to compile with the legacy preprocessor/compatibility modes.

[pokanoka]

They're already supported for both modes but PHNT_MODE ifdefs exist to guarantee only types available with the WDK are available by default.

Yeah, I have no complains here. What I was trying to refer is just preprocessor defines (ignoring types). I meant to say that when define is exactly the same in sdk/wdk and in SystemInformer header, we can remove PHNT_MODE ifdef guards around the defines (redefining the macro to the same value is not treated as warning).

Are you using /std:c++latest and /std:c17? none of these defines and values should be generating a warning or causing issues

Actually yes, and I have no warnings when building SystemInformer itself :-)

Intention

My intention here is not to fix any issues with PHNT (there's none), but rather to provide some unification and increase interoperability with other projects by setting the defines to the common base (the common base being the defines used by Microsoft). Incidentally this also has some benefit of simplifying PHNT headers (by removing some ifdef guards) and a benefit of providing insurance of no discrepancies between defines in PHNT and in sdk/wdk (by way of compiler warnings which will arise iff defines ever change; with ifdef guards there's no such benefit).

Example

Perhaps a simple example of why I want this to be merged is in order.
Imagine there's 3 projects: "myexe", "ntobjdir", and "phnt".

The imaginary "ntobjdir" lib provides api for working with native object directories. It has interface header which has define #define DIRECTORY_QUERY (0x0001), w/o any ifdef guards. One can include this interface header in any order; it has no conflicts with sdk/wdk - because all defines are exactly the same (save for comments and whitespaces).

Now there's also "phnt" project. It has #define DIRECTORY_QUERY 0x0001. When one includes it's headers in the specified order (<phnt_windows.h> instead of <windows.h>), there's again no conflict nor problems.

However. If compilation unit in "myexe" project wants to use both "ntobjdir" lib and "phnt", there's trouble!
The defines will mismatch and one will get compiler warnings. Not nice! How can this be solved? Two possible solutions:

1. Wrap each potentially conflicting define in ifdef, in all libs: #ifndef DIRECTORY_QUERY ... #define DIRECTORY_QUERY xxxx ... #endif. That'll quickly will become very-very ugly.

2. Or play nice, and just make all potentially conflicting defines the same as the baseline define used by Microsoft.
   That'll allow to include lib headers in any sane order and there will be no define conflicts: neither between different libs nor between libs and sdk/wdk.

Changes

As can be seen from the commit, the ammount of changes for basic defines style unification is very low (initially I expected much more changes). Perhaps I might have missed something, but so far it was all required.