I have an issue with scoped_handle on x64 that I need rather urgent assistance with.

I feel like I'm actually close to figuring out the problem, but getting lost in the corners of how abstracted things like scoped_handle are. The problem is an exception being thrown on line 161 of scoped_handle.hpp:

   static void translate(holder_type& h, degenerate_function_type pv)
   {
        function_type   fn  =   reinterpret_cast<function_type>(pv);

        STLSOFT_ASSERT(!h.bPointer);
        STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL != fn);

        fn(h.u.h); // <-- Here's line 161
   }

The call that's causing this problem is around this:

        // trying to get HKU/.DEFAULT/Environment
    std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
                SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);

    try
    {
        reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());

        for (reg_value_sequence_w::const_iterator envvar = env.begin();
                    env.end() != envvar; ++envvar)
        {
            ...
        }
    }
    catch (const registry_exception&)
    {
    }
    catch (...)
    {
    }

The exception thrown is not a registry_exception, but it might be an invalid_calling_convention_exception.

We have that secondary catch (...), but that's completely inappropriate as we are not able to complete this code path on x64 at all. I've got a sample program, but it includes some of our source code that I can't post to a public newsgroup. Can you contact me off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.

-austin

Am just doing a Pantheios release, and then will attend to this. Will email you separately now ...

"Austin Ziegler" <austin.ziegler@evault.com> wrote in message news:gac0hg$gau$1@digitalmars.com...
> I have an issue with scoped_handle on x64 that I need rather urgent assistance with.
>
> I feel like I'm actually close to figuring out the problem, but getting lost in the corners of how abstracted things like
scoped_handle are. The problem is an exception being thrown on line 161 of scoped_handle.hpp:
>
>    static void translate(holder_type& h, degenerate_function_type pv)
>    {
>         function_type   fn  =   reinterpret_cast<function_type>(pv);
>
>         STLSOFT_ASSERT(!h.bPointer);
>         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL != fn);
>
>         fn(h.u.h); // <-- Here's line 161
>    }
>
> The call that's causing this problem is around this:
>
>         // trying to get HKU/.DEFAULT/Environment
>     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
>                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);
>
>     try
>     {
>         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());
>
>         for (reg_value_sequence_w::const_iterator envvar = env.begin();
>                     env.end() != envvar; ++envvar)
>         {
>             ...
>         }
>     }
>     catch (const registry_exception&)
>     {
>     }
>     catch (...)
>     {
>     }
>
> The exception thrown is not a registry_exception, but it might be an invalid_calling_convention_exception.
>
> We have that secondary catch (...), but that's completely inappropriate as we are not able to complete this code path on x64 at
all. I've got a sample program, but it includes some of our source code that I can't post to a public newsgroup. Can you contact me
off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
>
> -austin

Austin

Just checking this one off as complete.

Can you let me know whether you get any issues with the next release - 1.9.55 - which should be out today/tomorrow.

Cheers

Matt

"Austin Ziegler" <austin.ziegler@evault.com> wrote in message news:gac0hg$gau$1@digitalmars.com...
> I have an issue with scoped_handle on x64 that I need rather urgent assistance with.
>
> I feel like I'm actually close to figuring out the problem, but getting lost in the corners of how abstracted things like
scoped_handle are. The problem is an exception being thrown on line 161 of scoped_handle.hpp:
>
>    static void translate(holder_type& h, degenerate_function_type pv)
>    {
>         function_type   fn  =   reinterpret_cast<function_type>(pv);
>
>         STLSOFT_ASSERT(!h.bPointer);
>         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL != fn);
>
>         fn(h.u.h); // <-- Here's line 161
>    }
>
> The call that's causing this problem is around this:
>
>         // trying to get HKU/.DEFAULT/Environment
>     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
>                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);
>
>     try
>     {
>         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());
>
>         for (reg_value_sequence_w::const_iterator envvar = env.begin();
>                     env.end() != envvar; ++envvar)
>         {
>             ...
>         }
>     }
>     catch (const registry_exception&)
>     {
>     }
>     catch (...)
>     {
>     }
>
> The exception thrown is not a registry_exception, but it might be an invalid_calling_convention_exception.
>
> We have that secondary catch (...), but that's completely inappropriate as we are not able to complete this code path on x64 at
all. I've got a sample program, but it includes some of our source code that I can't post to a public newsgroup. Can you contact me
off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
>
> -austin

