As far as you (and your program) are concerned, the BPL's are loaded into your address space and there's no mixing with any other application that happens to use the same BPL's at the same time. BPL's are treated just as DLL's are. Just because all windows applications use COMCTRL32.DLL it doesn't mean that any application may change memory in any other application.
Unless you're using some kind of inter-process communication, there's no way for BPL's in different processes to touch each other. AFAIK on the operating system part there might be more to this. I think DLL's (and BPL's) are memory-mapped so the code segments only occupy physical RAM once, no matter how many different processes are using the same DLL. There might be some kind of copy-on-write mechanism in place just in case one process decides to write over the executable code from one of its DLL's - but then again, that "write" would be completely invisible to any other process using the same BPL. -- Cosmin Prund > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Darren McBride > Sent: 18 iulie 2007 11:25 > To: 'Borland's Delphi Discussion List' > Subject: Packages and memory use > > Folks, > > I have an application that utilises separate packages for different > aspects > of my application. Sometimes I get random access violations when it > appears > that the only logical possibility is that, when running two instances > of the > application, the packages from the first application instance appear to > corrupt memory addresses in the second application instance. I am not > using > FastMM or anything (maybe I should) and am still using Delphi 6. Am I > right > in assuming that separate instances of the BPL's are loaded into > separate > memory addresses for each application instance ? Is there anything else > I > can use to trace the problem ? > > I am very careful is using Assigned() when clearing objects and doing > everything by the book in my constructors and destructors. > > Thanks in advance, > Darren > > > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
