Windows XP support for 1.9 dropped?

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Windows XP support for 1.9 dropped?

Post by Kojack » Wed May 08, 2013 2:22 am

You are the second (possibly third) person who reads this code and thinks that if (sizeof(T) == 4) { } introduces extra overhead... I don't see anyone providing any evidence of this however and it does not make any sense.
As I said above, check the assembly. I did before I posted.

Code: Select all

        bool cas (const T &old, const T &nu)
        {
51128F40  push        ebp  
51128F41  mov         ebp,esp  
51128F43  push        0FFFFFFFFh  
51128F45  push        offset __ehhandler$?cas@?$AtomicScalar@W4LoadingState@Resource@Ogre@@@Ogre@@QAE_NABW4LoadingState@Resource@2@0@Z (51775510h)  
51128F4A  mov         eax,dword ptr fs:[00000000h]  
51128F50  push        eax  
51128F51  sub         esp,118h  
51128F57  push        ebx  
51128F58  push        esi  
51128F59  push        edi  
51128F5A  push        ecx  
51128F5B  lea         edi,[ebp-124h]  
51128F61  mov         ecx,46h  
51128F66  mov         eax,0CCCCCCCCh  
51128F6B  rep stos    dword ptr es:[edi]  
51128F6D  pop         ecx  
51128F6E  mov         eax,dword ptr [___security_cookie (51CF0CA0h)]  
51128F73  xor         eax,ebp  
51128F75  mov         dword ptr [ebp-10h],eax  
51128F78  push        eax  
51128F79  lea         eax,[ebp-0Ch]  
51128F7C  mov         dword ptr fs:[00000000h],eax  
51128F82  mov         dword ptr [ebp-14h],ecx  
            if (sizeof(T)==2) {
51128F85  xor         eax,eax  
51128F87  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+77h (51128FB7h)  
                return _InterlockedCompareExchange16((SHORT*)&mField, static_cast<SHORT>(nu), static_cast<SHORT>(old)) == static_cast<SHORT>(old);
51128F89  mov         ecx,dword ptr [ebp+8]  
51128F8C  mov         ax,word ptr [ecx]  
51128F8F  mov         edx,dword ptr [ebp+0Ch]  
51128F92  mov         cx,word ptr [edx]  
51128F95  mov         edx,dword ptr [ebp-14h]  
51128F98  lock cmpxchg word ptr [edx],cx  
51128F9D  cwde  
51128F9E  mov         ecx,dword ptr [ebp+8]  
51128FA1  movsx       edx,word ptr [ecx]  
51128FA4  xor         ecx,ecx  
51128FA6  cmp         eax,edx  
51128FA8  sete        cl  
51128FAB  mov         al,cl  
51128FAD  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
51128FB2  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
            } 
			else if (sizeof(T)==4) 
51128FB7  mov         edx,1  
51128FBC  test        edx,edx  
51128FBE  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+0A7h (51128FE7h)  
			{
                return _InterlockedCompareExchange((LONG*)&mField, static_cast<LONG>(nu), static_cast<LONG>(old)) == static_cast<LONG>(old);
51128FC0  mov         eax,dword ptr [ebp+8]  
51128FC3  mov         eax,dword ptr [eax]  
51128FC5  mov         ecx,dword ptr [ebp+0Ch]  
51128FC8  mov         edx,dword ptr [ecx]  
51128FCA  mov         ecx,dword ptr [ebp-14h]  
51128FCD  lock cmpxchg dword ptr [ecx],edx  
51128FD1  mov         edx,dword ptr [ebp+8]  
51128FD4  xor         ecx,ecx  
51128FD6  cmp         eax,dword ptr [edx]  
51128FD8  sete        cl  
51128FDB  mov         al,cl  
51128FDD  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
51128FE2  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
			} 
			else if (sizeof(T)==8) {
51128FE7  xor         edx,edx  
51128FE9  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+140h (51129080h)  
                return _InterlockedCompareExchange64((LONGLONG*)&mField, static_cast<LONGLONG>(nu), static_cast<LONGLONG>(old)) == static_cast<LONGLONG>(old);
51128FEF  mov         eax,dword ptr [ebp+8]  
51128FF2  mov         eax,dword ptr [eax]  
51128FF4  cdq  
51128FF5  mov         ecx,eax  
51128FF7  mov         esi,edx  
51128FF9  mov         edx,dword ptr [ebp+0Ch]  
51128FFC  mov         eax,dword ptr [edx]  
51128FFE  cdq  
51128FFF  mov         edi,eax  
51129001  mov         eax,edx  
51129003  mov         dword ptr [ebp-110h],eax  
51129009  mov         eax,ecx  
5112900B  mov         edx,esi  
5112900D  mov         esi,dword ptr [ebp-14h]  
51129010  mov         ebx,edi  
51129012  mov         ecx,dword ptr [ebp-110h]  
51129018  lock cmpxchg8b qword ptr [esi]  
5112901C  mov         ecx,eax  
5112901E  mov         esi,edx  
51129020  mov         edx,dword ptr [ebp+8]  
51129023  mov         eax,dword ptr [edx]  
51129025  cdq  
51129026  mov         dword ptr [ebp-118h],ecx  
5112902C  mov         dword ptr [ebp-114h],esi  
51129032  mov         dword ptr [ebp-120h],eax  
51129038  mov         dword ptr [ebp-11Ch],edx  
5112903E  mov         eax,dword ptr [ebp-118h]  
51129044  cmp         eax,dword ptr [ebp-120h]  
5112904A  jne         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+126h (51129066h)  
5112904C  mov         ecx,dword ptr [ebp-114h]  
51129052  cmp         ecx,dword ptr [ebp-11Ch]  
51129058  jne         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+126h (51129066h)  
5112905A  mov         dword ptr [ebp-124h],1  
51129064  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+130h (51129070h)  
51129066  mov         dword ptr [ebp-124h],0  
51129070  mov         al,byte ptr [ebp-124h]  
51129076  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
            } 
			else {
5112907B  jmp         Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+1C2h (51129102h)  
                OGRE_EXCEPT(Exception::ERR_NOT_IMPLEMENTED,"Only 16, 32, and 64 bit scalars supported in win32.","AtomicScalar::cas");
51129080  push        offset string "AtomicScalar::cas" (518DF8A8h)  
51129085  lea         ecx,[ebp-34h]  
51129088  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (50AC8FA6h)  
5112908D  mov         dword ptr [ebp-4],0  
51129094  push        offset string "Only 16, 32, and 64 bit scalars "... (518DF868h)  
51129099  lea         ecx,[ebp-54h]  
5112909C  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (50AC8FA6h)  
511290A1  mov         byte ptr [ebp-4],1  
511290A5  xor         edx,edx  
511290A7  mov         byte ptr [ebp-109h],dl  
511290AD  push        112h  
511290B2  push        offset string "d:\\work\\qgf5_2013\\dev\\sdk\\includ"... (518DF820h)  
511290B7  lea         eax,[ebp-34h]  
511290BA  push        eax  
511290BB  lea         ecx,[ebp-54h]  
511290BE  push        ecx  
511290BF  movzx       edx,byte ptr [ebp-109h]  
511290C6  push        edx  
511290C7  lea         eax,[ebp-108h]  
511290CD  push        eax  
511290CE  call        Ogre::ExceptionFactory::create (50AABECEh)  
511290D3  add         esp,18h  
511290D6  push        offset __TI3?AVUnimplementedException@Ogre@@ (51A88998h)  
511290DB  lea         ecx,[ebp-108h]  
511290E1  push        ecx  
511290E2  call        _CxxThrowException (5163EF60h)  
511290E7  mov         byte ptr [ebp-4],0  
511290EB  lea         ecx,[ebp-54h]  
511290EE  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (50ABD561h)  
511290F3  mov         dword ptr [ebp-4],0FFFFFFFFh  
511290FA  lea         ecx,[ebp-34h]  
511290FD  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (50ABD561h)  
            }
        }
