[ros-dev] headers suggestion

Jonathan Wilson jonwil at tpgi.com.au
Sun Nov 21 08:33:34 CET 2004


 >> , videoprt.sys, ndis.sys etc)
 >
 >
 >
 > Once again, I'm not sure those have exported functions that are usually
 > being called, so I don't see why to include them in the NDK. They should
 > just have their own set of internal headers.
just ask vizzini (our ndis guru) about ndis.sys and calling functions in it 
that are not documented by microsoft.
I suspect that there are things in videoprt.sys not documented by microsoft 
either.
IMO the NDK should basicly be 3 things:
1.a "native" API header file or files (i.e. the "nt.h" which has been 
referenced in at least one microsoft example or code somewhere) and would 
provide interfaces for everything in ntdll.dll that we can get prototypes for.
2.a set of header files that document everything exported by ntoskrnl, hal, 
win32k (the Engxxx functions), videoprt.sys, ndis.sys, scsiport.sys etc and 
not documented by microsoft.
then 3.anything else in userland that isnt documeneted (e.g. undocumented 
shell32 functions or undocumented user32 functions or whatever else). I 
have actually seen some of this undocumented stuff in real-world usage.
Lots of people use undocumented shell32 functions for various things.
And several code examples out there subclass the menu windows in that app 
with a hook and hook various undocumented menu messages (I have seen 
references to MN_xxx messages that I think are the messages in question 
although I cant remember where I saw them). So, people are using the 
undocumented functionality.
Since we are implementing it (to be compatible with windows), I see no 
reason not to document it somewhere for all to see...

Are we going to actually get permission to re-licence then submit all the 
w23api changes back to w32api?
If so, I suggest we keep the stuff (like IFS) that w32api wont accept 
seperate (i.e. in seperate header files) from the base w32api (i.e. our 
w32api would only be w32api + stuff we are working on getting into w32api)

Given that anything that goes into our SDK and DDK headers will be stuff 
that is documented in the platform SDK with any ros-specific additions 
(e.g. for stuff that is documented)



More information about the Ros-dev mailing list