Hey guys,
What is our policy on adding undocumented functions to Wine's public headers? My stance is that we, as an alternative implementation of the Win32 API, provide another set of Win32 public headers, like Microsoft and cygwin/mingw provide as well. If our headers contain undocumented functions that no other headers have, then we're just that much more complete. I've always thought of the Wine code base as documentation for the Win32 API, especially in places where there is no documentation from Microsoft. There are several places where -Wmissing-declarations warns about missing declarations for exported APIs. A lot of these have no corresponding entry in Microsoft's public headers. Adding these declarations gets rid of the warnings and makes our headers more complete. What are your thoughts on this matter?
James Hawkins wrote:
Hey guys,
What is our policy on adding undocumented functions to Wine's public headers? My stance is that we, as an alternative implementation of the Win32 API, provide another set of Win32 public headers, like Microsoft and cygwin/mingw provide as well. If our headers contain undocumented functions that no other headers have, then we're just that much more complete. I've always thought of the Wine code base as documentation for the Win32 API, especially in places where there is no documentation from Microsoft. There are several places where -Wmissing-declarations warns about missing declarations for exported APIs. A lot of these have no corresponding entry in Microsoft's public headers. Adding these declarations gets rid of the warnings and makes our headers more complete. What are your thoughts on this matter?
I think we should do this, but protect them with #ifdef __WINESRC__, since we may want to use them internally, but we don't want them used in things that may be built with the PSDK headers, like tests.
Robert Shearman rob@codeweavers.com writes:
I think we should do this, but protect them with #ifdef __WINESRC__, since we may want to use them internally, but we don't want them used in things that may be built with the PSDK headers, like tests.
We can do that for things that actually need to be used from other dlls, but if it's just to quiet the warnings then I don't think that's a good enough reason to diverge from the SDK headers.
On Tue, 10 Oct 2006, James Hawkins wrote: [...]
What is our policy on adding undocumented functions to Wine's public headers? My stance is that we, as an alternative implementation of the Win32 API, provide another set of Win32 public headers, like Microsoft and cygwin/mingw provide as well. If our headers contain undocumented functions that no other headers have, then we're just that much more complete.
Developers who write Windows programs and call undocumented functions are likely to define a prototype for them straight in their source code. So adding prototypes for undocumented functions in Wine's public headers would likely cause such code to fail to compile with Winelib (duplicate prototypes, small divergences, etc). As such it should be avoided.