CString in a DLL Shared Data Segment

I'm creating a DLL with a shared data segment using the #pragma directive.

I'm trying to share a CString object among other variables. The problem is that the CString object resets its contents everytime the DLL injects itself into a process's address space.

I would like the CString object (I've also tried a char array) to maintain its' contents from process to process.

Is there a way to do this?
Thanks in advance.
shark351Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mikeblasCommented:
You can't.

First: A CString copies its data as it constructs (or is assigned), and the constructor will run each time the DLL is inserted into a new process.

Second: and the data will be allocated on a process-local heap, and can't be shared.

You need to use a more sensible and appropriate interprocess communication mechanism.

..B ekiM
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
shark351Author Commented:
OK, as mentioned I also tried using a regular char array which obviously will not re-construct itself like a CString will.
1) Why is the char array being reset also?
2) What alternatives do I have to maintain a buffer from process to process?
3) You say that the data is allocated on a process local heap. That's fine but the global data is defined in the DLL module as SHARED,RWS. In Jeffery Richter's "Advanced Windows" he shows how to use this method to share data among all instances of a DLL. Why won't a char array work in this case?
0
mikeblasCommented:
I didn't read in your message that you said a character array was failing, or that you wanted to use it.

1) The character array shouldn't be reset, if you've declared it correctly. You've probably not declared it correctly, though it's also possible that you're not properly testing the value of the array or that you're actually doing something to change the content of the array when you didn't expect it. You've not expressed any specific symptoms or shown any code. With nothing to go on, all I can do is guess.

2) Write a function in your DLL which manages a dynamically-allocated block of memory which is shared across processes (that is, allocated with the GMEM_SHARED flag). This access mechanism also gives you a convenient construct for gating access to the data for the multiple threads which will be touching it.

3) I didn't say a character array wouldn't work in this case. A character array isn't a CString; I was referring to CStrings, specifically. In my post, I never mentioned character arrays.

Apparently, you already have the sample in the Richter book--my book has a sample of this technique, too.  How shall we proceed? Do you want to post your project and have me diagnose it?

..B ekiM
0
shark351Author Commented:
-Mikeblas,

I'll post the appropriate code below.
The GetBuffer() function is called by an application that I created which simply gets a copy of the shared DLL buffer.
KeyboardProc is the callback for the Keyboard Hook. It is in this function that I keep adding characters to the buffer.
You'll notice that there is a CString and a char array declared in the shared section. I've been experimenting with both types.
Please let me know if you see a problem.
Thanks.

DLL CODE:

DLL Header File:
#define LIBFUNC __declspec(dllexport)
/////////////////////////////////////////////////////////////////////////////
// Exportable Functions
LIBFUNC BOOL SetKeyboardHook(HWND, HINSTANCE);
LIBFUNC void GetBuffer(char*);

/////////////////////////////////////////////////////////////////////////////
// Implementation

BOOL UnsetKeyboardHook();
LRESULT CALLBACK KeyboardProc(int, WPARAM, LPARAM);

DLL CPP File:
#pragma data_seg("SHARDATA")
static HWND g_hWnd=NULL;
static HHOOK g_hHookKeyboard=NULL;
static CString g_strBuffer;
static char g_szBuf[256];
#pragma data_seg()

// Instruct the Linker to make SHARDATA
// readable, writable & shared
#pragma comment(linker, "-SECTION:SHARDATA,RWS")

void GetBuffer(char* c)
{
      strcpy(c, g_szBuf);
}
0
mikeblasCommented:
Yeah, you've coded it wrong. You've got:
 
#pragma data_seg("SHARDATA")
// ...
static char g_szBuf[256];
#pragma data_seg()

and that doesn't put anything in the SHARDATA section. Since g_szBuf is uninitialized, the compiler puts it into the .bss section with all the other uninitalized global data. You want to make sure everything you want to be in SHARDATA is initialized. For this example, you should've coded:

#pragma data_seg("SHARDATA")
// ...
static char g_szBuf[256] = { 0 };
#pragma data_seg()

The initialization makes g_szBuf appear in the SHARDATA section.

..B ekiM
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.