Re: mkshortcut (cygutils-1.4.14) free error

[Mark Geisert <mark at maxrnd dot com>]

Anthony Heading writes:
> > The second issue with the non-absolute path is more problematic.
> > Without your second patch, I do see the issue but only on the 2nd or
> > later invocation. In other words, if the xyzzy.lnk file does not
> > initially exist, the command 'src/mkshortcut/.libs/mkshortcut xyzzy'
> > works and does create the link file. Another invocation then shows the
> > error. Is it simply mis-reporting that there's an existing link file?
> 
> Yes. The hint in the error message is unhelpful I think, since a missing
> directory is only one of a myriad of possible errors. As you note, an
> existing link prompts the same message.

Re the unhelpful hint, I was considering removing the guess it's making or
substituting something more generic.  I'm not sure it would help.  If
there were some way to get the underlying Windows error code we might be
able to map it to an errno but that seems like it might not be robust.  If
we only have OLE/COM error codes like the "E_FAIL" for an existing link
file, it seems hopeless.  I'll probably leave the error message text as-is
for now.
 
> On the build I made on Windows 10, however, I hit the problem on the
> very first invocation. I imagine you therefore are building on Windows 7
> or earlier, which seems to produce binaries that work OK.

Yes, I'm building on Windows 7, 64- and 32-bit as well as Windows XP.  No
plans at present to upgrade but I might need to consider VMs to test later
Windows versions.

> As I said, I
> suspect this is because IPersistFile::Save has changed semantics, e.g.
> per this link:
>
https://msdn.microsoft.com/en-us/library/
windows/desktop/hh848036%28v=vs.85%29.aspx
> 
> I haven't verified this;  I don't know how why or whether gcc is
> volunteering the executable to run in Windows 8 mode, or if there's a
> manifest in some dll library stub, or whether the COM ID of the
> IPersistFile interface is redirected by newer headers, or any similar
> variant of Windows black magic,  but it seems to me like a good guess.

I'll happily defer to your understanding of Those Black Arts :).
 
> If you're going to stay building on Windows 7 then, I don't think this
> latter patch is needed,  although it's hopefully harmless.  But I guess
> without it the code will silently break when Windows 8 or newer comes
> into the picture.

I think we should take advantage of the detective work you've done and
patch as you've suggested.  I'll add a comment to the effect that it's for
a specific Windows behavior change seen after Windows 7.  I'll add a link
to that MSDN page if our coding/doc conventions allow for that.

Thanks again for your patient and detailed help on this!

..mark




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple