«

Hello,
Recently we've upgraded to use MsDev 2008 for our code (until now
we've used MsDev 2005).

Unfortunately we are using some 3rd party DLLs that were build in
MsDev 2005, and there are a few methods in those DLL that are
allocating memory, which I as a client need to free. I have no control
of them, so I cannot change the interface or the way memory
allocations work, nor is there a way for us to recieve these DLLs
build with MsDev 2008. There are also some places where allocations
are done on our side and are freed by their DLL (I know this is bad
exercise, but that's they way the 3rd party enforces....)

As you can guess - our software crashes because of this mixture
(memory allocations are done with MSVCR80 and freed with MSVCR90, or
viceversa, causing different heaps to be used...).
My question: Is there a way to enforce the 3rd party DLL to use the
same heap (i.e. use MSVCR90) as my software? I'm really lost...


BTW - I've investigated it and I must add that even there was no cross
memory allocation/deallocation, there are still problems when running
with several heaps - if memory is not freed (and say that it is still
used, no leak), then each page taken by a heap is not available for
the other heap. So if the other DLL needs a lot of space at some point
and frees most of it, but still takes many pages, my main program is
left with less available heap then expected.

* Yuval Steinberg, on 16.09.2010 22:41:
> Hello,
> Recently we've upgraded to use MsDev 2008 for our code (until now
> we've used MsDev 2005).
>
> Unfortunately we are using some 3rd party DLLs that were build in
> MsDev 2005, and there are a few methods in those DLL that are
> allocating memory, which I as a client need to free. I have no control
> of them, so I cannot change the interface or the way memory
> allocations work, nor is there a way for us to recieve these DLLs
> build with MsDev 2008. There are also some places where allocations
> are done on our side and are freed by their DLL (I know this is bad
> exercise, but that's they way the 3rd party enforces....)
>
> As you can guess - our software crashes because of this mixture
> (memory allocations are done with MSVCR80 and freed with MSVCR90, or
> viceversa, causing different heaps to be used...).
> My question: Is there a way to enforce the 3rd party DLL to use the
> same heap (i.e. use MSVCR90) as my software? I'm really lost...
>
>
> BTW - I've investigated it and I must add that even there was no cross
> memory allocation/deallocation, there are still problems when running
> with several heaps - if memory is not freed (and say that it is still
> used, no leak), then each page taken by a heap is not available for
> the other heap. So if the other DLL needs a lot of space at some point
> and frees most of it, but still takes many pages, my main program is
> left with less available heap then expected.

If you ask in an on-topic group I'm sure somebody will outline how to link your
main code with MSVCR80 instead of MSVCR90.

As a stopgap measure you can just implement a DLL that uses MSVCR80 (runtime
DLL) and provide allocation and deallocation operations.

For a longer perspective, stop using badly designed 3rd party software.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

Yuval Steinberg <>, on 16/09/2010 13:41:24, wrote:

> Hello,
> Recently we've upgraded to use MsDev 2008 for our code (until now
> we've used MsDev 2005).
>
> Unfortunately we are using some 3rd party DLLs that were build in
> MsDev 2005, and there are a few methods in those DLL that are
> allocating memory, which I as a client need to free. I have no control
> of them, so I cannot change the interface or the way memory
> allocations work, nor is there a way for us to recieve these DLLs
> build with MsDev 2008. There are also some places where allocations
> are done on our side and are freed by their DLL (I know this is bad
> exercise, but that's they way the 3rd party enforces....)
>
> As you can guess - our software crashes because of this mixture
> (memory allocations are done with MSVCR80 and freed with MSVCR90, or
> viceversa, causing different heaps to be used...).
> My question: Is there a way to enforce the 3rd party DLL to use the
> same heap (i.e. use MSVCR90) as my software? I'm really lost...
>
>
> BTW - I've investigated it and I must add that even there was no cross
> memory allocation/deallocation, there are still problems when running
> with several heaps - if memory is not freed (and say that it is still
> used, no leak), then each page taken by a heap is not available for
> the other heap. So if the other DLL needs a lot of space at some point
> and frees most of it, but still takes many pages, my main program is
> left with less available heap then expected.

Well, you have some chance to get sensible help here, although you're
way off topic - yours is a very platform/implementation specific issue,
nothing to do with C++ as /language/, which is what this group focuses on.

I can only wish you good luck and suggest you to start looking for an
appropriate group or forum that focuses on your platform &&
implementation, to increase the chances to get effective help.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com

Thanks for the quick answer. SOme but some inline response

> If you ask in an on-topic group I'm sure somebody will outline how to link your
> main code with MSVCR80 instead of MSVCR90.
I'm not sure I understood this answer..
>
> As a stopgap measure you can just implement a DLL that uses MSVCR80 (runtime
> DLL) and provide allocation and deallocation operations.
That's what we have been doing so far, though I don't like it. As I
said, there is still a downside of memory fragmentation caused by it
(that is build-in such a solution and should not be overlooked), and I
would really want to know if there is a way to force that 3rd party to
run with the same heap.

>
> For a longer perspective, stop using badly designed 3rd party software.
Perhaps you're correct, but this is not an option in this case. This
is a client DLL that implements private protocols for communicating
with their server. That is the game I have to play and I can't change
the rules.
>
> Cheers & hth.,
>
> - Alf
>
> --
> blog at <url:http://alfps.wordpress.com>

On Sep 16, 10:41*pm, Yuval Steinberg <yuval.steinb...@gmail.com>
wrote:
> Hello,
> Recently we've upgraded to use MsDev 2008 for our code (until now
> we've used MsDev 2005).
>
> Unfortunately we are using some 3rd party DLLs that were build in
> MsDev 2005, and there are a few methods in those DLL that are
> allocating memory, which I as a client need to free. I have no control
> of them, so I cannot change the interface or the way memory
> allocations work, nor is there a way for us to recieve these DLLs
> build with MsDev 2008. There are also some places where allocations
> are done on our side and are freed by their DLL (I know this is bad
> exercise, but that's they way the 3rd party enforces....)

Question has already been answered, I'll just add that original
project management failure is that you have libraries that effectively
tie you into use of an eventually obsolete toolchain. It's possible
that you had no dealing whatsoever in that decision, but I kinda feel
this should be said.

Goran.