MS OLE questions

[Mike Hearn]

OK, so I applied (as opposed to merged) the ole32.dll parts of the
patch, but I can't figure out why it won't compile.

It seems that I'm missing a #define somewhere that is needed for the
basic types to be defined, example errors are:

In file included from ../../include/rpcproxy.h:31,
                 from dcom_p.c:20:
../../include/winnt.h:296: parse error before "BOOLEAN"
cc1: warnings being treated as errors
../../include/winnt.h:296: warning: type defaults to `int' in
declaration of `BOOLEAN'
../../include/winnt.h:296: warning: type defaults to `int' in
declaration of `PBOOLEAN'
../../include/winnt.h:296: warning: data definition has no type or
storage class
../../include/winnt.h:355: parse error before "LCID"
../../include/winnt.h:355: warning: type defaults to `int' in
declaration of `LCID'

I've tried doing a, for instance, #define __WINE__ but no cigar.

The first line it chokes on, is:

typedef BYTE            BOOLEAN,    *PBOOLEAN;

I can't see where BYTE is declared actually, but it compiled before.

I vaguely recall a mention of some define to import the wine types that
you weren't sure was needed any more, but I don't recall its name :(

Has anybody got any ideas?

On Tue, 2003-07-15 at 13:34, Ove Kaaven wrote:
> tir, 15.07.2003 kl. 12.38 skrev Mike Hearn:
> > Another question (sorry ;) - is it possible to only merge the parts that
> > touch ole32.dll, and continue to use native oleaut32 and rpcrt4?
> 
> I'm not sure. I'd expect native rpcrt4 (at least the NT/2000 versions of
> it) to do some stuff that Wine doesn't support, like NT LPC ports (which
> is a kernel feature exported by ntdll, and as far as I know this is not
> implemented in wine). Perhaps the win95/98 version of rpcrt4 has a small
> chance of working.
> 
> > ie, basically - how many crosscalls are there between wine code in
> > ole32, oleaut32, rpcrt4 - do your patches that add inter-thread
> > marshalling depend explicitly on your typelib marshaller?
> 
> oleaut32 and ole32 has in theory completely independent marshallers, you
> can use any combination as long as they use compatible transports, in
> this case that both use rpcrt4's dcom stuff. So you can use Marcus's
> oleaut32 code (as long as you adapt it for RPC), it doesn't matter for
> ole32. Though you probably can't use native oleaut32 with builtin
> rpcrt4, because like I mentioned earlier, the core of the typelib
> marshaller should have been in rpcrt4, and that's where native oleaut32
> expects it to be. And as you may have noticed, native ole32 uses a lot
> of undocumented rpcrt4 features that I haven't figured out the exact
> behaviour of.
> 
> So I guess it looks a bit grim for running any of them native, but I
> suppose you could experiment.
> 
> 
>