[Wine] Couple DLL problems

[Gert van den Berg]

On Tue, Mar 10, 2009 at 1:03 AM, vitamin <wineforum-user at winehq.org> wrote:
>
> Gert van den Berg wrote:
>> Is there any way to checking whether this (A DLL with the same name as
>> a "standard" one in die application directory is trying to load the
>> DLL from its normal location) is what happens? (If I do not have
>> access to the source code if the DLL)
>
> Wine always prefers it's own (built-in) dlls over natives except for few "stub" dlls - mostly placeholder dlls.
>
> This is done on purpose. And all discussions about changing that lead to - "yes we want it that way for number of reasons (....)". And there are even bugs filed for apps that have their own dll with the name identical to the built-in. But the dll have nothing to do with each-other. So the app crashes trying to use wrong dll. Same for Office 2005+ and it's "special" riched32.dll.
>
A third mode, emulating Windows' behaviour would be nice...
(native,builtin is fine for the riched issues, but something that
works for wrappers would be nice as well) Convincing the maintainers
that it is needed would be another story altogether. (I saw the thread
on wine-devel about the riched DLL's for Office)

As for the wscok wrapper: It seem that it might be completely based in
ws2_32 (which strangely enough gets loaded before wsock32 from loadll
output... I based this on strings output, which might not be the best
source, especially taking into account my lack of understanding of
interenal DLL structure) which might remove the need for a hack that
involves renaming the DLL

> So in short - no it won't be fixed any time soon. You have to hack Wine/wrapper dll to make it do what you want. And if you don't have source - well you can hack it with hexedit :-)
>