Shared string inside DLL

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.

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> 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.[/color]

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")

--
Mike Smith

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> 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.[/color]

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

re: Shared string inside DLL

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.

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:MgTzf.34$a97.32@newsread1.mlpsca01.us.to.veri o.net...[color=blue]
> Lindsay wrote:[color=green]
>> 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.[/color]
>
> 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[/color]

re: Shared string inside DLL

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.

"Mike Smith" <mikeUNDERSCOREsmith@acm.org> wrote in message
news:11svvtkar65l657@news.supernews.com...[color=blue]
> Lindsay wrote:[color=green]
>> 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.[/color]
>
> 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")
>
> --
> Mike Smith[/color]

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
> news:MgTzf.34$a97.32@newsread1.mlpsca01.us.to.veri o.net...
>[color=green]
>>Lindsay wrote:
>>[color=darkred]
>>>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.[/color]
>>
>>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.[/color][/color]

V
--
Please remove capital As from my address when replying by mail

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> [...] 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.
> [..][/color]

Good guess!

re: Shared string inside DLL

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...

Lindsay wrote:[color=blue]
> 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));[/color]

!!Yikes!! You are trying to realloc a static block of memory. I
suspect that is 'undefined behaviour' as they say.
[color=blue]
> MessageBoxW(NULL,wFilenames,NULL,MB_OK);
> lstrcatW(wFilenames,fn);
> lstrcatW(wFilenames,L";");
>[/color]

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:
[color=blue]
> WCHAR wFilenames[1]=L"";[/color]
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:
[color=blue][color=green]
> > Lindsay wrote:[color=darkred]
> >> WCHAR* wFilenames;
> >>
> >> QUICKEDITDLL bool STDCALL AddFilename(LPWSTR fn)
> >> {
> >> int
> >> s=(lstrlenW((LPCWSTR)wFilenames)+lstrlenW((LPCWSTR )fn)+2)*sizeof(WCHAR);[/color][/color][/color]

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).
[color=blue][color=green][color=darkred]
> >> // Plus 2 to accomedate a semicolon and a null char
> >> WCHAR* nS=(WCHAR*)malloc(s);[/color][/color][/color]
[color=blue][color=green][color=darkred]
> >> ZeroMemory(nS,s);[/color][/color][/color]
don't bother, you are about to overwrite the zeros anyhow.
[color=blue][color=green][color=darkred]
> >> lstrcpyW(nS,wFilenames);
> >> //free(wFilenames);[/color][/color][/color]

commented out because it crashes the first time? (because wFilenames is
0?)
[color=blue][color=green][color=darkred]
> >> wFilenames=(WCHAR*)realloc(wFilenames,s);[/color][/color][/color]

reallocing a null. works, but odd. try just malloc, freeing wFilenames
beforehand, if not null.
[color=blue][color=green][color=darkred]
> >> ZeroMemory(wFilenames,s);[/color][/color][/color]

waste of time, again.
[color=blue][color=green][color=darkred]
> >> lstrcpyW(wFilenames,nS);[/color][/color][/color]
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.
[color=blue][color=green][color=darkred]
> >> 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.[/color][/color][/color]

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.
[color=blue][color=green]
> >
> > 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.
> > Mike Smith[/color][/color]

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

re: Shared string inside DLL

<gottlobfrege@gmail.com> wrote in message
news:1137720246.908655.159820@g43g2000cwa.googlegr oups.com[color=blue][color=green][color=darkred]
>>>
>>> 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.
>>> Mike Smith[/color][/color]
>
> 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....[/color]

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.


--
John Carson

re: Shared string inside DLL

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!

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:8UTzf.36$a97.21@newsread1.mlpsca01.us.to.veri o.net...[color=blue]
> Lindsay wrote:[color=green]
>> 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.[/color]
>
> 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.
>[color=green]
>> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
>> news:MgTzf.34$a97.32@newsread1.mlpsca01.us.to.veri o.net...
>>[color=darkred]
>>>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.[/color][/color]
>
> V
> --
> Please remove capital As from my address when replying by mail[/color]

re: Shared string inside DLL

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.

<gottlobfrege@gmail.com> wrote in message
news:1137720246.908655.159820@g43g2000cwa.googlegr oups.com...[color=blue]
> 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...
>
> Lindsay wrote:[color=green]
>> 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));[/color]
>
> !!Yikes!! You are trying to realloc a static block of memory. I
> suspect that is 'undefined behaviour' as they say.
>[color=green]
>> MessageBoxW(NULL,wFilenames,NULL,MB_OK);
>> lstrcatW(wFilenames,fn);
>> lstrcatW(wFilenames,L";");
>>[/color]
>
> 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:
>[color=green]
>> WCHAR wFilenames[1]=L"";[/color]
> 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:
>[color=green][color=darkred]
>> > Lindsay wrote:
>> >> WCHAR* wFilenames;
>> >>
>> >> QUICKEDITDLL bool STDCALL AddFilename(LPWSTR fn)
>> >> {
>> >> int
>> >> s=(lstrlenW((LPCWSTR)wFilenames)+lstrlenW((LPCWSTR )fn)+2)*sizeof(WCHAR);[/color][/color]
>
> 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).
>[color=green][color=darkred]
>> >> // Plus 2 to accomedate a semicolon and a null char
>> >> WCHAR* nS=(WCHAR*)malloc(s);[/color][/color]
>[color=green][color=darkred]
>> >> ZeroMemory(nS,s);[/color][/color]
> don't bother, you are about to overwrite the zeros anyhow.
>[color=green][color=darkred]
>> >> lstrcpyW(nS,wFilenames);
>> >> //free(wFilenames);[/color][/color]
>
> commented out because it crashes the first time? (because wFilenames is
> 0?)
>[color=green][color=darkred]
>> >> wFilenames=(WCHAR*)realloc(wFilenames,s);[/color][/color]
>
> reallocing a null. works, but odd. try just malloc, freeing wFilenames
> beforehand, if not null.
>[color=green][color=darkred]
>> >> ZeroMemory(wFilenames,s);[/color][/color]
>
> waste of time, again.
>[color=green][color=darkred]
>> >> lstrcpyW(wFilenames,nS);[/color][/color]
> 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.
>[color=green][color=darkred]
>> >> 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.[/color][/color]
>
> 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.
>[color=green][color=darkred]
>> >
>> > 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.
>> > Mike Smith[/color][/color]
>
> 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
>[/color]

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> 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![/color]

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.
[color=blue]
>
> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
> news:8UTzf.36$a97.21@newsread1.mlpsca01.us.to.veri o.net...
>[color=green]
>>Lindsay wrote:
>>[color=darkred]
>>>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.[/color]
>>
>>First of all, please don't top-post.
>>
>>Second, [...][/color][/color]

V

re: Shared string inside DLL

On Fri, 20 Jan 2006 11:50:30 -0500, Victor Bazarov
<v.Abazarov@comAcast.net> wrote:[color=blue]
>Lindsay wrote:[color=green]
>> 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![/color]
>
>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.[/color]

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.

re: Shared string inside DLL

JustBoo wrote:[color=blue]
> On Fri, 20 Jan 2006 11:50:30 -0500, Victor Bazarov
> <v.Abazarov@comAcast.net> wrote:[color=green]
> >Lindsay wrote:[color=darkred]
> >> 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![/color]
> >
> >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.[/color]
>
> 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.[/color]

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

re: Shared string inside DLL

Lindsay wrote:[color=blue]
> Have you tested any of this code? The second version works fine, thanks to
> Mike Smith who hit the nail on the head.[/color]

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.

--
Mike Smith