In particular these bits:

Code: Select all

            if (sizeof(T)==2) {
51128F85  xor         eax,eax  
51128F87  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+77h (51128FB7h)  
                return _InterlockedCompareExchange16((SHORT*)&mField, static_cast<SHORT>(nu), static_cast<SHORT>(old)) == static_cast<SHORT>(old);

Code: Select all

			else if (sizeof(T)==4) 
51128FB7  mov         edx,1  
51128FBC  test        edx,edx  
51128FBE  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+0A7h (51128FE7h)  
			{
                return _InterlockedCompareExchange((LONG*)&mField, static_cast<LONG>(nu), static_cast<LONG>(old)) == static_cast<LONG>(old);

Code: Select all

			else if (sizeof(T)==8) {
51128FE7  xor         edx,edx  
51128FE9  je          Ogre::AtomicScalar<enum Ogre::Resource::LoadingState>::cas+140h (51129080h)  
                return _InterlockedCompareExchange64((LONGLONG*)&mField, static_cast<LONGLONG>(nu), static_cast<LONGLONG>(old)) == static_cast<LONGLONG>(old);
No, it doesn't explicitly do if(2==2), if(4==4) or if(8==8). Instead it does:
xor eax,eax (makes eax = 0)
je (jump if eax is zero)
equivalent to if(false), it skips the code for size 2

move edx,1 (makes edx = 1)
test edx,edx (edx & edx)
je (jump if edx is zero, which is never will be)
equivalent to if(true)

So the assembly is explicitly doing:
if(false)
{
_InterlockedCompareExchange16
}
else if(true)
{
_InterlockedCompareExchange
}
else if(false)
{
_InterlockedCompareExchange64
}
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: Windows XP support for 1.9 dropped?

Post by sparkprime » Wed May 08, 2013 3:29 am

This is with optimisations enabled?
0 x

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7147
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 16

Re: Windows XP support for 1.9 dropped?

Post by Kojack » Wed May 08, 2013 3:45 am

No, it's the debug build I've been talking about. None of those branches should exist in an optimised build since the tests can be evaluated at compile time.

On a partly related note, apparently VS2012 Update 2 (which we use for the ogre 2012 sdks) breaks XP compatibility too, but Update 3 RC1 should fix it.
http://blogs.msdn.com/b/vcblog/archive/ ... g-mfc.aspx
0 x

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: Windows XP support for 1.9 dropped?

Post by sparkprime » Wed May 08, 2013 3:54 am

OK but of course performance is going to be poor in debug mode. It looks like it does constant propagation (since you need that to instantiate templates so they probably do it globally) but not dead code elimination. That's their call.

If you're saying we should make the c++ source code more complex in order to get better performance without compiler optimisation then I disagree very strongly.

If you're saying we should make the c++ code more complex to avoid the symbol then *maybe* but it would be preferable to find a fix that doesn't depend on template instantiation.

At any rate I don't think any of this has anything to do with his original problem, since he said he commented out the call and rebuilt and that did not help. This code has been in Ogre 5 years or so, and I have spent most of that time on XP so something else must be going on here.
0 x

bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia

Re: Windows XP support for 1.9 dropped?

Post by bstone » Wed May 08, 2013 5:07 pm

Yeah, ignore my comment about the excessive branching since that won't happen in release builds. I was thinking in the context of that linking issue. I even doubt that debug builds were the problem in the first place. But something weird is going on there.
0 x

FuzzyShoting
Kobold
Posts: 28
Joined: Sun Apr 22, 2012 3:34 pm

Re: Windows XP support for 1.9 dropped?

Post by FuzzyShoting » Sun May 12, 2013 9:39 pm

I replaced _InterlockedCompareExchange64 with __InterlockedCompareExchange64

And inserted

Code: Select all

inline LONGLONG __InterlockedCompareExchange64(LONGLONG volatile* Destination, LONGLONG Exchange, LONGLONG Comperand)
{
   __asm {
      mov esi, [Destination]
      mov ebx, dword ptr [Exchange]
      mov ecx, dword ptr [Exchange + 4]
      mov eax, dword ptr [Comperand]
      mov edx, dword ptr [Comperand + 4]
         lock cmpxchg8b [esi]
   }
}
in hopes of it working. But no dice. Was given the same message.
Is it even in this file that the error is?

So what I ended up trying was to take the ogre 1.8 atomic file, insert that entirely, recompile and merge minor missing codes. And it still gave off errors.
0 x

MartinSliwka
Gnoblar
Posts: 1
Joined: Tue Jul 09, 2013 3:37 pm

Re: Windows XP support for 1.9 dropped?

Post by MartinSliwka » Wed Jul 10, 2013 2:36 pm

Problem lies in OgreAtomicWrappers.h and is not caused by using intrinsic _InterlockedCompareExchange64 but by using InterlockedIncrement64 and InterlockedDecrement64. They are implemented in winbase.h as inline functions using API function InterlockedCompareExchange64.

So I replaced all Interlocked functions with their intrinsic variant (function name starts with underscore). And because _InterlockedIncrement64 and _InterlockedDecrement64 intrinsic are not available in x86 builds I had to reimplement them. I used inline functions from winbase.h, pasted them at start of MSVC #ifdef section and changed them to use intrinsic _InterlockedCompareExchange64 instead of API function InterlockedCompareExchange64:

Code: Select all

...

#elif OGRE_COMPILER == OGRE_COMPILER_MSVC && OGRE_COMP_VER >= 1400 && OGRE_THREAD_SUPPORT

#ifndef WIN32_LEAN_AND_MEAN
#  define WIN32_LEAN_AND_MEAN
#endif
#if !defined(NOMINMAX) && defined(_MSC_VER)
#	define NOMINMAX // required to stop windows.h messing up std::min
#endif
#include <windows.h>
#include <intrin.h>

// copied from winbase.h and changed to use intrinsic _InterlockedCompareExchange64 instead of API InterlockedCompareExchange64
#ifndef _WIN64

FORCEINLINE	LONGLONG _InterlockedIncrement64( __inout LONGLONG volatile *Addend )
{
	LONGLONG Old;

	do {
		Old = *Addend;
	} while (_InterlockedCompareExchange64(Addend, Old + 1, Old) != Old);

	return Old + 1;
}

FORCEINLINE LONGLONG _InterlockedDecrement64 ( __inout LONGLONG volatile *Addend )
{
	LONGLONG Old;

	do {
		Old = *Addend;
	} while (_InterlockedCompareExchange64(Addend, Old - 1, Old) != Old);

	return Old - 1;
}

#endif

...
0 x

Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Re: Windows XP support for 1.9 dropped?

Post by Oogst » Fri Aug 02, 2013 6:38 pm

I am encountering the same problem, and from the posts in this topic it does not quite become clear to me what I need to do to solve it. Lots of ideas, but which actually works?

Is it enough to 'simply' compile Ogre myself on my WindowsXP machine?
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 2

Re: Windows XP support for 1.9 dropped?

Post by syedhs » Sun Aug 04, 2013 3:51 am

I think the last post before yours does it.. it seems so..
0 x
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me

Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Re: Windows XP support for 1.9 dropped?

Post by Oogst » Tue Aug 20, 2013 9:59 pm

I tried the solution of simply compiling Ogre 1.9RC myself on a Windows XP machine, and doing only that already turns out to solve the problem. Apparently when compiled on Windows XP, Ogre does not attach itself to functions that are not available on Windows XP. :)
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

User avatar
vilgeits
Goblin
Posts: 298
Joined: Tue Aug 02, 2005 10:41 pm

Re: Windows XP support for 1.9 dropped?

Post by vilgeits » Wed Aug 21, 2013 12:24 pm

Oogst wrote:I tried the solution of simply compiling Ogre 1.9RC myself on a Windows XP machine, and doing only that already turns out to solve the problem. Apparently when compiled on Windows XP, Ogre does not attach itself to functions that are not available on Windows XP. :)
Probably it could work perfectly but its far away from being a elegant solution IMO, probably a change on OGRE source should be performed.
0 x

Oogst
OGRE Expert User
OGRE Expert User
Posts: 1034
Joined: Mon Mar 29, 2004 8:49 pm
Location: the Netherlands
Contact:

Re: Windows XP support for 1.9 dropped?

Post by Oogst » Thu Aug 22, 2013 11:01 am

I totally agree that the Ogre team should solve this issue properly. Ogre mentions in the features that it supports "Windows (all major versions)", while the current SDK that you download from the Ogre website doesn't run on Windows XP (which is still used quite commonly).

Does anyone know whether a bug for this is already reported in the JIRA tracker? Maybe it is even already fixed in the latest development revision?

For me for the moment compiling myself is a fine solution, though, so I am happy. :)
0 x
blog.oogst3d.net: my dev blog and portfolio
Ronimo Games: my game dev company
Awesomenauts: platforming MOBA (PC/Mac/Linux/XBox360/PS3/PS4)
Swords & Soldiers: side-scrolling RTS (PS3/Wii/PC/Mac/Linux/iPhone/iPad/Android)
Proun: abstract racing game (PC)
Cello Fortress: mixing game and live cello performance

