From: Vijay Kiran Kamuju <infyquest@gmail.com>
Subject: Re: [PATCH 1/4] oleaut32: Fix TypeLibCount for SLTG_OtherTypeInfo
Message-Id: <CACfa+KKcM=KRsS_Wv_bXBzij86M82Nz3uf2A5EGdqO9yXYe+ew@mail.gmail.com>
Date: Thu, 11 Jun 2020 14:22:16 +0200
In-Reply-To: <20200611115953.GC6484@merlot.physics.ox.ac.uk>
References: <CACfa+KJNj+SMdiXi1Rooy9OJYSk0TCRdaoOOB2SUye5dwVWcaA@mail.gmail.com> <20200611115953.GC6484@merlot.physics.ox.ac.uk>

On Thu, Jun 11, 2020 at 2:00 PM Huw Davies <huw@codeweavers.com> wrote:
>
> On Thu, Jun 11, 2020 at 01:10:43PM +0200, Vijay Kiran Kamuju wrote:
> > Based on patch by Sebastian Lackner <sebastian@fds-team.de>
> >
> > From: Dmitry Timoshkov <dmitry@baikal.ru>
> > Signed-off-by: Vijay Kiran Kamuju <infyquest@gmail.com>
>
> > From f5c2552bae4d0a4c517ef54a8ac2159fdb3cf3ba Mon Sep 17 00:00:00 2001
> > Date: Thu, 11 Jun 2020 12:59:34 +0200
> > Subject: [PATCH 1/4] oleaut32: Fix TypeLibCount for SLTG_OtherTypeInfo
> >
> > Based on patch by Sebastian Lackner <sebastian@fds-team.de>
> >
> > From: Dmitry Timoshkov <dmitry@baikal.ru>
> > Signed-off-by: Vijay Kiran Kamuju <infyquest@gmail.com>
> > ---
> >  dlls/oleaut32/typelib.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c
> > index f8d7136834..1f2c6e182c 100644
> > --- a/dlls/oleaut32/typelib.c
> > +++ b/dlls/oleaut32/typelib.c
> > @@ -4472,6 +4472,8 @@ static ITypeLib2* ITypeLib2_Constructor_SLTG(LPVOID pLib, DWORD dwTLBLength)
> >      len += 0x40;
> >
> >      /* And now TypeInfoCount of SLTG_OtherTypeInfo */
> > +    pTypeLibImpl->TypeInfoCount = *(WORD *)((char *)pLibBlk + len);
> > +    len += sizeof(WORD);
> >
> >      pOtherTypeInfoBlks = heap_alloc_zero(sizeof(*pOtherTypeInfoBlks) * pTypeLibImpl->TypeInfoCount);
>
> It's more complicated than that.  ->TypeInfoCount is set earlier on,
> should that be changed to a local variable or something?
Yes, I think that this complicates complete constructor implementation.
As the TypeInfoCount is used in a lot of places.
I have to test by moving to a local variable, I believe this may lead
to crashes.
>
> Also, there are still bits on [2/4] that aren't do to with help
> strings, e.g. the small_no and typekind change, and all the offset
> renumbering.
Should I send the patch for small_no, typekind change first, which
also affects the offset renumbering.
I can send you the old NE tlbs which I got from DDKs, which I use for testing.
>
> Huw.
Vijay.