Olestr

This is a discussion on Olestr within the Windows Programming forums, part of the Platform Specific Boards category; Hello everyone, When we use OLESTR to allocate a variable from string literal, like OLESTR("Hello World"), the memory space for ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    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

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    From what I see, OLESTR just adds L to the string, turning it into unicode (but keeps it as multi-byte for 16-bit).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    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 View Post
    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

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,548
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    1.

    Quote Originally Posted by matsp View Post
    [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 View Post
    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

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by George2 View Post
    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?

    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


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

    Quote Originally Posted by matsp View Post
    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

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21