cc3250mt / borlndmm

[Malcolm Smith]

I understand that (for BCB5) cc3250mt is the RTL and borlndmm is the memory
manager.

I'm curious if there are potential cause for problems if some inhouse
runtime packages use the RTL and others don't - which are used by several
DLL's and Exe's (which themselves may have different combinations of using
RTL and/or dynamic/static linked).

I'm currently trying to resolve a problem in a project where I'm receiving
an AV in cc3250mt when attaching an event sink to a COM server (it was
working last week). The project consists of an exe, a COM DLL and dozens of
runtime packages. I was cleaning up the various projects to make sure their
settings were consistent but now things are broken (the AV) and I cannot
work out which change caused the problem. I've reviewed the current
projects with the previous but I cannot see any major differences.

--
Malcolm Smith
MJ Freelancing
http://www.mjfreelancing.com

Associate Editor
C++Builder Developers Journal
http://www.bcbjournal.com

[Craig Farrell]

Hi,

One issue to be aware of, is "two different RTL's"
(a CodeGuard warning) in one process. While that
can be OK, if resources are allocated in one RTL
and freed in another it can be dangerous. If the
exe, and all the pacakges link to the RTL dynamically,
then there will only be one RTL loaded in that
process space.

--Craig

[Paul at NCF]

Hi,

I have to date only used static linked libraries in EXEs and DLLs and don't
have any problems. This does mean that EXEs and DLLs look large, but in
reality, is it really going to take that much longer to load in to memory,
or take up more memory than dynamically loading all DLLs and BPLs?

With BCB DLLs you should't load and unload them all the time as the BCB
architecture leaks. So the safe option is to load the DLL at the main
application memory point so there is always a dummy handle instance in scope
for the process life (the rest of the s/w architecture can load and unload
with it actually doing so).

Passing data back between the DLLS has to be managed carefully. I've
provided "free memory" functions in the DLL interface so that memory
allocated in the DLL and returned to the caller (EXE), can also be released
by and in the DLL.

Hope this helps.

Regards,

Paul

"Malcolm Smith" <mjfree...@optusnet.com.au> wrote in message
news:46d6...@newsgroups.borland.com...