oleaut32 patch

[Gregory M. Turner]

On Tuesday 22 April 2003 10:39 am, Ove Kaaven wrote:
> tir, 22.04.2003 kl. 06.02 skrev Alexandre Julliard:
> > Ove Kaaven <ovek at arcticnet.no> writes:
> > > The oaidl_p.c is almost unmodified MIDL output generated from Wine's
> > > oaidl.idl (I only had to add an #undef __WINE__ at the top to get all
> > > the Winelib definitions, perhaps this isn't needed under Wine anymore),
> > > so it shouldn't be hard to maintain, and Alexandre once said MIDL
> > > output is acceptable as a stopgap solution. I don't know if proper
> > > InstallShield repaint support calls for stopgaps, though.
> >
> > One problem is that this code causes hundreds of warnings, and I don't
> > think that's acceptable (it also fails to link but that could be fixed
> > by adding a few stubs).

Couldn't those be fixed by tweaking our headers a bit?  I seem to recall being 
able to imagine ironing those out... well, I guess I need to reapply this 
patch and go over it to give a meaningful opinion.

> Hmm, the stub functions in usrmarshal.c was enough for me when I tried.
> What stubs are missing?

I forget, again, but I experienced this too against cvs as of a couple of days 
ago.

> And yeah, I know it causes a lot of warnings, but I thought that it
> might be a reasonable tradeoff since it won't stay there forever.
>
> > We could fix the warnings manually but that
> > will cause obvious maintenance problems. How far are we from being
> > able to generate that with widl?
>
> Not all that close I'm afraid. I think it might be easiest to make widl
> emit stubless (rpcrt4-interpreted bytecode) marshallers than the
> old-fashioned inline marshallers 

Indeed, it probably would... I gravitate to the depreciated /Oi versions 
because I imagine they will provide a nice guideline as to how to implement 
the stubless versions... but I get the impression you have delved into this 
more deeply than I, Ove, so I'm happy to defer to your judgement (not that 
I'm the gatekeeper here anyhow ;) )

Will try to take a look this weekend and see if I have any coherent thoughts 
on the subject ;)

> (hardcoded function tables, which look
> like a nightmare to generate)
> but wine's dlls/rpcrt4/ndr_stubless.c is
> still just a stub... 
> so the bytecode interpreter would have to be
> implemented also (but of course that has to be done eventually anyway,
> stubless proxies are better according to MS, so many apps will use
> them). It'll probably take a few weeks for me at least, since the stuff
> I do have works, and thus its priority is lower... but I can try if
> you're willing to wait a bit.

-- 
gmt

"Democracy is the theory that holds that the common people know
what they want, and deserve to get it good and hard." HL Mencken