Re: shell32 patch 12

[Mike McCormack]

This patch broke the installation of IE6.

When running the command below during installation of IE6, a pathname is 
scribbled over the stack...

C:\windows\inf\unregmp2.exe /Shortcuts /IE5 /RegExts

Any ideas why?

Mike

Martin Fuchs wrote:
> This patch is based on work of Ge van Geldorp  and me.
>
> Changelog:
> reimplementation of SHGetPathFromIDListA/W() using the new helper
> functions SHELL_GetPathFromIDListA/W(). The new implementation avoids to
> use IShellFolder::GetDisplayNameOf(), so that it behaves like the following:
> - return the absolute file system path, not relative to the dekstop
> - return FALSE as error code if the path can not converted in a valid file system path
> - don't return virtual CLSID paths
>
> Note:
> The two helper functions will we called from other places in following patches, so they
> are declared in the header file.

shell32 patch 12

[Martin Fuchs]

Hello,
> > This patch broke the installation of IE6.
> >
> > When running the command below during installation of IE6, a pathname is 
> > scribbled over the stack...
> >
> > C:\windows\inf\unregmp2.exe /Shortcuts /IE5 /RegExts
> >
> > Any ideas why?

I see you found and could solve the problem.
If I understand correctly, this says, this part of IE installation uses PIDLs,
which are illegal in some way?
Is this the normal behaviour or only result of for example some
mis-convifured registry entries?

Thanks,

Martin

shell32 patch 12

[Mike McCormack]

Martin Fuchs wrote:
> I see you found and could solve the problem.
> If I understand correctly, this says, this part of IE installation uses PIDLs,
> which are illegal in some way?
> Is this the normal behaviour or only result of for example some
> mis-convifured registry entries?

Actually, I added the ERR("pidl is borked\n") to detect the case where 
the PIDL itself was invalid, but that error message never shows.  I 
haven't found the exact reason for the original problem, but the code I 
wrote to avoid buffer overruns fixes the problem.

It's hard to find the original problem as using a +relay trace makes it 
magically disappear.  Perhaps initializing the buffer to a nul string 
also helps?

Mike