RenderSurface_Win32 compiling on 64 bit Windows is confusing. But apparently it is at least consistent with Microsoft's terminology: they are calling the 64 bit version of the Windows API "Win32 for 64 bit Windows", rather than "Win64". In my experience the 32 vs. 64 naming scheme on 64 bit Windows is a total mish-mash, with "32" directory/file names containing 64 bit code and vice versa, so you're likely to confuse someone no matter what name is used.
The Microsoft math is derived from Boost's VC config header, so I'm assuming it's kosher. See http://www.boost.org/boost/config/compiler/visualc.hpp . -Mike ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Burns Sent: Thursday, September 07, 2006 12:01 PM To: osg users Subject: Re: Re: [osg-users] Build Problems: OSG 1.2 RC 2 with VC 6 I'd support something a lot cleaner than we have now. It is quite confusing to have RenderSurface_Win32 compile on Windows64 and _WIN32 to distinguish VisualStudio version. We need not follow suit with microsoft math ( 1200 == VC++6.0 ). However, I'll relegate to someone with more knowledge of these differences than I. -don On 9/7/06, Mike Wittman <[EMAIL PROTECTED]> wrote: Hi Don and Philip, Could we gate out these (and any other) VC 6 specific changes with #if _MSC_VER == 1200 // 1200 == VC++ 6.0 or #if defined(WIN32) && _MSC_VER == 1200 // 1200 == VC++ 6.0 rather than #if _WIN32 ? This appears to be the recommended way to detect MSVC version. The use of #if _WIN32 may be confusing as the #else code is valid (and is actually used) under later versions of the compiler. -Mike ________________________________________ From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Don Burns Sent: Wednesday, September 06, 2006 5:57 PM To: osg users Subject: Re: Re: [osg-users] Build Problems: OSG 1.2 RC 2 with VC 6 Hi Philip, I've made these changes and will check them in as soon as the compile looks OK here in Linux land. Windows users please test. The one I am not including though is this one: src\PipeTimer.cpp(128 in double PipeTimer::getElapsedTime( GLuint query ) #ifdef _WIN32 return 0.0; /* Temp fix */ #else if( !_valid ) return 0.0; GLuint64EXT timeElapsed = 0; GLint available = 0; while( !available ) { (*_glGetQueryObjectiv)( query, GL_QUERY_RESULT_AVAILABLE, &available ); } (*_glGetQueryObjectui64v)(query, GL_QUERY_RESULT, &timeElapsed ); return (double)timeElapsed*_div; #endif It seems this just turns off the PipeTimer functionality for all win32 users. Did you have a good reason for doing this? -don On 9/6/06, Philip Taylor <[EMAIL PROTECTED]> wrote: Just an update - editing the VS6 Project Settingsis trivial - a pain but trivial so I reckon this is just a simple "TODO" (or "MUSTDO") for VS 6 users. but more VS 6 build issues ================================== OpenThreads ================================== Win32Thread.cpp(554) : error C2065: 'DWORD_PTR' : undeclared identifier The line should read "DWORD res" instead of "DWORD_PTR res", as this the value returned by SetThreadAffinityMask ================================== Producer - all 64 bit issues ================================== Producer\PipeTimer(10) fails to compile unless defined as #ifdef _WIN32 typedef __int64 GLint64EXT; typedef unsigned __int64 GLuint64EXT; #else typedef long long int GLint64EXT; typedef unsigned long long int GLuint64EXT; #endif ================================ Producer/RenderSurface_Win32.cpp( 260,279, 1379 ) #ifdef _WIN32 SetWindowLong(_win, GWL_WNDPROC, (LONG) _oldWndProc); #else SetWindowLongPtr(_win, GWLP_WNDPROC, (LONG_PTR)_oldWndProc); #endif Producer/RenderSurface_Win32.cpp(770) #ifdef _WIN32 _oldWndProc = (WNDPROC)SetWindowLong(_win, GWL_WNDPROC, (LONG) ((WNDPROC)s_proc) ); #else _oldWndProc = (WNDPROC)SetWindowLongPtr(_win, GWLP_WNDPROC, (LONG_PTR)((WNDPROC)s_proc)); #endif ================================ src\PipeTimer.cpp(128 in double PipeTimer::getElapsedTime( GLuint query ) #ifdef _WIN32 return 0.0; /* Temp fix */ #else if( !_valid ) return 0.0; GLuint64EXT timeElapsed = 0; GLint available = 0; while( !available ) { (*_glGetQueryObjectiv)( query, GL_QUERY_RESULT_AVAILABLE, &available ); } (*_glGetQueryObjectui64v)(query, GL_QUERY_RESULT, &timeElapsed ); return (double)timeElapsed*_div; #endif src/ConfigLexer.cpp(24) #include <stdio.h> // to define EOF ================================ OpenSceneGraph ================================ The following .dsp files can't be loaded - all modified for VS 7 i think freetype.dsp ive.dsp dot_osg.dsp No doubt there will be a few more issues to resolve ================================ regards Philip -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Philip Taylor Sent: 06 September 2006 21:03 To: osg users Subject: RE: Re: [osg-users] Build Problems: OSG 1.2 RC 2 with VC 6 Hi Mike, Robert There is one other VS 6 gotcha - see the attached picture. VS 6 objects to a project' Generalsettings including environmental variables. Onhitting the OK button, it erases them from the workspace and apparently from the disk since even if I cancel the settings dialog and close the workspace without saving, these variables never return. The reality is that its not a big deal if the VS 6 build solution is to just delete the PlatformName and ConfigurationName environmental names from the workspaces. I'll report back if any other solution appears --- just don't wait for one, since it would probably be unique to VS 6 and undo the good work put in by Mike. My preferred solution is just to make it a documentation issue and amend the README file, something along the lines of: "VS 6 users must delete references to PlatformName and ConfigurationName environmental names from the workspace before attempting a build." or as per Mike's suggestion, perhaps OSG could include two command (.BAT) filesfor 32 bit Debug and Release builds which set the variables and then invoke the compiler. Not so intuative, but this requires no changes to the various .dsp / .dsw files, except perhaps the gotcha. The users just have to remember that switching builds between Debug and Release means exiting VS 6 and invoking the alternative BAT file. Personally I think I prefer the former, but time will tell......... regards Philip _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
