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.