Marcus Meissner marcus@jet.franken.de writes:
From: Sebastian Lackner sebastian@fds-team.de
Signed-off-by: Sebastian Lackner sebastian@fds-team.de Signed-off-by: Marcus Meissner marcus@jet.franken.de
dlls/oleaut32/tmarshal.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-)
The existing code is ugly, and instead of trying to retrofit 64-bit support into it, I'd suggest looking into reusing the rpcrt4 routines which already handle pretty much all of this in a more correct way.
On Mon, Nov 06, 2017 at 07:36:26PM +0100, Alexandre Julliard wrote:
Marcus Meissner marcus@jet.franken.de writes:
From: Sebastian Lackner sebastian@fds-team.de
Signed-off-by: Sebastian Lackner sebastian@fds-team.de Signed-off-by: Marcus Meissner marcus@jet.franken.de
dlls/oleaut32/tmarshal.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-)
The existing code is ugly, and instead of trying to retrofit 64-bit support into it, I'd suggest looking into reusing the rpcrt4 routines which already handle pretty much all of this in a more correct way.
I will try to take a look, but I do not see the approach to take yet. We would need to map typelib trees to midl codes/ ndr call trees to be able to handle this?
Also please consider my original fix, where I just turned a crashing test into a regular fail:
https://source.winehq.org/patches/data/138221
Ciao, Marcus
Marcus Meissner marcus@jet.franken.de writes:
On Mon, Nov 06, 2017 at 07:36:26PM +0100, Alexandre Julliard wrote:
Marcus Meissner marcus@jet.franken.de writes:
From: Sebastian Lackner sebastian@fds-team.de
Signed-off-by: Sebastian Lackner sebastian@fds-team.de Signed-off-by: Marcus Meissner marcus@jet.franken.de
dlls/oleaut32/tmarshal.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-)
The existing code is ugly, and instead of trying to retrofit 64-bit support into it, I'd suggest looking into reusing the rpcrt4 routines which already handle pretty much all of this in a more correct way.
I will try to take a look, but I do not see the approach to take yet. We would need to map typelib trees to midl codes/ ndr call trees to be able to handle this?
Yes, you'd want to generate format strings for the typelib.
If that's not feasible for some reason, we can look into sharing the implementation; but obviously making use of exported APIs is preferable.
On Tue, Nov 07, 2017 at 08:40:34AM +0100, Alexandre Julliard wrote:
Marcus Meissner marcus@jet.franken.de writes:
On Mon, Nov 06, 2017 at 07:36:26PM +0100, Alexandre Julliard wrote:
The existing code is ugly, and instead of trying to retrofit 64-bit support into it, I'd suggest looking into reusing the rpcrt4 routines which already handle pretty much all of this in a more correct way.
I will try to take a look, but I do not see the approach to take yet. We would need to map typelib trees to midl codes/ ndr call trees to be able to handle this?
Yes, you'd want to generate format strings for the typelib.
If that's not feasible for some reason, we can look into sharing the implementation; but obviously making use of exported APIs is preferable.
Implementing rpcrt4.Create(Proxy,Stub)FromTypeinfo() should give us what we need. That's an ugly solution in itself, but at least we're not proposing it.
Huw.
-
Alexandre Julliard -
Huw Davies -
Marcus Meissner