Globals

[Walt Decker]

Looking at past posts concerning shared data between EXEs and DLLs containing globals I began to wonder if passing a pointer to a DLL could be used instead of memory-mapped files.

For example, the EXE contains globals A and B, A.DLL contains globals B and C, and B.DLL contains globals C and D.

If the EXE passes A_PTR to A.DLL, can A.DLL then change the data contained in global A?


------------------

[Tom Hanlin]

It isn't relevant whether A is global. The DLL can certainly change the data. Bear in mind, though, that the dataspace for a DLL is tied to the EXE that calls it: no other EXE will be able to access that A value, even if it calls the same DLL.

------------------
Tom Hanlin
PowerBASIC Staff

[Don Dickinson]

If your goal is to try to have a DLL modify a global used by the calling EXE, then you can pass a pointer (or easier, just pass the variable by reference) as a parameter in a DLL function.

If your goal is to share data between 2 exe's, this approach will not work - as Tom said, each program gets its own copy of the DLL.

--Don

[Walt Decker]

What I'm trying to do is get a little better understanding of the relationship between an exe and the dlls used by the exe. It is my understanding that the globals declared in an exe are in a data space different from the globals declared in the dlls which are either implicitly or explicitly loaded. Taking the example posted, A.DLL cannot directly change the data contained in global "A" of the exe nor can it directly change the data contained in global D of B.DLL unless the data is passed in the argument list or a pointer is passed to the data. Is that correct?

------------------

[Lance Edmonds]

Correct.

This of it this way: a GLOBAL is only global to the module in which it is defined. However, since an Instance of a DLL is mapped into the address-space of the EXE (or DLL) that loaded it, the memory use by the entire process is available to the DLL, but unless the DLL is given a pointer to particular memory locations, the DLL will not "know" where the memory block resides.

Or in other words: memory addresses of data owned by the EXE are not automatically "known" by the DLL, and vice-versa.

Most importantly, attempting to access an address that is not within the address-space of the process results in a GPF/Page fault. For example, reading or writing to an array beyond it's bounds stands a very good chance of a GPF. Depending on where the surrounding data is positined in memory, you may not always get a GPF because you could end up writing to a valid address for the process, but actually end up writing over unrelated data (this is often how memory corruption problems occur).

Because may not always occur when writing directly to memory (for example, using pointers or inline-assmebly), suspicion as to the real cause can be missed if "unrelated" code is mistakenly trusted. For example, if code in a DLL incorrectly writes to memory, it could cause corruption to show up in the EXE, and vice-versa.

Ensuring code only uses valid memory addresses is simple if code is written carefully. Do it wrong, and it can save a lot of time spent tracking down the real cause.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Peter Manders]

Lance,

So there you have one for the wishlist.

Please add an extra global variable type for DLLs, that are shared by all calls from all apps.

So we can stop using memory mapped files or mutexes or whatever for sharing data across apps through a DLL.

Peter.


------------------
[email protected]

[Lance Edmonds]

If you are talking about sharing data between _processes_, then the compiler would have to encapsulate one of the standard inter-process communication "routes", such as a memory mapped file, %WM_COPYDATA, etc. There are choices of ways and the best choice is really application-specific (ie, it is the programmers choice).

Still, I'll pass the request along to R&D... Thanks!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Walt Decker]

Thank you, Lance. That sounds a little like the way named common works in PDS.

One more thing. Do the global addresses move around during execution? For example, if I set up a structure of pointers for all globals and fill it during an initialization phase, will the addresses be valid throught the life of the app?

------------------

[Lance Edmonds]

Only as long as they reference memory that will not move

For example, PowerBASIC reserves the right to move arrays when an array is REDIMed, and _dynamic_ strings move with each allocation whether they are LOCAL, STATIC or GLOBAL.

Similarly, LOCAL variables will move each time their containing sub/function is called.

However, other kinds of scalar STATIC and GLOBAL variables should not move around at run-time.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Peter Manders]

Lance,

Just to clarify,

> However, other kinds of scalar STATIC and GLOBAL variables should not move around at run-time.

I think we can assume that (for simple strings) the STRPTR() data could change location but string descriptors VARPTR() will be stationary?
For simple strings that is, because string arrays can be moved around as you said.


Peter.


------------------
[email protected]