Why i am not into dll hell???

  • Thread starter Thread starter xkp
  • Start date Start date
X

xkp

From internet i red the following about dll hell.

Shared in-memory code pages
Even if the system DLL is okay, or an application has a working local
copy, if a previous application has started with an incompatible
version, the new application won't work. This can manifest itself
either as "an application doesn't work if a different application is
running", or more mysteriously as "an application doesn't work if a
different application has been run (but needn't be running any
longer)": if app a loads a corrupt or incompatible library, then app b
is launched and uses that library, that version will stay in memory
even after app a exits (so long as app b is still running), so app b
might fail to work because of app a, even though app a is no longer
running. More subtly yet, a third application app c may fail to run
(so long as app b is still running) even if it is started after app a
has exited.

In my case i have two different exe named OLD and NEW, both using a
dll named DLL.
the software OLD, which is older, uses older version of dll DLL, which
is in the same directory of OLD


OLDprogramfolder
OLD.exe
DLL.dll (older)


the software NEW, newer, uses a different version of dll DLL, which is
in the same directory of NEW

NEWprogramfolder
NEW.exe
DLL.dll (newer)


According to theory if i run the OLD program first, it will load
DLL.dll and will work fine, but if i then run NEW without closing OLD,
it will try to use DLL.dd from OLD folder, not loading the new version
of DLL.dll.
Well this is not what actually happens.
If i run "process explorer" i can see that each of the two program,
OLD and NEW, uses its own dll from its folder.
Why this happen?
I need to understand it in order to be sure that it is not just by
chance that both software are working on my machine and they could not
work on others.
Any advice?
Thanks in advance
 
If I understand you correctly, you seem to think that you have a problem
because thing are working the way they are designed to work?
 
If I understand you correctly, you seem to think that you have a problem
because thing are working the way they are designed to work?
Click to expand...
No
i think i have a problem just because things are not going as i have
red they are supposed to go.
I mean, according to theory i should have a conflict (one of the cases
of dll hell) , and i want to be sure i am not having it for a real
reason and not by chance.
 
xkp said:
No
i think i have a problem just because things are not going as i have
red they are supposed to go.
I mean, according to theory i should have a conflict (one of the cases
of dll hell) , and i want to be sure i am not having it for a real
reason and not by chance.
Click to expand...

Your code is working as it should (as Stephany said). I believe you are
taking the artical out of context, such as (possibly) assuming that because
things worked the way the artical describes in COM, they will still work that
way in .Net.

For example, the banner of what you posted says "Shared in-memory code
pages". Are you creating such in both DLLs from within .Net?
 
Hi xkp,

Are these MFC applications? Do you have manifests for your DLLs (either embedded
or external)??

Jigar Mehta
 
Hi xkp,

Are these MFC applications? Do you have manifests for your DLLs (either embedded
or external)??

Jigar Mehta
Click to expand...
Hi Jigar
No they use standars windows libraries,and no manifest embedding.
 
Back
Top