Shared string inside DLL

[Lindsay]

I need a string to be shared between all instances of my dll. Also, I need
to append the string with each new instance of the dll.


The string is declared:

#pragma bss_seg("MYBSS")
WCHAR* wFilenames;
#pragma bss_seg()
#pragma comment (linker,"/SECTION:MYBSS,rws")

There is a routine which is called once only per instance which recieves
another string to append to wFilenames:

QUICKEDITDLL bool STDCALL AddFilename(LPWSTR fn)
{
int s=(lstrlenW((LPCWSTR)wFilenames)+lstrlenW((LPCWSTR)fn)+2)*sizeof(WCHAR);
// Plus 2 to accomedate a semicolon and a null char
WCHAR* nS=(WCHAR*)malloc(s);
ZeroMemory(nS,s);
lstrcpyW(nS,wFilenames);
//free(wFilenames);
wFilenames=(WCHAR*)realloc(wFilenames,s);
ZeroMemory(wFilenames,s);
lstrcpyW(wFilenames,nS);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");
MessageBoxW(NULL,wFilenames,NULL,MB_OK);
free(nS);
return true;
}

wFilenames only ever holds the last string ( fn ).

I'm stumped but I'm sure I've just missed something but I don't know what.

 

[Mike Smith]

I need a string to be shared between all instances of my dll. Also, I need
to append the string with each new instance of the dll.


The string is declared:

#pragma bss_seg("MYBSS")
WCHAR* wFilenames;
#pragma bss_seg()
#pragma comment (linker,"/SECTION:MYBSS,rws")

There is a routine which is called once only per instance which recieves
another string to append to wFilenames:

QUICKEDITDLL bool STDCALL AddFilename(LPWSTR fn)
{
int s=(lstrlenW((LPCWSTR)wFilenames)+lstrlenW((LPCWSTR)fn)+2)*sizeof(WCHAR);
// Plus 2 to accomedate a semicolon and a null char
WCHAR* nS=(WCHAR*)malloc(s);
ZeroMemory(nS,s);
lstrcpyW(nS,wFilenames);
//free(wFilenames);
wFilenames=(WCHAR*)realloc(wFilenames,s);
ZeroMemory(wFilenames,s);
lstrcpyW(wFilenames,nS);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");
MessageBoxW(NULL,wFilenames,NULL,MB_OK);
free(nS);
return true;
}

wFilenames only ever holds the last string ( fn ).

I'm stumped but I'm sure I've just missed something but I don't know what.

Well, this is OT for c.l.c++ (being Win32-specific) but: I believe the
problem is that, while your pointer wFilenames is shared, the memory it
points to is not. You need to do something more like:

#pragma bss_seg("MYBSS")
WCHAR wFilenames[65536]; // <- or some appropriate amount of space
#pragma bss_seg()
#pragma comment (linker,"/SECTION:MYBSS,rws")

 

[Victor Bazarov]

I need a string to be shared between all instances of my dll. Also, I need
to append the string with each new instance of the dll.
[...]
I'm stumped but I'm sure I've just missed something but I don't know what.

You've missed the fact that there are no DLLs in C++ (and somehow I think
you actually knew that, it's not your first time here). Please ask in the
newsgroup that deals with your OS or your compiler (or both). AFAIK, it
is generally possible but it involves mechanisms not available in C++ in
its standard form. Memory sharing between processes is not defined in
C++, since the C++ program model does not acknowledge the existence of
other processes.

V

 

[Lindsay]

Yes I did know that. But my question was not so much about the DLL as that
was mentioed just so you knew why I was doing this. I only wanted to know
why my routine for appending the string was not working.

I need a string to be shared between all instances of my dll. Also, I
need to append the string with each new instance of the dll.
[...]
I'm stumped but I'm sure I've just missed something but I don't know
what.

You've missed the fact that there are no DLLs in C++ (and somehow I think
you actually knew that, it's not your first time here). Please ask in the
newsgroup that deals with your OS or your compiler (or both). AFAIK, it
is generally possible but it involves mechanisms not available in C++ in
its standard form. Memory sharing between processes is not defined in
C++, since the C++ program model does not acknowledge the existence of
other processes.

V

 

[Lindsay]

Excellent suggestion which worked! The string is initially declared as:
WCHAR wFilenames[1]=L""; and realloc is used thus:

int s=lstrlenW(wFilenames)+lstrlenW((LPCWSTR)fn)+1;
LPWSTR wFN=wFilenames;
wFN=(LPWSTR)realloc(wFN,(s+1)*sizeof(WCHAR));
MessageBoxW(NULL,wFilenames,NULL,MB_OK);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");

