On Tuesday 15 October 2002 12:07 pm, Ove Kaaven wrote:
> On 15 Oct 2002, Alexandre Julliard wrote:
> > Greg Turner <[EMAIL PROTECTED]> 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?
--
gmt
"It has been well said that really up-to-date liberals
do not care what people do, as long as it is compulsory."
-George F. Will