User avatar
vilgeits
Goblin
Posts: 298
Joined: Tue Aug 02, 2005 10:41 pm

Re: Windows XP support for 1.9 dropped?

Post by vilgeits » Sat Aug 24, 2013 9:45 am

MartinSliwka wrote:Problem lies in OgreAtomicWrappers.h and is not caused by using intrinsic _InterlockedCompareExchange64 but by using InterlockedIncrement64 and InterlockedDecrement64. They are implemented in winbase.h as inline functions using API function InterlockedCompareExchange64.

So I replaced all Interlocked functions with their intrinsic variant (function name starts with underscore). And because _InterlockedIncrement64 and _InterlockedDecrement64 intrinsic are not available in x86 builds I had to reimplement them. I used inline functions from winbase.h, pasted them at start of MSVC #ifdef section and changed them to use intrinsic _InterlockedCompareExchange64 instead of API function InterlockedCompareExchange64:

Code: Select all

...

#elif OGRE_COMPILER == OGRE_COMPILER_MSVC && OGRE_COMP_VER >= 1400 && OGRE_THREAD_SUPPORT

#ifndef WIN32_LEAN_AND_MEAN
#  define WIN32_LEAN_AND_MEAN
#endif
#if !defined(NOMINMAX) && defined(_MSC_VER)
#	define NOMINMAX // required to stop windows.h messing up std::min
#endif
#include <windows.h>
#include <intrin.h>