Thanks for the suggestion. Apologies if OT, but I have no formal tuition in
C or C++ and I still get confused as to which NG to ask in. I guess this
should have been Win32.

I need a string to be shared between all instances of my dll. Also, I
need to append the string with each new instance of the dll.


The string is declared:

#pragma bss_seg("MYBSS")
WCHAR* wFilenames;
#pragma bss_seg()
#pragma comment (linker,"/SECTION:MYBSS,rws")

There is a routine which is called once only per instance which recieves
another string to append to wFilenames:

QUICKEDITDLL bool STDCALL AddFilename(LPWSTR fn)
{
int
s=(lstrlenW((LPCWSTR)wFilenames)+lstrlenW((LPCWSTR)fn)+2)*sizeof(WCHAR);
// Plus 2 to accomedate a semicolon and a null char
WCHAR* nS=(WCHAR*)malloc(s);
ZeroMemory(nS,s);
lstrcpyW(nS,wFilenames);
//free(wFilenames);
wFilenames=(WCHAR*)realloc(wFilenames,s);
ZeroMemory(wFilenames,s);
lstrcpyW(wFilenames,nS);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");
MessageBoxW(NULL,wFilenames,NULL,MB_OK);
free(nS);
return true;
}

wFilenames only ever holds the last string ( fn ).

I'm stumped but I'm sure I've just missed something but I don't know
what.

Well, this is OT for c.l.c++ (being Win32-specific) but: I believe the
problem is that, while your pointer wFilenames is shared, the memory it
points to is not. You need to do something more like:

#pragma bss_seg("MYBSS")
WCHAR wFilenames[65536]; // <- or some appropriate amount of space
#pragma bss_seg()
#pragma comment (linker,"/SECTION:MYBSS,rws")

 

[Victor Bazarov]

Yes I did know that. But my question was not so much about the DLL as that
was mentioed just so you knew why I was doing this. I only wanted to know
why my routine for appending the string was not working.

First of all, please don't top-post.

Second, in the code that you posted there were only six lines that did
not require any extensions to C++ or additional information about OS-
specific libraries (and two are comments):

{
// Plus 2 to accomedate a semicolon and a null char
//free(wFilenames);
free(nS);
return true;
}

the rest could not be even comprehended without special knowledge.

Third, even if we possess the knowledge necessary to comprehend your code,
whatever the reason your code is not working, it cannot be presented using
the terms of the Standard C++, most likely, don't you think? Besides, you
didn't even say how your routine "wasn't working". What are you, a child?
Read the FAQ section 5 again, please.

I need a string to be shared between all instances of my dll. Also, I
need to append the string with each new instance of the dll.
[...]
I'm stumped but I'm sure I've just missed something but I don't know
what.

You've missed the fact that there are no DLLs in C++ (and somehow I think
you actually knew that, it's not your first time here). Please ask in the
newsgroup that deals with your OS or your compiler (or both). AFAIK, it
is generally possible but it involves mechanisms not available in C++ in
its standard form. Memory sharing between processes is not defined in
C++, since the C++ program model does not acknowledge the existence of
other processes.

V

 

[Victor Bazarov]

[...] Apologies if OT, but I have no formal tuition in
C or C++ and I still get confused as to which NG to ask in. I guess this
should have been Win32.
[..]

Good guess!

 

[gottlobfrege]

I'm torn as to whether I should reply or not, as I agree this is the
wrong place to ask, but I'm afraid you might walk away thinking you
solved your problems...

Excellent suggestion which worked! The string is initially declared as:
WCHAR wFilenames[1]=L""; and realloc is used thus:

int s=lstrlenW(wFilenames)+lstrlenW((LPCWSTR)fn)+1;
LPWSTR wFN=wFilenames;
wFN=(LPWSTR)realloc(wFN,(s+1)*sizeof(WCHAR));

!!Yikes!! You are trying to realloc a static block of memory. I
suspect that is 'undefined behaviour' as they say.

MessageBoxW(NULL,wFilenames,NULL,MB_OK);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");

what makes you think wFilenames now has enough room? ie why do you
think (as I suspect you do) that wFN points to the same place
wFilenames does? If realloc always magically made room at the same
place in memory, why would you need to set wFN to its return value? ie
do you think the value of wFN changed by the assignment?

