Re: WIDL: use __RPC_FAR attribute for pointers in proxies
Mike McCormack <mike(a)codeweavers.com> writes:
ChangeLog: * use __RPC_FAR attribute for pointers in proxies
Is this really useful? __RPC_FAR will always be an empty define, even when building on Windows, and I doubt we'll want to add 16-bit support to widl... -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
* use __RPC_FAR attribute for pointers in proxies
Is this really useful? __RPC_FAR will always be an empty define, even when building on Windows, and I doubt we'll want to add 16-bit support to widl...
Yes, because it makes it easier to compare the output of midl and widl. Additionally, I hope that projects other than Wine can use widl too one day... Mike
Mike McCormack <mike(a)codeweavers.com> writes:
Yes, because it makes it easier to compare the output of midl and widl. Additionally, I hope that projects other than Wine can use widl too one day...
Frankly I can't think of any project that would need that. It's just historical noise, far pointers have fortunately gone the way of the dinosaur. I'd suggest doing a s/__RPC_FAR// on the midl output before comparison and avoiding it in Wine. In fact we explicitly forbid use of FAR in Wine, and __RPC_FAR should probably be treated the same way. -- Alexandre Julliard julliard(a)winehq.org
Yes, because it makes it easier to compare the output of midl and widl. Additionally, I hope that projects other than Wine can use widl too one day...
Yeah, I'd vote for *not* following the exact output of MIDL in WIDL actually. - MIDL produces code that could compete in the worlds ugliest code competition. - The casts it uses make new versions of gcc cry - There's a lot of junk in there we probably don't need (stubless proxy support etc) I'd rather we produced clean, easily readable Wine style code rather than copying the output of MIDL exactly. The code isn't magic, it should not be difficult to simply compare the meaning of the code if we're not sure it matches up. thanks -mike
Mike Hearn wrote:
Yes, because it makes it easier to compare the output of midl and widl. Additionally, I hope that projects other than Wine can use widl too one day...
Yeah, I'd vote for *not* following the exact output of MIDL in WIDL actually.
- MIDL produces code that could compete in the worlds ugliest code competition.
- The casts it uses make new versions of gcc cry
- There's a lot of junk in there we probably don't need (stubless proxy support etc)
Stubless proxies are the only ones that are secure.
I'd rather we produced clean, easily readable Wine style code rather than copying the output of MIDL exactly. The code isn't magic, it should not be difficult to simply compare the meaning of the code if we're not sure it matches up.
Agreed. Rob
Mike Hearn wrote:
Stubless proxies are the only ones that are secure.
Secure? This is news to me, how is interpretive marshalling more secure than generated code based marshalling?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_... Rob
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_...
Interesting. I wonder how this affects the output. I think we should worry about this sort of thing when our DCOM code is actually mature enough that we can use it, though.
Mike Hearn wrote:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_...
Interesting. I wonder how this affects the output.
It changes the conformance descriptor in the type format string from 4 bytes to 6 bytes.
I think we should worry about this sort of thing when our DCOM code is actually mature enough that we can use it, though.
I should really clean up my NdrClientCall2 work at some point. Rob
Yeah, I'd vote for *not* following the exact output of MIDL in WIDL actually.
I don't want to make WIDL produce exactly the same output as MIDL, but it's nice to have some of the lines line up so it can be compared easily. Mike
participants (4)
-
Alexandre Julliard -
Mike Hearn -
Mike McCormack -
Robert Shearman