I am currently trying to clean up our win32k headers.
The situation so far: - ntgdi.h in psdk which should be compatible to ms version of ntgdi.h from the sdk - ntgdytyp.h containing a bunch of gdi related types in include/reactos/win32k - ntgdihdl.h containing handle related types and macros in include/reactos/win32k - ntgdibad.h containing private and ms incompatible functions and structures in include/reactos/win32k - ntuser.h containing ntuser functions and types in include/reactos/win32k - ntusertyp.h containing ntuser related types in include/reactos/win32k - W32CLIENTINFO is defined in both ntusertyp.h and ntgdityp.h (less complete). - there is the PATRECT structure in ntuser.h, and if ntuser.h is not included, also in ntgdityp.h, this should be named POLYPATBLT as defined in ntgdi.h, but there is only an incomplete type without the structure definition. (IMO ms should have put this structure into wingdi.h together with PolyPatBlt, but they don't seem to want anyone use that gdi32 exported function.)
I wonder why ms put ntgdi.h into the sdk at all, as it's completely useless to user mode application writers, but well, ncie to have the prototypes ;-)
So how do we clean up this mess?
Suggestions: - when ms puts ntgdi.h into the sdk, we could also put ntuser.h there. - if we want to stay 100% compatible with sdk headers, we can add a define, like #ifdef USE_NON_SDK // put non sdk compatible but still windows compatible definitions here #endif - use a version definition, like I did with the simplecall definitions in ntuser.h to make it compatible to different windows versions - keep ntgdibad.h and create ntuserbad.h for incompatible definitions - ntgdihdl.h is used by win32k and gdi32, both also import ntgdityp.h. So I'd suggest merging that stuff into ntgdityp.h - maybe merge types into ntgdi.h and ntuser.h? Some definitions are already in there. - create win32ktypes.h and put ntuser/ntgdi shared stuff there, like W32CLIENTINFO - maybe add POLYPATBLT and PolyPatBlt() (others?) to wingdi.h inside USE_NON_SDK ifdef plus a POLYPATBLT_DEFINED
I don't think it's a problem to make our sdk headers more complete than ms ones. This might help if we don't want a header mess or extra definitions inside the .c files.
Comments appreciated.
Thanks, Timo
Hi!
On Wed, Apr 2, 2008 at 11:21 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
I am currently trying to clean up our win32k headers.
The situation so far:
- ntgdi.h in psdk which should be compatible to ms version of ntgdi.h
from the sdk
Yes! Should always be!!
- ntgdytyp.h containing a bunch of gdi related types in
include/reactos/win32k
- ntgdihdl.h containing handle related types and macros in
include/reactos/win32k
- ntgdibad.h containing private and ms incompatible functions and
structures in include/reactos/win32k
- ntuser.h containing ntuser functions and types in include/reactos/win32k
- ntusertyp.h containing ntuser related types in include/reactos/win32k
- W32CLIENTINFO is defined in both ntusertyp.h and ntgdityp.h (less
complete).
Gdi and User point to the ClientInfo area which is part of thread info structures and like all thread structures should be place in some sort of include/reactos/win32k/w32thread.h. This would allow Gdi and User to access them both. I have placed #ifndef _NTUSRTYP_ so when both headers are used there will be no compile errors.
- there is the PATRECT structure in ntuser.h, and if ntuser.h is not
included, also in ntgdityp.h, this should be named POLYPATBLT as defined in ntgdi.h, but there is only an incomplete type without the structure definition. (IMO ms should have put this structure into wingdi.h together with PolyPatBlt, but they don't seem to want anyone use that gdi32 exported function.)
I wonder why ms put ntgdi.h into the sdk at all, as it's completely useless to user mode application writers, but well, ncie to have the prototypes ;-)
So how do we clean up this mess?
Suggestions:
- when ms puts ntgdi.h into the sdk, we could also put ntuser.h there.
- if we want to stay 100% compatible with sdk headers, we can add a
define, like #ifdef USE_NON_SDK // put non sdk compatible but still windows compatible definitions here #endif
If we are compatible why do we need this? All SDK headers should be compatible and I have pointed this out. When NDK/DDK (WDK) or PSDK (SDK) changes are made the developer should have access to these and compare the changes to verify them as correct. I have made changes to the NDK with some Rtl functions and I had to make logical choices and assumptions. Since those Rtl functions are unknown and the research was from Wine, I did go through the steps of verifying and cross referencing them before I moved them into NDK.
SDK and WDK are open to the public and there is nothing preventing that developer from referencing them for research and standards.
One of my best patent guys always said,"Once someone publishes their patent in text book form, they just gave it away." If your lawyer doesn't know that, go find one that does!
- use a version definition, like I did with the simplecall definitions
in ntuser.h to make it compatible to different windows versions
- keep ntgdibad.h and create ntuserbad.h for incompatible definitions
- ntgdihdl.h is used by win32k and gdi32, both also import ntgdityp.h.
So I'd suggest merging that stuff into ntgdityp.h
- maybe merge types into ntgdi.h and ntuser.h? Some definitions are
already in there.
- create win32ktypes.h and put ntuser/ntgdi shared stuff there, like
W32CLIENTINFO
This will due too!
- maybe add POLYPATBLT and PolyPatBlt() (others?) to wingdi.h inside
USE_NON_SDK ifdef plus a POLYPATBLT_DEFINED
I don't think it's a problem to make our sdk headers more complete than ms ones. This might help if we don't want a header mess or extra definitions inside the .c files.
Comments appreciated.
Thanks, Timo
Thanks, James
James Tabor schrieb:
Gdi and User point to the ClientInfo area which is part of thread info structures and like all thread structures should be place in some sort of include/reactos/win32k/w32thread.h. This would allow Gdi and User to access them both. I have placed #ifndef _NTUSRTYP_ so when both headers are used there will be no compile errors.
Placing an undocumented and partly unknown structure inside two different headers will lead to problems, like the two different versions we have now ;-)
Suggestions:
- when ms puts ntgdi.h into the sdk, we could also put ntuser.h there.
- if we want to stay 100% compatible with sdk headers, we can add a
define, like #ifdef USE_NON_SDK // put non sdk compatible but still windows compatible definitions here #endif
If we are compatible why do we need this? All SDK headers should be compatible and I have pointed this out. When NDK/DDK (WDK) or PSDK (SDK) changes are made the developer should have access to these and compare the changes to verify them as correct. I have made changes to the NDK with some Rtl functions and I had to make logical choices and assumptions. Since those Rtl functions are unknown and the research was from Wine, I did go through the steps of verifying and cross referencing them before I moved them into NDK.
SDK and WDK are open to the public and there is nothing preventing that developer from referencing them for research and standards.
Well I'm not sure if I got you right, so I just try to make my thinking more clear: There's compatible and there's compatible: A) our sdk headers will contain 100% the same as ms sdk headers, not less, not more B) our sdk headers will contain everything that is in ms sdk headers, but can contain more. The ms sdk you can download is the public sdk. It's probably not what ms uses to compile their stuff. It's partly limited. ntgdi.h contains "typedef struct _POLYPATBLT POLYPATBLT, * PPOLYPATBLT"; But where's the real structure definition? Somewhere else? Does that make sense? Well it does when ms uses different headers that contain all the complete types, but then they don't even need this typedef.. So where do we put it? I suggested the #ifdef's to have compatibility A when it's not defined and B when it's defined. ntuser.h doesn't belong to the ms sdk. But for what reason? Do ms people really have ntuser stuff somewhere else? Probably not, they just decided not to ship it (I think they shipped ntuser.h with DDK some time ago)
Timo
Hi!
2008/4/2 Timo Kreuzer timo.kreuzer@web.de:
Placing an undocumented and partly unknown structure inside two different headers will lead to problems, like the two different versions we have now ;-)
Sorry~
Well I'm not sure if I got you right, so I just try to make my thinking more clear: There's compatible and there's compatible: A) our sdk headers will contain 100% the same as ms sdk headers, not less, not more B) our sdk headers will contain everything that is in ms sdk headers, but can contain more. The ms sdk you can download is the public sdk. It's probably not what ms uses to compile their stuff. It's partly limited. ntgdi.h contains "typedef struct _POLYPATBLT POLYPATBLT, * PPOLYPATBLT";
BTW the structure is this: typedef struct _POLYPATBLT { LONG nXLeft; LONG nYLeft; LONG nWidth; LONG nHeight; HBRUSH hBrush; } POLYPATBLT, * PPOLYPATBLT;
I was going to change it with the next installment of GdiBatch.
But where's the real structure definition? Somewhere else? Does that make sense? Well it does when ms uses different headers that contain all the complete types, but then they don't even need this typedef.. So where do we put it? I suggested the #ifdef's to have compatibility A when it's not defined and B when it's defined. ntuser.h doesn't belong to the ms sdk. But for what reason? Do ms people really have ntuser stuff somewhere else? Probably not, they just decided not to ship it (I think they shipped ntuser.h with DDK some time ago)
I guess we can add those into the our SDK. I was ranting on how we should be compatible.
Timo
Do what you think is right.... Thanks, James
-
James Tabor -
Timo Kreuzer