Comment 79 for bug 205895

(In reply to comment #16)
> Granted, ies4linux is present, but it is a constant factor and the variable
> factor is wine. Therefore, in this limited case, the change in wine can be said
> to produce the bug.
>
> I recognize you are saying there may be a deeper issue, but step 3 indicates
> that there is not an easy alternative to doing what I did. Therefore, may I
> suggest that looking into the bug reported by Brandon Koepke is worthwhile?
>
> I do not have the skill to write a test case as you suggest. My personal
> problem is solved; therefore, I am investing the time in responding in the hope
> of clarifying this issue for others. I cannot do more than describe my
> experiences in detail. I will be glad to answer more questions, if that helps.
> I'll even run additional tests with different methods of installing ie6 + 128
> bit encryption if someone wants to point me in the right direction. (I think
> winetricks ie6 might work if I could get all the required encryption DLLs
> registered, but I have not been able to do that on my own.)
>
It's certainly possible that there's a bug in Wine, perhaps even likely, but the problem is that adding native dll's (especially as many as ies4linux does) creates a configuration that really isn't supportable by us. In a way you could compare it with mixing dlls from different Windows versions and hoping to get a working system. You create potentially invalid interactions between the native dll's and the builtin ones.

Another reason why a configuration like that isn't useful for reporting bugs is that we can't/don't want to look at what those native dlls do exactly, because Wine has to implement those same dlls.

Bottom line is that for us to do something about it the bug has to be reproducible, one way or another, without using native dll's.