// copied from winbase.h and changed to use intrinsic _InterlockedCompareExchange64 instead of API InterlockedCompareExchange64
#ifndef _WIN64

FORCEINLINE	LONGLONG _InterlockedIncrement64( __inout LONGLONG volatile *Addend )
{
	LONGLONG Old;

	do {
		Old = *Addend;
	} while (_InterlockedCompareExchange64(Addend, Old + 1, Old) != Old);

	return Old + 1;
}

FORCEINLINE LONGLONG _InterlockedDecrement64 ( __inout LONGLONG volatile *Addend )
{
	LONGLONG Old;

	do {
		Old = *Addend;
	} while (_InterlockedCompareExchange64(Addend, Old - 1, Old) != Old);

	return Old - 1;
}

#endif

...
Your solution works like a charm, should't it be included?
0 x

User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4291
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 2
Contact:

Re: Windows XP support for 1.9 dropped?

Post by spacegaier » Sat Aug 24, 2013 11:25 am

IF that solution works, it might be worth to create a JIRA ticket with a linked BitBucket pull request and the team will review it and decide whether it should get included. Perhaps also link this thread in the JIRA ticket as a reference.
0 x
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...

User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
Contact:

Re: Windows XP support for 1.9 dropped?

Post by sparkprime » Mon Aug 26, 2013 10:49 pm