Matthew Wilson Wrote:
> Just checking this one off as complete.
> 
> Can you let me know whether you get any issues with the next release - 1.9.55 - which should be out today/tomorrow.

Will do. If the changes are similar to the patches we sent you, this shouldn't be a problem.

-austin

Hello Matthew,

I have the same problem with the latest version of STLSOFT (1.9.99) and Visual Studio 2008 running under Windows 7 x64. The Exception thrown is stlsoft::winstl_project::invalid_calling_convention_exception. It happens when I try to iterate over a reg_value_sequence. I traced it back to the very same line as Austin (see quoted message below), but didn't get further. It complains about an unsupported calling convention "S".



> Austin

> Just checking this one off as complete.

> Can you let me know whether you get any issues with the next release - 1.9.55 - which should be out today/tomorrow.

> Cheers

> Matt

> "Austin Ziegler" <austin.ziegler@evault.com> wrote in message news:gac0hg$gau$1@digitalmars.com...
>> I have an issue with scoped_handle on x64 that I need rather urgent assistance with.
>>
>> I feel like I'm actually close to figuring out the problem, but getting lost in the corners of how abstracted things like
> scoped_handle are. The problem is an exception being thrown on line 161 of scoped_handle.hpp:
>>
>>    static void translate(holder_type& h, degenerate_function_type pv)
>>    {
>>         function_type   fn  =   reinterpret_cast<function_type>(pv);
>>
>>         STLSOFT_ASSERT(!h.bPointer);
>>         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL !=
>>         fn);
>>
>>         fn(h.u.h); // <-- Here's line 161
>>    }
>>
>> The call that's causing this problem is around this:
>>
>>         // trying to get HKU/.DEFAULT/Environment
>>     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
>>                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);
>>
>>     try
>>     {
>>         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());
>>
>>         for (reg_value_sequence_w::const_iterator envvar = env.begin();
>>                     env.end() != envvar; ++envvar)
>>         {
>>             ...
>>         }
>>     }
>>     catch (const registry_exception&)
>>     {
>>     }
>>     catch (...)
>>     {
>>     }
>>
>> The exception thrown is not a registry_exception, but it might be an invalid_calling_convention_exception.
>>
>> We have that secondary catch (...), but that's completely inappropriate as we are not able to complete this code path on x64 at
> all. I've got a sample program, but it includes some of our source code that I can't post to a public newsgroup. Can you contact me off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
>>
>> -austin





So Long...

Gabor

Hello Matthew,

On July 28th I wrote:

> I have the same problem with the latest version of STLSOFT (1.9.99) and Visual Studio 2008 running under Windows 7 x64. The Exception thrown is stlsoft::winstl_project::invalid_calling_convention_exception. It happens when I try to iterate over a reg_value_sequence. I traced it back to the very same line as Austin (see quoted message below), but didn't get further. It complains about an unsupported calling convention "S".


The problem ist still present in STLSOFT 1.9.101. This simple program can reproduce the problem:

#include "stdafx.h"
#include <iostream>
#include <algorithm>
#include "winstl/registry/reg_key_sequence.hpp"

void print(const winstl::reg_key& key)
{
    std::cout << key.name().c_str() << std::endl;
}

int _tmain(int argc, _TCHAR* argv[])
{
    try
    {
        winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE,
            _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"));

        std::for_each(keys.begin(), keys.end(), print);
        return 0;
    }

    catch (std::exception& e)
    {
        std::cout << e.what() << std::endl;
        return 1;
    }
}

I debugged the program to find out what the problem is, and in winstl.h I found following definitions:

#if defined(WIN64)
# define WINSTL_OS_IS_WIN64
#elif defined(WIN32)
# define WINSTL_OS_IS_WIN32
#else /* ? WIN?? */
# error WinSTL is only compatible with Win32 and Win64
#endif /* WIN?? */

But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my test program, before the include of reg_key_sequence.h:

#ifdef _WIN64
#define WIN64
#endif

Then everything worked fine. So I googled a bit, and it seems that, for Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not. So, to correct this problem, the line in winstl.h should be changed to "#if defined (_WIN64)".


So Long...

Gabor

Hell Matthew,


The problem still exists in STLSOFT 1.9.104. The suggested workaround still works, but it should be included into STLSOFT.

