Ove Kaaven ovek@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). 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?
tir, 22.04.2003 kl. 06.02 skrev Alexandre Julliard:
Ove Kaaven ovek@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).
Hmm, the stub functions in usrmarshal.c was enough for me when I tried. What stubs are missing?
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 (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.
Ove Kaaven ovek@arcticnet.no writes:
Hmm, the stub functions in usrmarshal.c was enough for me when I tried. What stubs are missing?
Things like NdrSimpleTypeMarshall that are declared as stubs in rpcrt4.spec; the new import library mechanism doesn't allow importing stubs. Anyway that's easy to work around.
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.
Well, we can live with a few warnings, but hundreds is a bit too much IMO. But if you don't plan to update that file too often I can hack it to fix the warnings.
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 (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.
Sure, there's no hurry. I'm happy to commit the MIDL-generated stuff in the meantime, as long as the better solution is somewhere in sight.
On Tuesday 22 April 2003 10:39 am, Ove Kaaven wrote:
tir, 22.04.2003 kl. 06.02 skrev Alexandre Julliard:
Ove Kaaven ovek@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.
-
Alexandre Julliard -
Gregory M. Turner -
Ove Kaaven