I will have to do it in my fork if it's not done upstream, since I have users complaining about it now :)
0 x

cyberjunk
Halfling
Posts: 51
Joined: Tue Jun 05, 2012 4:33 pm

Re: Windows XP support for 1.9 dropped?

Post by cyberjunk » Thu Sep 12, 2013 1:55 am

I'm having the exactly same issue when building Ogre 1.9.0 from RC1 sources for 32-Bit and running it on Windows XP.

My OgreMain.dll always has an import to the InterlockedCompareExchange64 Windows API function from kernel32.dll
However this function is only available on Vista or later, so I get the mentioned error message on startup.
BTW: I'm using DepencyWalker to check which DLL imports which functions from windows api...

This issue basically has nothing to do with 64Bit, unlike mentioned by someone.
The API function can be called on x86/x64 systems and also can be used from x86/x64 applications, just as long as it's at least Windows Vista.

I checked all statically linked sub components (since these can also cause this), but none of them makes use of InterlockedCompareExchange64.
The boost headers for the atomic component mention the function, but I checked my dynamically linked boost DLL an none of them imports InterlockedCompareExchange64
So what's left is the OgreMain source which most likely causes the import of InterlockedCompareExchange64 (I thought) ??
The cas(...) method of AtomicScalar in OgreAtomicWrapper.h ...

