yang686526

naming convention of dlls cause problems
naming convention of dlls cause problems
we have (in 1.12 vs 2003) run into problems when testing our apps using the toolkit: the debug and release dlls have the same names but a debug build of our program cannot use the toolkit release dlls and vice versa. that is; no error message, just a gp and great confusion for the testers and developers.
i also have the following consern regarding using the same dll name across versions of the toolkit:
program from vendor a installs 1.12 release dlls.
program from vendor b installs 1.13 release dlls and overwrites the 1.12 dlls.
if the 1.13 dlls are not 100% backward compatible with 1.12, then the program from vendor a will break. i suspect this will be a problem for vendor a's support to detect and solve for the user.
are these problems considered?
is there a solution for this?
if this is not a deliberate design decision; could you consider having different dll names based on debug/release and version?
-rune jorgensen
www.dds.no
>program from vendor a installs 1.12 release dlls.
>program from vendor b installs 1.13 release dlls and overwrites the 1.12 >dlls.
it seem to be highly improbable that programs from different vendors are installed in the same location
i think no reasonable vendor installs libraries in system folders anymore
you could use the static lib files instead of linking into the dll's. that way you don't have to ship any of the dll's, but the cost is that your application will become quite large.
quote:
... but the cost is that your application will become quite large.
exactly. and loading time will increase too, because about half of the dlls are loaded dynamically on demand.
(most of the new functionality is coming as drx modules now)
quote:
originally posted by rune jørgensen
the debug and release dlls have the same names but a debug build of our program cannot use the toolkit release dlls and vice versa. that is; no error message, just a gp and great confusion for the testers and developers.
hi,
rune, and could you debug into the crash, and see what is in the call stack ?
(in case you're interested in using mixed release-debug builds)
quote:
originally posted by dmitry a. novikov
hi,
rune, and could you debug into the crash, and see what is in the call stack ?
(in case you're interested in using mixed release-debug builds)
in dd1.12 i had problems with memorymanagment by using dd release with our debug dlls.
we are using following name conventions :
name+ versionnumber + d for debug dlls/libs.
may be it´s a solution for dd.
> in dd1.12 i had problems with memorymanagment
> by using dd release with our debug dlls.
that is our experience as well. the heap seems to get corrupted when mixing dd release dlls with ms debug msvcr71d.dll.
msvcr71d.dll!_crtisvalidheappointer(const void * puserdata=0x01f93580)
msvcr71d.dll!_free_dbg_lk(void * puserdata=0x01f93580, int nblockuse=1)
msvcr71d.dll!_free_dbg(void * puserdata=0x01f93580, int nblockuse=1)
mfc71d.dll!operator delete(void * p=0x01f93580)
mfc71d.dll!operator delete[](void * p=0x01f93580)
it will not break like this if we use the dd release dlls with ms release dlls or dd debug dlls with ms debug dlls. note that ms themselves use version number in the dll name and add a d if it is a debug dll to avoid a mix of incompatible dlls to be loaded.
-rune jorgensen
www.dds.no
quote:
..
mfc71d.dll!operator delete(void * p=0x01f93580)
mfc71d.dll!operator delete[](void * p=0x01f93580)
and what is further up the stack?
i mean - what object is being deleted?
quote:
originally posted by wvk
and what is further up the stack?
i mean - what object is being deleted?
that´s our answer from vladimir kalinin
in 1.12 we overloaded new/delete operators,
and it seems that compiler used our "new" in first dll
and crt "delete" in the second.
there are some oddities in debug allocation routines in vc++,
and is better not to mix debug and release dlls when new/delete are
overloaded.
but in the future we will take this scenario into account.
perhaps in 1.13 this will work immediately,
because we were fixing some connected issues,
debugging our new custom memory management.
1.13 is being released just now (tomorrow perhaps).
best regards,
vladimir kalinin
well, i didn't say this scenario is not working at all, it just requires more attention to memory management issues. and, as i said, in 1.13 we fixed a lot of connected problems, debugging our custom heap.
after all, our samples are working in debug mode, being linked with release dlls. i do not say that our samples are as complex as real applications, but there are illustrated a lot of techniques, and memory is used extensively enough.
so, it seems that this problem can be fixed, but anyway, to fix the issue, we need more info.
of course if it will appear that this is not dd bug, and is not obvious client bug, then renaming dlls should be discussed/considered.
vladimir
if the intention is that dd release dlls should actually work with ms debug dlls and vice versa, then i will try it out with 1.13 first. then i can dig into debug details if it still fails.
-rune jorgensen
www.dds.no
at least it is not intended that they should not
vladimir

i've now tested dd 1.13 with visual studio 6.0. here dd debug dlls can be used with our release build and vice versa.
-rune jorgensen
www.dds.no