32-bit has long been an issue in the gaming world. Within weeks, there will be several major games hitting that will only work on 64-bit versions of Windows. Audio and Video production software needs to follow this lead and ditch 32-bit. I am really glad to see the industry starting to finally make the shift.
Some of us made the shift :)
I found the move from ANSI to UNICODE harder than the move from 32 to 64-bit.
Patrice,
How so?
I have not had any issues that I am aware of, compiling my existing code to 64bit. (with or without adding the UNICODE defines.)
James
James--
Issues, well i would say that in my case sizeof was a nasty one, so easy to forget when translating code from PB to C/C++, especially because that wouldn't raise any error.
Patrice,
I take back what I said. I have issues with UNICODE defined.
I can create 64bit apps without it but it appears I have my work cut out if I want to use it with the bcx/bc9Baisc library routines.
James
It's not just the processor architecture, it looks like the games coming down the road will require 6+ GB of memory (which if you go by Steam's stats, about 50% of gamers still have 4GB or less). I suspect a lot of this is actually being driven by the next generation of consoles, since most PC versions of games these days (at least for the AAA titles) tend to be ports. What will be interesting to watch is what happens with DirectX support. Microsoft has said that DX 11.2 is only going to be available for Windows 8.1 and the Xbox One. This could mean that new games for the Xbox that are ported to the PC would require Windows 8.1 as the minimum operating system. Let the hand-wringing begin.
As i said some time before, the industrie is going the 64 bit way.
Its a chance for them to "dump all the old products and sell it all new".
Therefore they will go "64 bit only" as soon as they can.
Even iPhones are going 64 bit ...(eye-phones? Sounds useless :-).
Patrice,
I spoke too soon. It appears this UNICODE issue has already been addressed and a simple call to a post translation app will transform your c++ ansi source -> c++ unicode. No work for me YAY :) Not fully tested but promising so far.
James
Check thoroughly the use of sizeof everywhere.
And also sendmessage/postmessage when using string pointer and/or the value returned by sendmessage to retrieve a string length.
Quote from: Mike Stefanik on October 09, 2013, 07:22:39 AM
It's not just the processor architecture, it looks like the games coming down the road will require 6+ GB of memory (which if you go by Steam's stats, about 50% of gamers still have 4GB or less).
Until now, the issue with not having 64-bit has always been on the server side for the games. For the games themselves to be 64-bit really will not be an issue nowadays.
Quote from: Mike Stefanik on October 09, 2013, 07:22:39 AMI suspect a lot of this is actually being driven by the next generation of consoles, since most PC versions of games these days (at least for the AAA titles) tend to be ports. What will be interesting to watch is what happens with DirectX support. Microsoft has said that DX 11.2 is only going to be available for Windows 8.1 and the Xbox One. This could mean that new games for the Xbox that are ported to the PC would require Windows 8.1 as the minimum operating system. Let the hand-wringing begin.
Multi-port console games are generally specced to the least powerful console. In this case, it would be the XBox One (which changes on a daily basis) that is less powerful than the PS4. So any games released for both systems will be specced to the XBone, It will be interesting to see how the PC ports are handled. I do not keep up with DX anymore to know how much of a difference there is between 11.2 and 11.1 and 11.0.
I doubt there will ever be a 64 bit PB, but I've been using this for some time ...
#If %Def(%UNICODE)
Macro ZStr = WStringz
Macro BStr = WString
%SIZEOF_CHAR = 2
#Else
Macro ZStr = Stringz
Macro BStr = String
%SIZEOF_CHAR = 1
#EndIf
On a somewhat different note, just the other day I came across some links to a way of using 32 bit COM objects (there are lots of those) in 64 bit code...
http://www.gfi.com/blog/32bit-object-64bit-environment/
Apparently its doable. I had been laboring under the assumption it was not.
Quote from: Frederick J. Harris on October 09, 2013, 09:47:10 PM
On a somewhat different note, just the other day I came across some links to a way of using 32 bit COM objects (there are lots of those) in 64 bit code...
That's one of those "sort of" solutions. Your 64-bit application can't actually load an 32-bit inproc COM server, instead it uses a surrogate that runs under WoW64 which loads the COM object. Effectively you're using the COM object as an out-of-process server, with all of the inherent overhead of marshaling calls across process boundaries (particularly if there's a lot of parameters passed by reference). I think it's really only something that should be done if you have absolutely no other options, and even then it may not work depending on how the COM server was written.
Edit: Also, keep in mind that as of Windows Server 2012, WoW64 is considered an optional feature and may not be installed. It's safe to assume that future desktop versions of Windows will continue to include WoW64 for backwards compatibility, but Microsoft is pushing the transition to 64-bit code harder on the server side of things.
QuoteAlso, keep in mind that as of Windows Server 2012, WoW64 is considered an optional feature and may not be installed. It's safe to assume that future desktop versions of Windows will continue to include WoW64 for backwards compatibility, but Microsoft is pushing the transition to 64-bit code harder on the server side of things.
Important point.
Patrice,
I have issues with console apps and unicode using MinGW.
Do you have any problems with a console app and UNICODE and if not would you post a snippet?
James
James--
Small example of console application i am using to quick test GDImage in 64-bit unicode mode.
int _tmain(int argc, _TCHAR* argv[]) {
WCHAR sImgName[MAX_PATH] = {0}
BOOL bRet = BOOL(Load_GDIPLUS());
LONG_PTR hGDIplus = zGdipStart();
RegisterGDImageClass(); // GDImage class
RegisterGLImageClass(); // OpenGL class
long nWidth = 0, nHeight = 0;
wcscpy_s(sImgName, L"c:\\travail\\gdimage\\bimbo2.png");
ZI_GetImageSizeFromFile(&sImgName[0], nWidth, nHeight);
HWND hParent = GetForegroundWindow();
HWND hWnd = ZI_CreateWindowFromImage (WS_POPUP, sImgName, 800, 100, hParent, 0, 0, ZD_TOPLEFTCOLOR);
wcout << L"Window is " << (long) hWnd << endl;
if (!IsWindowVisible(hWnd)) {
ZI_SetLayeredAlpha(hWnd, 0);
ShowWindow(hWnd, SW_SHOW);
SetFocus(WasFocus);
for (long K = 0; K < 256; K +=2) {
ZI_SetLayeredAlpha(hWnd, (BYTE) K);
Sleep(1); ZD_DoEvents();
ZI_UpdateWindow(hWnd, 1);
}
ZI_SetLayeredAlpha(hWnd, 255);
}
wcout << endl;
system("pause"); // Halts execution; shows the "Press any key to continue..." prompt
zGdipEnd(hGDIplus);
return 0;
}
Patrice,
Thank you. It shows my code is good and that it's a problem with compile/link parameters with g++ .
I have no issues with a gui app just a console. The linker is looking for WinMain.
The more research I do on UNICODE the more of a convoluted mess it becomes :)
James
Patrice,
I found the answer.
http://stackoverflow.com/questions/13871617/winmain-and-main-in-c-extended
James
http://msdn.microsoft.com/en-us/library/windows/desktop/ff381406(v=vs.85).aspx
wxWidgets is a C++ library that lets developers create applications for Windows, OS X, Linux and UNIX on 32-bit and 64-bit architectures as well as several mobile platforms including Windows Mobile, iPhone SDK and embedded GTK+.
http://www.wxwidgets.org/
Patrice,
I have a fork of bcx based on wxWidgets. A real nice library with many useful non-gui items too. They even have their own string class.
I was not able to build the latest version the last time I tried and really don't have much time for it now. Maybe down the road .....
James
I highly recommend the book: Cross-Platform GUI Programming with wxWidgets. It is a bit dated, but still very good book on WxWidgets.
Yes, that is the one. It was invaluable in wrapping my head around wxWidgets which I used with BlitzMax for several projects.