So I checked where this function is called, and it seems just the OgreAtomicWrappers.h itself as generic argument, and the OgreResource.cpp.
Here actually the enum "LoadingState" from "OgreResource.h" is passed..

I just went ahead and uncommented the elseif block that calls InterlockedCompareExchange64, and know what? My OgreMain.dll still has an import of InterlockedCompareExchange64
Hell, where does it come from :shock:

Edit:
I also tried to follow MartinSliwka's suggestion. As far as I understand this, InterlockedCompareExchange64 is also called from within InterlockedDecrement64 and InterlockedIncrement64.
At least that explains why I still have an import even when I deleted the use of InterlockedIncrement64 in the cas() method.

However after compiling with his "fix" I still have an import of InterlockedCompareExchange64 :cry:
Also, from what I get from his code snippet, his replacements for InterlockedIncrement64 and InterlockedDecrement64 still call InterlockedCompareExchange64, what he before mentioned as the "wrong" behaviour of the internal functions. So it seems like a good start, but wouldn't it be required to replace the InterlockedCompareExchange64 calls with other implementations?

Edit2:
Ok, I figured it out. MartinSliwka's solution indeed works! However you not only have to copy+paste the code block, but also replace any appearance of InterlockedIncrement64 and InterlockedDecrement64 with a variant having a "_" prefix (in OgreAtomicWrappers.h), so his new definitions actually get called :)
0 x

Nicolay77
Gnoblar
Posts: 3
Joined: Wed Sep 11, 2013 3:51 am

Re: Windows XP support for 1.9 dropped?

Post by Nicolay77 » Thu Sep 12, 2013 3:21 am

cyberjunk wrote: Edit2:
Ok, I figured it out. MartinSliwka's solution indeed works! However you not only have to copy+paste the code block, but also replace any appearance of InterlockedIncrement64 and InterlockedDecrement64 with a variant having a "_" prefix (in OgreAtomicWrappers.h), so his new definitions actually get called :)
Or do this, as it seems shorter than a search & replace:

Code: Select all

 ...

 #ifndef _WIN64

+#define InterlockedIncrement64 _InterlockedIncrement64
+#define InterlockedDecrement64 _InterlockedDecrement64

 FORCEINLINE   LONGLONG _InterlockedIncrement64( __inout LONGLONG volatile *Addend )
 ...
0 x

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Windows XP support for 1.9 dropped?

Post by Klaim » Thu Sep 12, 2013 4:35 pm

cyberjunk wrote:I'm having the exactly same issue when building Ogre 1.9.0 from RC1 sources for 32-Bit and running it on Windows XP.

My OgreMain.dll always has an import to the InterlockedCompareExchange64 Windows API function from kernel32.dll
However this function is only available on Vista or later, so I get the mentioned error message on startup.
BTW: I'm using DepencyWalker to check which DLL imports which functions from windows api...

This issue basically has nothing to do with 64Bit, unlike mentioned by someone.
The API function can be called on x86/x64 systems and also can be used from x86/x64 applications, just as long as it's at least Windows Vista.

I checked all statically linked sub components (since these can also cause this), but none of them makes use of InterlockedCompareExchange64.
The boost headers for the atomic component mention the function, but I checked my dynamically linked boost DLL an none of them imports InterlockedCompareExchange64
So what's left is the OgreMain source which most likely causes the import of InterlockedCompareExchange64 (I thought) ??
The cas(...) method of AtomicScalar in OgreAtomicWrapper.h ...

