On Tuesday 15 October 2002 12:07 pm, Ove Kaaven wrote:
On 15 Oct 2002, Alexandre Julliard wrote:
Greg Turner gmturner007@ameritech.net writes:
I like this theory, it has recently occured to me too. I will try compiling the sample using stdcall and see if that has an effect, after work. Also, in the winelib version, I changed main() to stdcall from cdecl (!) which I took to mean that winelib framework didn't want that calling convention.
It's not an stdcall/cdecl issue, Ove is right that it's a problem with returning a structure, gcc doesn't do it the same way as msvc. Just change NdrClientCall2 to return a LONG_PTR (it won't be 100% source compatible then, but we have no choice I'm afraid).
Hmm. Maybe it's possible to do something in the fashion of
LONG_PTR RPC_VAR_ENTRY NdrClientCall2( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING pFormat, ... ); #ifndef __WINE__ #define NdrClientCall2 (CLIENT_CALL_RETURN)NdrClientCall2 #endif
to gain source compatibility.
something like that should work... presumably we want to discriminate against msvc/gcc not wine/no-wine, right? Should I do something like this?
./include/commctrl.h-438-#if defined(__GNUC__) ./include/commctrl.h-439-# define PROGRESS_CLASSW (const WCHAR []){ 'm','s','c','t','l','s','_', \ ./include/commctrl.h-440- 'p','r','o','g','r','e','s','s','3','2',0 } ./include/commctrl.h:441:#elif defined(_MSC_VER) ./include/commctrl.h-442-# define PROGRESS_CLASSW L"msctls_progress32" ./include/commctrl.h-443-#else ./include/commctrl.h-444-static const WCHAR PROGRESS_CLASSW[] = { 'm','s','c','t','l','s','_', ./include/commctrl.h-445- 'p','r','o','g','r','e','s','s','3','2',0 }; ./include/commctrl.h-446-#endif
what is The Right Thing To Do if neither __GNUC__ nor _MSC_VER are defined in this case?