please don't apply RPC Merge D_PL1

Greg Turner gmturner007 at
Tue Oct 15 12:30:21 CDT 2002

On Tuesday 15 October 2002 12:07 pm, Ove Kaaven wrote:
> On 15 Oct 2002, Alexandre Julliard wrote:
> > Greg Turner <gmturner007 at> 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
>   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-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 };

what is The Right Thing To Do if neither __GNUC__ nor
_MSC_VER are defined in this case?


"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

More information about the wine-devel mailing list