\r
List:\r
Priority 1:\r
- - LDR_DATA_TABLE_ENTRY has a ROSSYM Hack (GvG) [ldrtypes.h]\r
+ - FIXED: LDR_DATA_TABLE_ENTRY has a ROSSYM Hack (Alex) [ldrtypes.h]\r
- FIXED: LDR_FLAGS are not correct (Alex) [ldrtypes.h]\r
- FIXED: Remove extra Process Info classes from ddk (Alex) [zwtypes.h]\r
- FIXED: PsEstablishWin32Callouts + Parameters don't match NT (Alex) [obtypes.h]\r
- Object Directory + implementation doesn't match NT (Alex) [obtypes.h]\r
\r
Priority 3:\r
- - Some RTL Structures need review (Alex) [rtltypes.h]\r
+ - FIXED: Some RTL Structures need review (Alex) [rtltypes.h]\r
- Pushlock support is needed to fix EPROCESS (Alex) [pstypes.h]\r
- MADDRESS_SPACE must be converted into the NT Type (Alex) [pstypes.h, mmtypes.h]\r
\r
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
+ - FIXED: Modify design of NDK so that all the types are in their respective files (Alex) [*.h]\r
\r
Priority 5:\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
projects / reactos.git / blobdiff