Remove all non-official LPC structures/defines/hardcoded hacks, and use actual correc...

[reactos.git] / reactos / include / ndk / fixmes.txt

diff --git a/reactos/include/ndk/fixmes.txt b/reactos/include/ndk/fixmes.txt
index 7814e74..b871431 100644 (file)
--- a/reactos/include/ndk/fixmes.txt
+++ b/reactos/include/ndk/fixmes.txt
@@ -33,8 +33,45 @@ List:
        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