I suspect you are lstrcatW'ing into a spot that is really only 1 WCHAR
long, and you are writing off into nowhere. (But since it is in its
own segment, it probably has some minimum segment size so that there
_happens_ to be empty room there.

add a variable after wFilenames, such as:

WCHAR wFilenames[1]=L"";

int foo = 17;

I bet foo doesn't = 17 after your code runs.

So, even though your question should be on Win32, I actually think your
problem is the C code, not the Win32-isms.

Let's take a look at your first version:

first time in, wFilenames is NULL. What does lstrlenW do with that?
(return 0 I suspect, but note that normal strlen would 'nicely' crash,
and let you know early on that something was wrong).
don't bother, you are about to overwrite the zeros anyhow.

commented out because it crashes the first time? (because wFilenames is
0?)

reallocing a null. works, but odd. try just malloc, freeing wFilenames
beforehand, if not null.

waste of time, again.
if you _are_ using realloc, the text from the old wFilenames was
preserved (when wFilenames isn't null) so the temporary nS wasn't
needed at all.

There's lots of problems there, even more serious ones in the second
version I think. But I must say, other than the initial NULL, I'm not
sure exactly what the missing string problem is. But it is hard to see
until it is cleaned up a bit.

Hopefully you reposted ona Win32 list and it has been all sorted out
there.

Nah, I don't think that's it. That part of the code is pretty normal
for Win32, but that conversation really does belong on another list....

- Tony

 

[John Carson]

Nah, I don't think that's it. That part of the code is pretty normal
for Win32, but that conversation really does belong on another
list....

Yeah, that is it. Each process in Win32 has its own virtual address space so
a memory address that points to valid memory in process A could point
anywhere in process B. What he needs is either the technique suggested by
Mike Smith or else a way to share dynamically allocated memory between
processes. This is very much Win32-specific and very much off-topic.

 

[Lindsay]

I'll post anyhow I want. Don't bother me with your trivialities.

As for being a child, well, that's just rude. If you haven't got an answer,
don't answer!

Yes I did know that. But my question was not so much about the DLL as
that was mentioed just so you knew why I was doing this. I only wanted to
know why my routine for appending the string was not working.

First of all, please don't top-post.

Second, in the code that you posted there were only six lines that did
not require any extensions to C++ or additional information about OS-
specific libraries (and two are comments):

{
// Plus 2 to accomedate a semicolon and a null char
//free(wFilenames);
free(nS);
return true;
}

the rest could not be even comprehended without special knowledge.

Third, even if we possess the knowledge necessary to comprehend your code,
whatever the reason your code is not working, it cannot be presented using
the terms of the Standard C++, most likely, don't you think? Besides, you
didn't even say how your routine "wasn't working". What are you, a child?
Read the FAQ section 5 again, please.

Lindsay wrote:

I need a string to be shared between all instances of my dll. Also, I
need to append the string with each new instance of the dll.
[...]
I'm stumped but I'm sure I've just missed something but I don't know
what.

You've missed the fact that there are no DLLs in C++ (and somehow I think
you actually knew that, it's not your first time here). Please ask in
the
newsgroup that deals with your OS or your compiler (or both). AFAIK, it
is generally possible but it involves mechanisms not available in C++ in
its standard form. Memory sharing between processes is not defined in
C++, since the C++ program model does not acknowledge the existence of
other processes.

V

 

[Lindsay]

Have you tested any of this code? The second version works fine, thanks to
Mike Smith who hit the nail on the head.

Also, for the first version, there was a couple of lines accidentaly
omitted. In the DLL_PROCESS_ATTACH, were the lines to check if NULL and if
so, allocate a couple of bytes of memory to wFilenames.

Anyhow, even though the 2nd version works, I now have other issues with my
DLL. Off to another NG now.

I'm torn as to whether I should reply or not, as I agree this is the
wrong place to ask, but I'm afraid you might walk away thinking you
solved your problems...

Excellent suggestion which worked! The string is initially declared as:
WCHAR wFilenames[1]=L""; and realloc is used thus:

int s=lstrlenW(wFilenames)+lstrlenW((LPCWSTR)fn)+1;
LPWSTR wFN=wFilenames;
wFN=(LPWSTR)realloc(wFN,(s+1)*sizeof(WCHAR));

!!Yikes!! You are trying to realloc a static block of memory. I
suspect that is 'undefined behaviour' as they say.

MessageBoxW(NULL,wFilenames,NULL,MB_OK);
lstrcatW(wFilenames,fn);
lstrcatW(wFilenames,L";");

what makes you think wFilenames now has enough room? ie why do you
think (as I suspect you do) that wFN points to the same place
wFilenames does? If realloc always magically made room at the same
place in memory, why would you need to set wFN to its return value? ie
do you think the value of wFN changed by the assignment?

I suspect you are lstrcatW'ing into a spot that is really only 1 WCHAR
long, and you are writing off into nowhere. (But since it is in its
own segment, it probably has some minimum segment size so that there
_happens_ to be empty room there.

add a variable after wFilenames, such as:

WCHAR wFilenames[1]=L"";

int foo = 17;

I bet foo doesn't = 17 after your code runs.

So, even though your question should be on Win32, I actually think your
problem is the C code, not the Win32-isms.

Let's take a look at your first version:

first time in, wFilenames is NULL. What does lstrlenW do with that?
(return 0 I suspect, but note that normal strlen would 'nicely' crash,
and let you know early on that something was wrong).
don't bother, you are about to overwrite the zeros anyhow.

commented out because it crashes the first time? (because wFilenames is
0?)

reallocing a null. works, but odd. try just malloc, freeing wFilenames
beforehand, if not null.

waste of time, again.
if you _are_ using realloc, the text from the old wFilenames was
preserved (when wFilenames isn't null) so the temporary nS wasn't
needed at all.

There's lots of problems there, even more serious ones in the second
version I think. But I must say, other than the initial NULL, I'm not
sure exactly what the missing string problem is. But it is hard to see
until it is cleaned up a bit.

Hopefully you reposted ona Win32 list and it has been all sorted out
there.

Nah, I don't think that's it. That part of the code is pretty normal
for Win32, but that conversation really does belong on another list....

- Tony

 

[Victor Bazarov]

I'll post anyhow I want. Don't bother me with your trivialities.

As for being a child, well, that's just rude. If you haven't got an answer,
don't answer!

I had an answer and I posted it. As to your reply, it only confirms that
you _are_ still a child. Apparently unable to learn to respect others,
you deserve to be ignored.

Yes I did know that. But my question was not so much about the DLL as
that was mentioed just so you knew why I was doing this. I only wanted to
know why my routine for appending the string was not working.

First of all, please don't top-post.

Second, [...]

V

 

[JustBoo]

I had an answer and I posted it. As to your reply, it only confirms that
you _are_ still a child. Apparently unable to learn to respect others,
you deserve to be ignored.

Respect is a two-way street.

V: "Yeah, you are!"
OP: "No I'm not!"

V: "I know you are but what am I?"
OP: "Leave me alone!"
V: "I'm not touching you! I'm not touching you!"

My gawd, your ego-driven megalomania and "control-freak" neurosis has
brought you to this Victor?

Wow, true intellect always bubbles to the surface eh, "V."

It's quite sad really. Hey Victor, think about a girlfriend or a dog
at the least. ( Now there is an opportunity for a bad joke... make
your own. )

"If you have ten thousand regulations you destroy
all respect for the law." - Winston Churchill

And I notice this ng has never been more "out of control."

"The more you tighten your grip, Tarkin, the more star systems will
slip through your fingers."

PettyMyopicBureaucrat = SnottyLanguageLawyer += NetCop;

Have a great day out in the sun and fun.

 

[Shark]

Respect is a two-way street.

V: "Yeah, you are!"
OP: "No I'm not!"

V: "I know you are but what am I?"
OP: "Leave me alone!"
V: "I'm not touching you! I'm not touching you!"

My gawd, your ego-driven megalomania and "control-freak" neurosis has
brought you to this Victor?

Wow, true intellect always bubbles to the surface eh, "V."

It's quite sad really. Hey Victor, think about a girlfriend or a dog
at the least. ( Now there is an opportunity for a bad joke... make
your own. )

"If you have ten thousand regulations you destroy
all respect for the law." - Winston Churchill

And I notice this ng has never been more "out of control."

"The more you tighten your grip, Tarkin, the more star systems will
slip through your fingers."

PettyMyopicBureaucrat = SnottyLanguageLawyer += NetCop;

Have a great day out in the sun and fun.

just out of curiosity, how old are the people in this ng? I am 22 (and
jobless).

 

[Mike Smith]

Have you tested any of this code? The second version works fine, thanks to
Mike Smith who hit the nail on the head.

Hey, whoa, I simply pointed out your problem. That doesn't mean your
solution is necessarily appropriate. Looking at your code, what you're
doing seems pretty dangerous to me; if it's working, it's working
entirely by accident.