64-bit-only coming VERY soon

[Brice Manuel]

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.

[Patrice Terrier]

Some of us made the shift

I found the move from ANSI to UNICODE harder than the move from 32 to 64-bit.

[James C. Fuller]

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

[Patrice Terrier]

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.

[James C. Fuller]

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

[Mike Stefanik]

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.

[Theo Gottwald]

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 :-).

[James C. Fuller]

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

[Patrice Terrier]

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.

[Brice Manuel]

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.

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.

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.

[Frederick J. Harris]

I doubt there will ever be a 64 bit PB, but I've been using this for some time ...

Code: [Select]

#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.

[Mike Stefanik]

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.

[Theo Gottwald]

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.

Important point.

[James C. Fuller]

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

[Patrice Terrier]

James--

Small example of console application i am using to quick test GDImage in 64-bit unicode mode.

Code: [Select]

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;
}