c++.stlsoft - x64 WinSTL issue with registry and scoped_handle: Urgent help needed
- Austin Ziegler <austin.ziegler evault.com> Sep 11 2008
- "Matthew Wilson" <matthew hat.stlsoft.dot.org> Sep 11 2008
- "Matthew Wilson" <matthew hat.stlsoft.dot.org> Sep 22 2008
- Austin Ziegler <austin.ziegler evault.com> Sep 30 2008
- Gabor.Fischer systecs.com (Gabor Fischer) Jul 28 2010
- Gabor.Fischer systecs.com (Gabor Fischer) Jan 10 2011
- Gabor.Fischer systecs.com (Gabor Fischer) Oct 20 2010
- "Matt Wilson" <matthewwilson acm.org> Dec 26 2010
- Gabor.Fischer systecs.com (Gabor Fischer) Dec 08 2010
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
Sep 11 2008
"Matthew Wilson" <matthew hat.stlsoft.dot.org> 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
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
off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.-austin
Sep 11 2008
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
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
off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.-austin
Sep 22 2008
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
Sep 30 2008
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.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
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
Jul 28 2010
Hello Matthew!This should now be addressed with the latest version: 1.9.105
Yes, it works now. :-) Thanks. So Long... Gabor
Jan 10 2011
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
Oct 20 2010
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
Dec 26 2010
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
Dec 08 2010