So I checked where this function is called, and it seems just the OgreAtomicWrappers.h itself as generic argument, and the OgreResource.cpp.
Here actually the enum "LoadingState" from "OgreResource.h" is passed..

I just went ahead and uncommented the elseif block that calls InterlockedCompareExchange64, and know what? My OgreMain.dll still has an import of InterlockedCompareExchange64
Hell, where does it come from :shock:

Edit:
I also tried to follow MartinSliwka's suggestion. As far as I understand this, InterlockedCompareExchange64 is also called from within InterlockedDecrement64 and InterlockedIncrement64.
At least that explains why I still have an import even when I deleted the use of InterlockedIncrement64 in the cas() method.

However after compiling with his "fix" I still have an import of InterlockedCompareExchange64 :cry:
Also, from what I get from his code snippet, his replacements for InterlockedIncrement64 and InterlockedDecrement64 still call InterlockedCompareExchange64, what he before mentioned as the "wrong" behaviour of the internal functions. So it seems like a good start, but wouldn't it be required to replace the InterlockedCompareExchange64 calls with other implementations?

Edit2:
Ok, I figured it out. MartinSliwka's solution indeed works! However you not only have to copy+paste the code block, but also replace any appearance of InterlockedIncrement64 and InterlockedDecrement64 with a variant having a "_" prefix (in OgreAtomicWrappers.h), so his new definitions actually get called :)

First, if as I suspect you are using TBB, then I reported the problem there with a simpler solution: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=78443
The origin of the bug is not the sources. If you're not using TBB, then the problem still comes from a configuration activating only the API from very old Windows versions.

Second, I made a patch, it's not reviewed yet becaus of lack of tests with MINGW (but it's so simple I don't think it's wrong): https://bitbucket.org/sinbad/ogre/pull- ... g-tbb/diff
0 x

cyberjunk
Halfling
Posts: 51
Joined: Tue Jun 05, 2012 4:33 pm

Re: Windows XP support for 1.9 dropped?

Post by cyberjunk » Thu Sep 12, 2013 7:55 pm

First, if as I suspect you are using TBB, then I reported the problem there with a simpler solution:
Nope, not using TBB, but thanks for the hint anyways...
I used the fix mentioned above and so far I'm fine now.
I can confirm basically anything written about it...
It's actually those Increment and Decrement methods which caused the import for me.

My Ogre 1.9 build now runs on WinXP.
In fact it's compiled on a Win8 x64 machine using VS2012.
Not especially the kind of buildenvironment I can recommend for XP compatibility, believe me (so many other issues).
So I'm glad it's working now.
0 x

dermont
Orc Shaman
Posts: 781
Joined: Thu Dec 09, 2004 2:51 am
x 9

Re: Windows XP support for 1.9 dropped?

Post by dermont » Mon Oct 07, 2013 12:15 pm

This still appears to be an issue with 1.9 on WIndows XP. Any reason why MartinSliwka/cyberjunk suggestions haven't been implemented?
0 x

Sawyer
Gnoblar
Posts: 3
Joined: Mon Jul 15, 2013 4:15 pm

Re: Windows XP support for 1.9 dropped?

Post by Sawyer » Tue Oct 22, 2013 12:46 am

Oogst wrote:while the current SDK that you download from the Ogre website doesn't run on Windows XP (which is still used quite commonly). Does anyone know whether a bug for this is already reported in the JIRA tracker? Maybe it is even already fixed in the latest development revision?
It does not appear this is submitted yet (I registered with the JIRA tracker intending to, but am still learning that).

The problem is also present in the default branch Tindalos (now in OgreAtomicScalar.h)

Using XP here. The code posted by MartinSliwka and Nicolay77 seem to have done the trick.
0 x

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: Windows XP support for 1.9 dropped?

Post by Assaf Raman » Sun Nov 03, 2013 5:53 pm

0 x
Watch out for my OGRE related tweets here.

Post Reply