cwr,
yes, the shared library is essentially in a read only state. the functions are passed to the application as needed, but never returned. [ the library is only altered when it is recompiled, not during use ]
cwr,
yes, the shared library is essentially in a read only state. the functions are passed to the application as needed, but never returned. [ the library is only altered when it is recompiled, not during use ]
Originally Posted by Jeff Henager
No. It may be true on linux, but not on Windows. On Windows, you have to use a special compiler directive to make the memory shared. For instance, on MSVC you would do:So my statement of "the running applications are not capable of writing to the memory that the shared library lives" was actually correct? I'm confused now.
So if a DLL has the above code, and some exported functions to manipulate the two variables, they will behave differently. Let's say application A links to this DLL and increments both variables. If application B links to the DLL and reads the variable's values, he will see varThatIsNotShared = 0, and someSharedVar = 1.Code:int varThatIsNotShared = 0; #pragma data_seg(".SHARDAT") int someSharedVar = 0; #pragma data_seg() #pragma comment(linker, "-section:.SHARDAT,rws")
Note that this shared memory can be written to by every process depending on the parameters passed to -section.
I think you're getting confused by the dll's image on disk, and it's image in memory. Of course a DLL's disk image can't be altered until it is compiled, but a DLL's memory can be overwritten easily. Not only can you change it's variables, but you can overwrite the export table as well. To the best of my knowledge, there is no part of a DLL's memory that you cannot write to.[ the library is only altered when it is recompiled, not during use ]
Now I start to understand the whole confusion. One of you is talking about the executable code in a dll, the other one is talking about the dlls- data. So both of you are right and wrong.
Yes the code of a dll is in memory only once and gets mapped into multiple application's addressspace. And yes usually there is some data area that belongs to the dll to store some dll-private state-info and that is readonly ( or even not accessible at all ) for applications and yes a dll can have some shared data-area as well that is read/writable by multiple applications simultaniously.
Kurt
Who is talking about executable code? I thought the OP wanted to know if his dll's data would get corrupted when more than one process links to it. Maybe I misunderstood something here.One of you is talking about the executable code in a dll