Priority 4:\r
- FIXED: Kernel and Memory Types are not architecture-specific (Eric) [ketypes.h, mmtypes.h]\r
- FIXED: Win32K Builds with windows.h (Filip) [extypes.h, ketypes.h]\r
+ - Move out stuff from umtypes.h into the actual header where they should go. Use ifdeffing\r
+ directly in that file to protect user-mode versus kernel-mode types. umtypes.h will only\r
+ end up containing the misc types that are needed for compatibility. This would create a\r
+ significant cleanup.\r
\r
Priority 5:\r
- - LPC Types are totally wrong. [lpctypes.h]\r
+ - FIXED: LPC Types are totally wrong. (Alex) [lpctypes.h]\r
- Missing System Info Classes [zwtypes.h]\r
- FIXED: Process Priority Classes are messed up (Alex) [pstypes.h]\r
+ \r
+Generic Note:\r
+ One of the most difficult things is when certain structures require the IFS for some of their\r
+ members. Up until some time ago, the IFS was 1000$, so it was senseless to require it in order\r
+ to allow people to use the NDK. Recently, however, the IFS price went down to 100$. This is \r
+ still way too much. Even though the GNU NTIFS.H exists, I don't want to fallback on it. The\r
+ good news is that the WDK (Windows Driver Kit), which will supplant the DDK in about a year,\r
+ includes the IFS. At that point we can remove all the #ifndef/ifdef NTIFS hacks, since it'll\r
+ be OK to "force" IFS usage.\r
+ \r
+ UPDATE:\r
+ However, I'm giving serious consideration of making the IFS a requirement, and suggesting\r
+ usage of the GNU IFS for anyone that needs it. The problem, however, is that the official\r
+ GNU IFS is outdated and quite invalid in many ways, compared to the ReactOS IFS (which still\r
+ isn't perfect yet). Also, this would include many more definitions then needed. A third\r
+ option that I'm considering is creating a new header, until the WDK is out, which will be \r
+ called ifstypes. It would be the brother of umtypes, but for kernel mode. Only a small\r
+ number of types will need to be included, and hence they will be easy to locate in case\r
+ the official ones change (by the time they do, the WDK will be out however, so no worries).\r
+ It would reduce all the ifdeffing to a single file.\r
+ \r
+ UPDATE2:\r
+ No. This is a bad idea. I've just added a note to purge out large parts of umtypes.h into the\r
+ actual xxtypes.h files, and then use iffdefing. This is a direct contradiction to my idea of\r
+ generalizing all the IFS stuff together.\r
+ \r
+ UPDATE3:\r
+ No. This is different...the user-mode types will always be unavailable in kernel-mode, and \r
+ dissipating them into the real files is a good thing, because they will never move out and\r
+ they are much easier to maintain. However, once the WDK comes out, all #ifdef ntifs will\r
+ become obsolete, and they will have to be hunted down and removed. Having a single file that\r
+ is automatically added if the IFS is not detected is much easier to remove once the time\r
+ comes.\r