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. > > >