Olestr

Hello everyone,


When we use OLESTR to allocate a variable from string literal, like OLESTR("Hello World"), the memory space for the string literal is on stack, right?

I can not find official document for this from MSDN.


thanks in advance,
George

From what I see, OLESTR just adds L to the string, turning it into unicode (but keeps it as multi-byte for 16-bit).

Hi Elysia,


My question is not whether OLECHAR is wchar_t* or char*.

My current issue is, I am not sure whether pass pointer pointing to "local" OLESTR string literal (e.g. OLECHAR* p = OLESTR("Hello"); then passing p to another function is safe?) from one function to another is safe (if on stack, not safe)?

Quote:

---

Originally Posted by Elysia

From what I see, OLESTR just adds L to the string, turning it into unicode (but keeps it as multi-byte for 16-bit).

---

regards,
George

Here's how OLESTR is defined according to MSDN:

Code:

---

#if defined(_WIN32) && !defined(OLE2ANSI)
  #define OLESTR(str)    L##str
#else  // 16-bit applications
  #define OLESTR(str)    str
#endif

---

It's like the TEXT macro. It simple adds "L" to the string. It's not a type.

So, the string literal will be stored on rdata section, which is "read only data", and thus persists throughout execution of the application [1]


[1] For the pedants, obvously if the data is forwarded from a DLL that is subsequently closed, the data is no longer available. But this is not normal behaviour and can be avoided by not closing the DLL. Note also that normal use of DLL's where the application is not opening the DLL by LoadLibrary(), then the closing is done by the process clean-up after the executable exits.

--
Mats

Thanks Mats,


1.

Quote:

---

Originally Posted by matsp

[1] For the pedants, obvously if the data is forwarded from a DLL that is subsequently closed, the data is no longer available. But this is not normal behaviour and can be avoided by not closing the DLL.

---

Previously, I think the string literal is stored in process global area, so whether or not the DLL is unloaded, we can safely access. Now, I understand it is stored in DLL specific storage area and will disappear after DLL unloads.

Do you have any formal documents to support this claim (MSDN for example)? :-)

2.

Quote:

---

Originally Posted by matsp

Note also that normal use of DLL's where the application is not opening the DLL by LoadLibrary(), then the closing is done by the process clean-up after the executable exits.

--
Mats

---

It is a typo? I think your above statements should not contain the word "not"? By reading, normal use of ... is not ... by LoadLibrary, I am confused. :-)


regards,
George

Quote:

---

Originally Posted by George2

Thanks Mats,


1.



Previously, I think the string literal is stored in process global area, so whether or not the DLL is unloaded, we can safely access. Now, I understand it is stored in DLL specific storage area and will disappear after DLL unloads.

Do you have any formal documents to support this claim (MSDN for example)? :-)

---

The global data produced for a DLL belongs in the DLL, and will disappear if the DLL is unloaded - that's the whole purpose of DLL's.

I don't have a reference to that, but nothing else makes any sense at all. If you produce a DLL that contains

Code:

---

void dllHello()
{
  printf("Hello World\n");
}

---

and then produce an executable that calls dllHello(), I expect the string "Hello, World\n" to be part of the DLL, not the executable. In your understanding, where do you get a different understanding?

Quote:

---

2.

>Note also that normal use of DLL's where the application is not opening the DLL by LoadLibrary(), then the closing is done by the process clean-up after the executable exits.

It is a typo? I think your above statements should not contain the word "not"? By reading, normal use of ... is not ... by LoadLibrary, I am confused. :-)


regards,
George

---

The normal case is that the DLL is loaded as part of the process creation. In this case, the DLL is not closed by the application code, but by the maintenance code in the kernel that deals with cleaning up after the process when it's exited.

I'm not sure what can be confusing about this, except that I perhaps should have avoided the double negative.

--
Mats

Thanks Mats,


Question answered. Your reply is clear this time. :-)

Quote:

---

Originally Posted by matsp

The global data produced for a DLL belongs in the DLL, and will disappear if the DLL is unloaded - that's the whole purpose of DLL's.

I don't have a reference to that, but nothing else makes any sense at all. If you produce a DLL that contains

Code:

---

void dllHello()
{
  printf("Hello World\n");
}

---

and then produce an executable that calls dllHello(), I expect the string "Hello, World\n" to be part of the DLL, not the executable. In your understanding, where do you get a different understanding?


The normal case is that the DLL is loaded as part of the process creation. In this case, the DLL is not closed by the application code, but by the maintenance code in the kernel that deals with cleaning up after the process when it's exited.

I'm not sure what can be confusing about this, except that I perhaps should have avoided the double negative.

--
Mats

---

regards,
George