[Wine] Re: Found the patch that breaks my app. Now what?

[roboknight]

Daniel Skorka wrote:
>
> Wow, you really seem to have spent quite some time on this; good work
> too. I (and propably most of us here) do not really feel qualified to
> answer your question about a workaround to this, were are mostly users
> ot developers after all. However, right at the end of the bug comments
> there's one saying that native shdocvw works. Is that an option for you?
>
> Daniel

Thanks.  I've been working hard at this because, if I want it fixed,
I've got to do the majority of the work.  I am just now at a point
where I don't understand enough what is causing the crash to really fix
it without making it worse, so I figured maybe other users might see
something like this.  It didn't seem appropriate for a developers forum
until I at least tried to fix it myself.

At any rate, it works to a point.  It won't ever display the list of
caches (there are 41 in a default database) or anything.  Eventually it
runs into a shell fixme that is labelled "semi-stub" which I think
kills it.  I have to check some real debug output to be sure as I was
just doing a quick test this morning, but it doesn't really appear
work.  Louis Lenders suggested both native SHDOCVW.DLL and SHLWAPI.DLL,
but when I add SHLWAPI.DLL, it crashes.  I'm unsure why there.  Maybe
he's using a different version of wine.  I was using a compiled version
from about a day or so ago (although I've tried many others).

At this point, my problem appears to be that I can not determine WHAT
that functionality that was provided by the old dependence on the
Mozilla ActiveX control really did for my application.  Whatever it
was, the messages that get sent to shdocvw.dll either don't get sent or
are properly handled elsewhere and it worked... If I have to, I'll make
a temporary patch for my use until I don't need it, but it seems kind
of a hollow solution working against moving wine toward its goals.
Plus I'd have to keep reapplying the stupid thing until I found I
didn't need it anymore.  Also, I don't know if there are any other apps
that experience this (I suspect not since GSAK appears to be the first
to come up against it), but it would be better if NO other apps
experienced it.

There is one thing I thought of that could be a problem with my using
native DLLs and that is the source.  I was wondering if there was a
well known, safe source, for win2k, win98, and win95 dlls.  I run win2k
and can get DLLs from there, but I figure it might be a good idea to
attempt to use the same DLLs as others using wine use (maybe everyone
else is using native '98 DLLs for example).  Anyway, I'm unsure if
people are using win95 DLLs or win2k DLLs by default now when they use
native DLLs.  There doesn't seem to be a reference on that point.  So I
figure someone who's been using native DLLs might let me know.

Thanks to those who have steered me to where I am at thus far.  If I do
get a viable workaround, be sure it will be posted prominently so
others may benefit from the results as this seems to be a real bugger
for GSAK.