Post by Boba
Dear All; here is what I can't figure out and need your
helpful advice on: when my user application starts, it
dependants (system DLLs) get loaded (if needed) and they
get mapped in. When this takes place, how do I control the
standard sequence of the file search used by the loader?
For instance, if a copy of some system DLL happens to exist
in my application's folder or in the current directory (both
differ from %windir%\system32), the loader will pick that
copy, but I want it to load the one from %windir%\system32
instead. Thank you in advance. Boba.
Boba, this is really a follow up to my last post. Based on your own
follow up responses, you have the same situation we have and no matter
how much you do, you will always run into one or few people that have
a issue and need your help to resolve it.
For example, we have RPC client/server system with many static dlls,
pluggable, etc. What is common for all clients are:
wcsrv2.dll RPC client server API interface
wcsrv.dll Original, now a backward compatibility module.
We have 3rd party developers and many have written products over the
years that many customers still use that the old WCSRV.DLL interface.
Many install their products on different folders and either:
1) Have the operator put the main product directory on the PATH
2) Automatically copy WCSRV.DLL from the main product directory,
3) Or install an WCSRV.DLL copy they had during production.
Because these older 3rd party products are still useful with the
wcsrv.dll compatibility module that loads the current WCSRV2.dll, if
they have an older WCSRV.DLL, they got a POPUP message saying
SERVER/CLIENT version mismatch problem. Thats because this version
checking was always done since the original version. That logic never
The support buck is passed to us when the 3rd party vendor is no
longer around or hasn't updated his software to link with WCSRV2.DLL.
It doesn't matter, you can try to hook into LoadLibraryEx() and take
control but I don't think that will always solve this.
Honestly, is this a big deal and worth it? No matter what you do,
someone will have mismatched problem.
We should take a lesson from Microsoft when they tried to DO US A
FAVOR by taking control of this issue with the manifest and SxS crap.
That created more problems than it was worth and thank god now got
out of our WAY and don't require it for ISVs :)