Folks,
With the current efforts to cleanup our headers on __WINESRC__s, I realized we are actually quite close to 'clean' header, something that should allow us to compile Wine with other headers, such as those from the w32api package that's part of mingw.
This is a worthy goal as the compiler will flag problems in our headers (by complaining about different prototypes), as well as in the w32api headers. A win-win situation for the free software world.
What do we need to do before we can try this stunt? Well, we need to cleanup our headers of __WINESRC__ tests that modifies them in a incompatible way. Let me be more explicit: 1. Tests that do not allow a file to be included in Wine are OK. If we use other headers, those file will simply be ignored, as they would not be used by Wine. 2. Tests to keep certain things undefined/undeclared in Wine are OK. Such tests simply make the header files a subset of the standard one, and the stuff that's not defined is not used, so all is good. 3. Tests that _add_ stuff to headers are BAD. It's clear that such things will not be present in other headers, and things will not work out as nicely. 4. Tests that modify the behavior of the headers are BAD. Same explanation as above.
I will list below things that fall under 3, and 4. Ideas on how to deal with them are highly appreciated.
-- It seems to me we want to move these to a wine/multimedia.h header. include/mmddk.h:#ifdef __WINESRC__ include/mmddk.h-#define DRV_QUERYDSOUNDIFACE (DRV_RESERVED + 10) include/mmddk.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-/* this call (GetDriverFlags) is not documented, nor the flags returned. include/mmsystem.h- * here are Wine only definitions include/mmsystem.h- */ include/mmsystem.h-#define WINE_GDF_EXIST 0x80000000 include/mmsystem.h-#define WINE_GDF_16BIT 0x10000000 include/mmsystem.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-#define WAVE_DIRECTSOUND 0x0080 include/mmsystem.h-#endif
-- Why do we need this undef? include/objidl.h:#ifdef __WINESRC__ include/objidl.h-#undef GetObject include/objidl.h-#endif
-- ? include/rpcproxy.h:#if defined(__WINESRC__) && defined(__WINE_WINE_OBJ_OLEAUT_H) include/rpcproxy.h-/* see http://msdn.microsoft.com/library/en-us/dnmsj99/html/com0199.asp?frame=true */ include/rpcproxy.h- include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateProxyFromTypeInfo( LPTYPEINFO pTypeInfo, LPUNKNOWN pUnkOuter, REFIID riid, include/rpcproxy.h- LPRPCPROXYBUFFER *ppProxy, LPVOID *ppv ); include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateStubFromTypeInfo( LPTYPEINFO pTypeInfo, REFIID riid, LPUNKNOWN pUnkServer, include/rpcproxy.h- LPRPCSTUBBUFFER *ppStub ); include/rpcproxy.h- include/rpcproxy.h-#endif
-- Seems like it wants moving to a wine/base.h include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define CRITICAL_SECTION_INIT(name) { (void *)(__FILE__ ": " name), -1, 0, 0, 0, 0 } include/winbase.h-#endif
-- Why are these Wine specific? include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) include/winbase.h-#endif
-- This one's a bugger. It make no sense to define these things conditionally on the -- version of the compiler. One's code is written one way or another. -- I suggest we remove these completely, and we defined the NONAMELESS* explicitly -- in the files that need them. include/winnt.h:#ifdef __WINESRC__ include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# define NONAMELESSUNION include/winnt.h-#else include/winnt.h-/* Anonymous struct support starts with gcc 2.96 or gcc/g++ 3.x */ include/winnt.h-# if !defined(NONAMELESSSTRUCT) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && (defined(__cplusplu s) || (__GNUC_MINOR__ < 96))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# endif include/winnt.h-/* Anonymous unions support starts with gcc 2.96/g++ 2.95 */ include/winnt.h-# if !defined(NONAMELESSUNION) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && ((__GNUC_MINOR__ < 9 5) || ((__GNUC_MINOR__ == 95) && !defined(__cplusplus)))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSUNION
-- These want moving to a wine-private header (wine/base.h?) include/winnt.h:#ifdef __WINESRC__ include/winnt.h-#define MEM_SYSTEM 0x80000000 include/winnt.h-#endif
include/winnt.h:#ifdef __WINESRC__ include/winnt.h- include/winnt.h-/* Macros to retrieve the current context */ include/winnt.h- include/winnt.h-#ifdef __i386__ include/winnt.h- include/winnt.h-#define _DEFINE_REGS_ENTRYPOINT( name, fn, args ) \ include/winnt.h- __ASM_GLOBAL_FUNC( name, \ include/winnt.h- "call " __ASM_NAME("__wine_call_from_32_regs") "\n\t" \ include/winnt.h- ".long " __ASM_NAME(#fn) "\n\t" \ include/winnt.h- ".byte " #args ", " #args )
include/winsock.h:#ifdef __WINESRC__ include/winsock.h-#define FD_WINE_LISTENING 0x10000000 include/winsock.h-#define FD_WINE_NONBLOCKING 0x20000000 include/winsock.h-#define FD_WINE_CONNECTED 0x40000000 include/winsock.h-#define FD_WINE_RAW 0x80000000 include/winsock.h-#define FD_WINE_INTERNAL 0xFFFF0000 include/winsock.h-#endif
-- What about these? include/wownt32.h:#ifdef __WINESRC__ include/wownt32.h-/* under Wine use the kernel functions directly so we don't have to import wow32 */ include/wownt32.h-HANDLE WINAPI K32WOWHandle32(WORD,WOW_HANDLE_TYPE); include/wownt32.h-WORD WINAPI K32WOWHandle16(HANDLE,WOW_HANDLE_TYPE); include/wownt32.h-#define WOWHandle32 K32WOWHandle32 include/wownt32.h-#define WOWHandle16 K32WOWHandle16 include/wownt32.h-#endif
-- There are also some in include/winternl.h, but those can wait for now :)
- Tests that do not allow a file to be included in Wine are OK. If we use other headers, those file will simply be ignored, as they would not be used by Wine.
- Tests to keep certain things undefined/undeclared in Wine are OK. Such tests simply make the header files a subset of the standard one, and the stuff that's not defined is not used, so all is good.
well, except if the part that's undefined clashes with Wine's current code (name space collision, features unsupported by compiler...)
- Tests that _add_ stuff to headers are BAD. It's clear that such things will not be present in other headers, and things will not work out as nicely.
in most of the cases, those are used to extend an existing API by providing Wine specific features. removing them will create some new trouble: - in some cases, extension is achieved with using bits or values declared as RFU by MS. moving the definitions out of the header will make it hard, if those values in the future are actually used by MS, to see the clash - not having them also in our own headers, will make it harder for the ones wishing to use them (they'd need to include both the standard header, plus the needed extension)
all in all, this sounds to me more a good janitorial project, but keeping it as a final goal seems a bit too heavy to me
A+
"Dimitrie O. Paun" dpaun@rogers.com writes:
-- Why do we need this undef? include/objidl.h:#ifdef __WINESRC__ include/objidl.h-#undef GetObject include/objidl.h-#endif
Because GetObject is a WINELIB_NAME_AW #define, and these cause a (deliberate) syntax error when building Wine.
-- Why are these Wine specific? include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) include/winbase.h-#endif
That's simply an optimization; maybe we could use an inline function instead.
-- This one's a bugger. It make no sense to define these things conditionally on the -- version of the compiler. One's code is written one way or another. -- I suggest we remove these completely, and we defined the NONAMELESS* explicitly -- in the files that need them.
The idea is that you can then use the NONAMELESS defines to write more portable code, without having to duplicate the compiler checks. So the user's code can do something like:
#include <winnt.h> #ifdef NONAMELESSUNION #define U(x) u.x #else #define U(x) x #endif
On January 5, 2003 06:38 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
-- Why do we need this undef? include/objidl.h:#ifdef __WINESRC__ include/objidl.h-#undef GetObject include/objidl.h-#endif
Because GetObject is a WINELIB_NAME_AW #define, and these cause a (deliberate) syntax error when building Wine.
Which means this ifdef is OK, it will not cause problems with other headers.
-- Why are these Wine specific? include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) include/winbase.h-#endif
That's simply an optimization; maybe we could use an inline function instead.
Ditto, right?
-- This one's a bugger. It make no sense to define these things conditionally on the -- version of the compiler. One's code is written one way or another. -- I suggest we remove these completely, and we defined the NONAMELESS* explicitly -- in the files that need them.
The idea is that you can then use the NONAMELESS defines to write more portable code, without having to duplicate the compiler checks. So the user's code can do something like:
#include <winnt.h> #ifdef NONAMELESSUNION #define U(x) u.x #else #define U(x) x #endif
Right. But it seems to me the NONAMELESS* names are a bit overloaded: on one hand, they are used to signal how some structures are defined, on the other they describe the capabilities of the compiler.
For example, what if one decides to use names on _all_ gcc versions? This thing gets in the way, no?
What about all the other things I've mentioned? Should we do anything about them? And if yes, what?
"Dimitrie O. Paun" dpaun@rogers.com writes:
That's simply an optimization; maybe we could use an inline function instead.
Ditto, right?
Yes, it would just be cleaner without it but it won't break anything.
Right. But it seems to me the NONAMELESS* names are a bit overloaded: on one hand, they are used to signal how some structures are defined, on the other they describe the capabilities of the compiler.
For example, what if one decides to use names on _all_ gcc versions? This thing gets in the way, no?
No, then you define NONAMELESS* yourself, that's what we do in Wine.
What about all the other things I've mentioned? Should we do anything about them? And if yes, what?
The extra flag values etc. should be removed, by fixing the code to not depend on extending the API that way. Of course that's easier said than done...
On January 5, 2003 07:39 pm, Alexandre Julliard wrote:
For example, what if one decides to use names on _all_ gcc versions? This thing gets in the way, no?
No, then you define NONAMELESS* yourself, that's what we do in Wine.
OK, but my problem is that we defined them on the #ifdef __WINESRC__. Which means our code will fail with other headers (even though, granted the fix is trivial). But I'm thinking, wouldn't it better to explicitely define these in the files that need it?
The extra flag values etc. should be removed, by fixing the code to not depend on extending the API that way. Of course that's easier said than done...
Yay! Can you please suggest a solution / comment on my comments :)? Here they are again:
-- It seems to me we want to move these to a wine/multimedia.h header. include/mmddk.h:#ifdef __WINESRC__ include/mmddk.h-#define DRV_QUERYDSOUNDIFACE (DRV_RESERVED + 10) include/mmddk.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-/* this call (GetDriverFlags) is not documented, nor the flags returned. include/mmsystem.h- * here are Wine only definitions include/mmsystem.h- */ include/mmsystem.h-#define WINE_GDF_EXIST 0x80000000 include/mmsystem.h-#define WINE_GDF_16BIT 0x10000000 include/mmsystem.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-#define WAVE_DIRECTSOUND 0x0080 include/mmsystem.h-#endif
-- ? include/rpcproxy.h:#if defined(__WINESRC__) && defined(__WINE_WINE_OBJ_OLEAUT_H) include/rpcproxy.h-/* see http://msdn.microsoft.com/library/en-us/dnmsj99/html/com0199.asp?frame=true */ include/rpcproxy.h- include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateProxyFromTypeInfo( LPTYPEINFO pTypeInfo, LPUNKNOWN pUnkOuter, REFIID riid, include/rpcproxy.h- LPRPCPROXYBUFFER *ppProxy, LPVOID *ppv ); include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateStubFromTypeInfo( LPTYPEINFO pTypeInfo, REFIID riid, LPUNKNOWN pUnkServer, include/rpcproxy.h- LPRPCSTUBBUFFER *ppStub ); include/rpcproxy.h- include/rpcproxy.h-#endif
-- Seems like it wants moving to a wine/base.h include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define CRITICAL_SECTION_INIT(name) { (void *)(__FILE__ ": " name), -1, 0, 0, 0, 0 } include/winbase.h-#endif
-- These want moving to a wine-private header (wine/base.h?) include/winnt.h:#ifdef __WINESRC__ include/winnt.h-#define MEM_SYSTEM 0x80000000 include/winnt.h-#endif
include/winnt.h:#ifdef __WINESRC__ include/winnt.h- include/winnt.h-/* Macros to retrieve the current context */ include/winnt.h- include/winnt.h-#ifdef __i386__ include/winnt.h- include/winnt.h-#define _DEFINE_REGS_ENTRYPOINT( name, fn, args ) \ include/winnt.h- __ASM_GLOBAL_FUNC( name, \ include/winnt.h- "call " __ASM_NAME("__wine_call_from_32_regs") "\n\t" \ include/winnt.h- ".long " __ASM_NAME(#fn) "\n\t" \ include/winnt.h- ".byte " #args ", " #args )
include/winsock.h:#ifdef __WINESRC__ include/winsock.h-#define FD_WINE_LISTENING 0x10000000 include/winsock.h-#define FD_WINE_NONBLOCKING 0x20000000 include/winsock.h-#define FD_WINE_CONNECTED 0x40000000 include/winsock.h-#define FD_WINE_RAW 0x80000000 include/winsock.h-#define FD_WINE_INTERNAL 0xFFFF0000 include/winsock.h-#endif
-- What about these? include/wownt32.h:#ifdef __WINESRC__ include/wownt32.h-/* under Wine use the kernel functions directly so we don't have to import wow32 */ include/wownt32.h-HANDLE WINAPI K32WOWHandle32(WORD,WOW_HANDLE_TYPE); include/wownt32.h-WORD WINAPI K32WOWHandle16(HANDLE,WOW_HANDLE_TYPE); include/wownt32.h-#define WOWHandle32 K32WOWHandle32 include/wownt32.h-#define WOWHandle16 K32WOWHandle16 include/wownt32.h-#endif
"Dimitrie O. Paun" dpaun@rogers.com writes:
OK, but my problem is that we defined them on the #ifdef __WINESRC__. Which means our code will fail with other headers (even though, granted the fix is trivial). But I'm thinking, wouldn't it better to explicitely define these in the files that need it?
Yes that would probably be better.
Yay! Can you please suggest a solution / comment on my comments :)? Here they are again:
include/rpcproxy.h:#if defined(__WINESRC__) && defined(__WINE_WINE_OBJ_OLEAUT_H) include/rpcproxy.h-/* see http://msdn.microsoft.com/library/en-us/dnmsj99/html/com0199.asp?frame=true */ include/rpcproxy.h- include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateProxyFromTypeInfo( LPTYPEINFO pTypeInfo, LPUNKNOWN pUnkOuter, REFIID riid, include/rpcproxy.h- LPRPCPROXYBUFFER *ppProxy, LPVOID *ppv ); include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateStubFromTypeInfo( LPTYPEINFO pTypeInfo, REFIID riid, LPUNKNOWN pUnkServer, include/rpcproxy.h- LPRPCSTUBBUFFER *ppStub ); include/rpcproxy.h- include/rpcproxy.h-#endif
This can probably be removed/commented out.
-- Seems like it wants moving to a wine/base.h include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define CRITICAL_SECTION_INIT(name) { (void *)(__FILE__ ": " name), -1, 0, 0, 0, 0 } include/winbase.h-#endif
This could be removed and replaced by explicit initializations in the files that need it.
include/winnt.h:#ifdef __WINESRC__ include/winnt.h- include/winnt.h-/* Macros to retrieve the current context */ include/winnt.h- include/winnt.h-#ifdef __i386__ include/winnt.h- include/winnt.h-#define _DEFINE_REGS_ENTRYPOINT( name, fn, args ) \ include/winnt.h- __ASM_GLOBAL_FUNC( name, \ include/winnt.h- "call " __ASM_NAME("__wine_call_from_32_regs") "\n\t" \ include/winnt.h- ".long " __ASM_NAME(#fn) "\n\t" \ include/winnt.h- ".byte " #args ", " #args )
This one will need to be moved, and probably reworked a bit. I'll look into doing that.
-- What about these? include/wownt32.h:#ifdef __WINESRC__ include/wownt32.h-/* under Wine use the kernel functions directly so we don't have to import wow32 */ include/wownt32.h-HANDLE WINAPI K32WOWHandle32(WORD,WOW_HANDLE_TYPE); include/wownt32.h-WORD WINAPI K32WOWHandle16(HANDLE,WOW_HANDLE_TYPE); include/wownt32.h-#define WOWHandle32 K32WOWHandle32 include/wownt32.h-#define WOWHandle16 K32WOWHandle16 include/wownt32.h-#endif
That's just an optimization, it shouldn't matter.
-- It seems to me we want to move these to a wine/multimedia.h header. include/mmddk.h:#ifdef __WINESRC__ include/mmddk.h-#define DRV_QUERYDSOUNDIFACE (DRV_RESERVED + 10) include/mmddk.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-/* this call (GetDriverFlags) is not documented, nor the flags returned. include/mmsystem.h- * here are Wine only definitions include/mmsystem.h- */ include/mmsystem.h-#define WINE_GDF_EXIST 0x80000000 include/mmsystem.h-#define WINE_GDF_16BIT 0x10000000 include/mmsystem.h-#endif
include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-#define WAVE_DIRECTSOUND 0x0080 include/mmsystem.h-#endif
-- These want moving to a wine-private header (wine/base.h?) include/winnt.h:#ifdef __WINESRC__ include/winnt.h-#define MEM_SYSTEM 0x80000000 include/winnt.h-#endif
include/winsock.h:#ifdef __WINESRC__ include/winsock.h-#define FD_WINE_LISTENING 0x10000000 include/winsock.h-#define FD_WINE_NONBLOCKING 0x20000000 include/winsock.h-#define FD_WINE_CONNECTED 0x40000000 include/winsock.h-#define FD_WINE_RAW 0x80000000 include/winsock.h-#define FD_WINE_INTERNAL 0xFFFF0000 include/winsock.h-#endif
For all of these the code probably needs to be redesigned to not require API extensions. I don't know how, each one must be studied in detail. And there are probably other places where we have added Wine-specific flags without __WINESRC__ that will need to be fixed too.
With the current efforts to cleanup our headers on __WINESRC__s, I realized we are actually quite close to 'clean' header, something that should allow us to compile Wine with other headers, such as those from the w32api package that's part of mingw.
Hehe I'm happy someone else wants to see this now. If there is someway we can script testing with other headers mabey with perl or something (now that MSYS has a decent perl) we can find where the WINE headers and others are not in sync. If such as system was in place I would be happy to add it to my testing routine.
Thanks Steven
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
On January 7, 2003 10:44 am, Steven Edwards wrote:
Hehe I'm happy someone else wants to see this now. If there is someway we can script testing with other headers mabey with perl or something (now that MSYS has a decent perl) we can find where the WINE headers and others are not in sync. If such as system was in place I would be happy to add it to my testing routine.
The hard part is getting Wine to compile with other headers. Once that's done, I don't think we need any script: just capture the compiler output, and go fix the warnings... We can go fancy if we want to do this automatically from time to time, but this is just us geeks going crazy. Let's get first Wine to compile with w32api (or even better with the MSVC headers!), that's where the hard work is.
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Steven Edwards