Fixed funcs for safe use in Win32/Win64

[GermanAizek]

• Has this change been discussed on the forum or in an issue before?
• Does the code follow the SFML Code Style Guide?
• Have you provided some example/test code for your changes?
• If you have additional steps which need to be performed list them as tasks!

---

Description

Easy commit for better portability between Windown platforms.

Tasks

• Tested on Linux
• Tested on Windows
• Tested on macOS
• Tested on iOS
• Tested on Android

[GermanAizek]

Dear @LaurentGomila and @Bromeon
Check it. Thx.

[LaurentGomila]

Thanks.

You can give more details (why you changed that, and where it is documented) so that we don't have to guess.

What I found on the MSDN:

Note To write code that is compatible with both 32-bit and 64-bit versions of Windows, use GetWindowLongPtr. When compiling for 32-bit Windows, GetWindowLongPtr is defined as a call to the GetWindowLong function.

[GermanAizek]

@LaurentGomila,
You have correctly found information on function, this pull request simplifies future migration between Windows platforms.
I also ask you to note that GetWindowLong will have the status of an deprecated function and possibly it will be deleted.

[GermanAizek]

@eXpl0it3r, check here 5cc0c68

[eXpl0it3r]

The change shouldn't really make a difference because the window styles are of type LONG i.e. 32-bits values anyways. As such it doesn't matter whether you're building for 32-bits or 64-bits architecture, you will always be dealing with 32-bits values.

But it also doesn't hurt to use the recommended function. For example .NET only ever uses the *Ptr functions.

[eXpl0it3r]

Thanks for this fix! 🙂