>> I have the same problem with the latest version of STLSOFT (1.9.99) and Visual Studio 2008 running under Windows 7 x64. The Exception thrown is stlsoft::winstl_project::invalid_calling_convention_exception. It happens when I try to iterate over a reg_value_sequence. I traced it back to the very same line as Austin (see quoted message below), but didn't get further. It complains about an unsupported calling convention "S".


> The problem ist still present in STLSOFT 1.9.101. This simple program can reproduce the problem:

> #include "stdafx.h"
> #include <iostream>
> #include <algorithm>
> #include "winstl/registry/reg_key_sequence.hpp"

> void print(const winstl::reg_key& key)
> {
>     std::cout << key.name().c_str() << std::endl;
> }

> int _tmain(int argc, _TCHAR* argv[])
> {
>     try
>     {
>         winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE,
>             _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"));

>         std::for_each(keys.begin(), keys.end(), print);
>         return 0;
>     }

>     catch (std::exception& e)
>     {
>         std::cout << e.what() << std::endl;
>         return 1;
>     }
> }

> I debugged the program to find out what the problem is, and in winstl.h I found following definitions:

> #if defined(WIN64)
> # define WINSTL_OS_IS_WIN64
> #elif defined(WIN32)
> # define WINSTL_OS_IS_WIN32
> #else /* ? WIN?? */
> # error WinSTL is only compatible with Win32 and Win64
> #endif /* WIN?? */

> But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my test program, before the include of reg_key_sequence.h:

> #ifdef _WIN64
> #define WIN64
> #endif

> Then everything worked fine. So I googled a bit, and it seems that, for Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not. So, to correct this problem, the line in winstl.h should be changed to "#if defined (_WIN64)".


> So Long...

> Gabor



So Long...

Gabor

This should now be addressed with the latest version: 1.9.105

"Gabor Fischer" <Gabor.Fischer@systecs.com> wrote in message news:BbS9VkAKQNB@systecs.com...
> Hell Matthew,
>
>
> The problem still exists in STLSOFT 1.9.104. The suggested workaround still works, but it should be included into STLSOFT.
>
>>> I have the same problem with the latest version of STLSOFT (1.9.99) and
>>> Visual Studio 2008 running under Windows 7 x64. The Exception thrown is
>>> stlsoft::winstl_project::invalid_calling_convention_exception. It
>>> happens
>>> when I try to iterate over a reg_value_sequence. I traced it back to the
>>> very same line as Austin (see quoted message below), but didn't get
>>> further. It complains about an unsupported calling convention "S".
>
>
>> The problem ist still present in STLSOFT 1.9.101. This simple program can reproduce the problem:
>
>> #include "stdafx.h"
>> #include <iostream>
>> #include <algorithm>
>> #include "winstl/registry/reg_key_sequence.hpp"
>
>> void print(const winstl::reg_key& key)
>> {
>>     std::cout << key.name().c_str() << std::endl;
>> }
>
>> int _tmain(int argc, _TCHAR* argv[])
>> {
>>     try
>>     {
>>         winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE,
>>             _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"));
>
>>         std::for_each(keys.begin(), keys.end(), print);
>>         return 0;
>>     }
>
>>     catch (std::exception& e)
>>     {
>>         std::cout << e.what() << std::endl;
>>         return 1;
>>     }
>> }
>
>> I debugged the program to find out what the problem is, and in winstl.h I found following definitions:
>
>> #if defined(WIN64)
>> # define WINSTL_OS_IS_WIN64
>> #elif defined(WIN32)
>> # define WINSTL_OS_IS_WIN32
>> #else /* ? WIN?? */
>> # error WinSTL is only compatible with Win32 and Win64
>> #endif /* WIN?? */
>
>> But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my test program, before the include of reg_key_sequence.h:
>
>> #ifdef _WIN64
>> #define WIN64
>> #endif
>
>> Then everything worked fine. So I googled a bit, and it seems that, for
>> Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not.
>> So,
>> to correct this problem, the line in winstl.h should be changed to "#if
>> defined (_WIN64)".
>
>
>> So Long...
>
>> Gabor
>
>
>
> So Long...
>
> Gabor
> 

Hello Matthew!

> This should now be addressed with the latest version: 1.9.105

Yes, it works now. :-) Thanks.



So Long...

Gabor