Mike Hearn wrote:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_robust.asp
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
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/_robust.asp
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:
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/_robust.asp
Rob
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? Or are we talking about different
things ...
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
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
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 cod
Mike McCormack <[EMAIL PROTECTED]> 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 pointe
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 wi
Mike McCormack <[EMAIL PROTECTED]> 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
[EMAIL PROTE
10 matches
Mail list logo