Alex Ionescu弄的一个工程：
The NDK has been used by ReactOS for more than two years now, as well as by all the tools which I'm developping. The whole point is to provide a set of "as-official-as-you-can-get" headers which supplement the WDK when developing applications which use the Native API. You can find more information in the "readme.txt" file in the NDK directory, as well as on the ReactOS Wiki.
Basically, the point of the NDK, in short:
1) Allow you to write 100% native applications without needing windows.h. Allow you to write Win32 applications which use Native APIs. Allow you to write kernel-mode drivers which peer into internal structures, or use undocumented kernel APIs.
2) Provide a *single* and *correct* set of headers for *all* community members who need access to Native API. Too many people get it wrong, or get it right but had to spend 2 months duplicating effort that someone may already have been made.
There's still a lot of work to be done in two areas:
1) Versionning. Since ReactOS has a stable goal of Windows Server 2003 SP1, and my apps are mostly for Vista, those are the two versions which have been the most tested (especially the former). The NDK supports versionning, but not all structures have XP versions, much less 2000 versions.
2) 64-bit support. Since ReactOS is only 32-bit, there wasn't a lot of work done for 64-bit support, except for cross-compiling my Vista programs. Therefore, many fields/parameters which are marked "ULONG" may actually be SIZE_T or ULONG_PTR.
I strongly urge and recommend anyone writing native applications to use the NDK instead of their own header files and please let me know any issues you encounter. As far as naming and structure format goes, the ones in the NDK are the official Microsoft-internal names (which were obtained either from symbols or strings inside binaries) --not guesses. So they supercede information found on other websites, if contradictory (of course, if you have a really good argument against a field name, feel free to drop me a note -- everyone makes mistakes).
Information on proper use of the NDK is found in the readme and ReactOS Wiki.
Next up, I plan to release the NDL, a library which handles most of the hard operations that native mode applications need to worry about, such as console input and output, process/thread routines and file i/o. The NDL will grow as required, since it's a fairly new project.
This will be followed by the latest NCLI, a simple command-line shell which will have basic commands similar to DOS. The current "lp", "lm" and "devtree" commands will become separate programs that the NCLI will be able to execute. NCLI itself will be very small, depending on the NDL for most input/output functionality, and only handling actual shell-specific processing. The hope is to isolate as much "common" functionality into the NDL as possibe, without putting too much into it.
As more people migrate towards the NDL/NDK, it should increase the quality of these two projects, as well as any current/future projects that use native APIs/structures (The Native Regedit comes to mind).
All is GPL, with a commercial license option.
Link: http://native-nt-toolkit.googlecode.com/svn/trunk/ndk/ for the SVN, http://code.google.com/p/native-nt-toolkit/ for the project homepage (including a direct .zip download)
The NDK has been used by ReactOS for more than two years now, as well as by all the tools which I'm developping. The whole point is to provide a set of "as-official-as-you-can-get" headers which supplement the WDK when developing applications which use the Native API. You can find more information in the "readme.txt" file in the NDK directory, as well as on the ReactOS Wiki.
Basically, the point of the NDK, in short:
1) Allow you to write 100% native applications without needing windows.h. Allow you to write Win32 applications which use Native APIs. Allow you to write kernel-mode drivers which peer into internal structures, or use undocumented kernel APIs.
2) Provide a *single* and *correct* set of headers for *all* community members who need access to Native API. Too many people get it wrong, or get it right but had to spend 2 months duplicating effort that someone may already have been made.
There's still a lot of work to be done in two areas:
1) Versionning. Since ReactOS has a stable goal of Windows Server 2003 SP1, and my apps are mostly for Vista, those are the two versions which have been the most tested (especially the former). The NDK supports versionning, but not all structures have XP versions, much less 2000 versions.
2) 64-bit support. Since ReactOS is only 32-bit, there wasn't a lot of work done for 64-bit support, except for cross-compiling my Vista programs. Therefore, many fields/parameters which are marked "ULONG" may actually be SIZE_T or ULONG_PTR.
I strongly urge and recommend anyone writing native applications to use the NDK instead of their own header files and please let me know any issues you encounter. As far as naming and structure format goes, the ones in the NDK are the official Microsoft-internal names (which were obtained either from symbols or strings inside binaries) --not guesses. So they supercede information found on other websites, if contradictory (of course, if you have a really good argument against a field name, feel free to drop me a note -- everyone makes mistakes).
Information on proper use of the NDK is found in the readme and ReactOS Wiki.
Next up, I plan to release the NDL, a library which handles most of the hard operations that native mode applications need to worry about, such as console input and output, process/thread routines and file i/o. The NDL will grow as required, since it's a fairly new project.
This will be followed by the latest NCLI, a simple command-line shell which will have basic commands similar to DOS. The current "lp", "lm" and "devtree" commands will become separate programs that the NCLI will be able to execute. NCLI itself will be very small, depending on the NDL for most input/output functionality, and only handling actual shell-specific processing. The hope is to isolate as much "common" functionality into the NDL as possibe, without putting too much into it.
As more people migrate towards the NDL/NDK, it should increase the quality of these two projects, as well as any current/future projects that use native APIs/structures (The Native Regedit comes to mind).
All is GPL, with a commercial license option.
Link: http://native-nt-toolkit.googlecode.com/svn/trunk/ndk/ for the SVN, http://code.google.com/p/native-nt-toolkit/ for the project homepage (including a direct .zip download)
其实有了wrk和pdb+F5，基本windows系统自身的东西就是开源的了。。
扫一扫
220
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
