Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, March 8, 2019 2:19 PM
I am finally making the plans to recompile a very large platform application to 64 bit. The odds are good I will be doing mixed 32/64 and even a few C# projects. I have some setup questions. I am using VS2015.
- Whats the difference between amd64 and x64?
2 For a x64 Command Prompt Window, I prepared a shortcut to call "vcvarsall.bat x64" passing x64 option. What are the options amd64_x86 or x86_amd64 for? What compiler environment do they offer? Why/When would I use it? I couldn't find any online info on them.
When starting a brand new project with VS IDE. I don't see a "WIN64" template to create a C++ x64 project. Do I select Win32 and then change the target to x64? That seem to work in a test project.
For existing 32bit (x86) projects, what are the proper steps to create a x64 configuration and project? I am following this link:
But the step 5 seems to be off. I don't see a Win64 or x64 option (except in the Copy from). Do I need to type "Win64" or x64? in the Type or select the new platform?
Thanks
PS: Is is true, VS2019 will no loner offer targeting XP? This could stop me from getting VS2019 is it doesn't offer a way to compile 32 bit v1xx_xp versions? I have lots of paying customers who use 32 bit XP for Games playing. I can't abandoned them.
Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com
All replies (5)
Friday, March 8, 2019 7:12 PM âś…Answered | 1 vote
1) Nothing*, AMD64 is AMD's flavour, x64 is the generic term. Because of how things happened, Intel started working on a completely new architecture in IA64 but AMD started working on extending x86. It wasn't until a while later that Intel themselves provided the extended x86 in the form of EMT64. Because AMD got there first, there are still places where it is still called AMD64.
2) The way you look at these is host_target. So amd64_x86 is an x64 compiler targeting x86 and x86_amd64 is an x86 compiler targeting x64.
The first one can be useful if you are targeting 32 bit Windows but have source that take up a lot of RAM, there are some template expansions that can exhaust the 32 bit compiler's address space. The second one is useful for building applications when you are still on a 32 bit system.
These were renamed in VS2017 to Hostx64\x86 and Hostx86\x64.
3) Interestingly enough these were renamed in Visual Studio 2017 Update 3 precisely because they didn't describe the project type properly.
3, 4) The x64 target should be added to the project automatically when you create the project.
So this shouldn't need to be followed unless you are using a project/solution which you first created before Visual Studio 2012, I think.
The fact that you are seeing x64 in copy from means that the project already has x64 as a platform.
5) VS2017 will still target XP, but yes, 2019 is dropping XP support. The decision was made to drop support for an operating system that has been out of support for almost 5 years, and the remaining variants will be out of support by April this year.
VS2019 will be able to use the VS2017 and 2015 compilers, like VS2017 is able to use the 2015 compilers, so it is still able to target XP using those.
As you should already know yourself, it is a pain to target XP because of the lack of some features. The UCRT and VCRuntime has had a lot of compatibility in it that has been making these a pain to support. Since they have dropped support for XP in 2019, the VCRuntime has already had major improvements in speed, for example memset is over 2 times faster. So unfortunately the XP support isn't free.
*There are a couple of instructions that work slightly differently, but that is all.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Sunday, March 10, 2019 1:43 PM
Thanks Darran. You are very helpful.
I seem to recall how AMD was more interested in 32 bit compatibility.
So if my development/build box is 64 bi and I building for 32 bitt, ideally, I should of been using "vcvarsall.bat amd64_x86" set instead of "vcvarsall.bat x86?"
3,4) I was thinking that I missed an install option but I looked at the install/setup modify and didn't see anything specific to 64 bit that wasn't enabled. How about template wise? That is the one thing I didn't play with and probably could of made use of. I am going to check that out.
- Well, I can't dictate what customers want to use. XP is still widely used and for legacy operations where change is not expected, it is stable. Since the product offers virtual RS232 modem and TCP/IP support, including 16 bit VDM support, there are still many customers (mostly on the smaller side) who have integrated turnkey boxes with many tools and hosting apps, game playing apps. Today they normally use a XP VM and they don't care for Windows XP updates. But our software, since we are still pure WIN32, with absolutely nothing that caters to new OSes only, there was no reason to abandon them, nor their money for our updates!
That said, yes, it is time to move forward and customers understand this too. I've held back too long. The odds are good I will single source but split two 32/64 bit compiling and build processes. I will try to single source as much as possible but I am not going to worry about XP/2000/2003/NT4 compatibility much more. I'll keep older versions around.
The 64 bit porting effort is going to be big. There are areas were inline assembly (__asm) was used. I converted most of it to C/C++, and I got it down to one part that is going to be most difficult, a challenge. This is with a backend p-code RTE where __asm is used to prepare the prolog and epilog for imported external (WIN32 WinAPI entry) DLL function calls. The backend has a BASIC-like (*.WCC source ext) language p-code compiler with WCX output images. WCX libraries are an inherent part of the product UI, i.e. telnet/console/ansi used for legacy console operations (for an example, telnet bbs.winserver.com), web UI and hooks for various events. WCX developers can import WIN32 WinAPI entry ready *.DLLs, l.e. kernel32.dll, etc, into their WCX apps.
So a big thing will be the idea of a 64 bit RTE calling 32 or 64 bit DLLs external functions. That will be very challenging, compatibility wise,. If its even possible or a good idea, it could be a show stopper or big bump on the road. It is all still in the planning stage, researching, etc. I'm going thru this reading now. :) Process Interoperability
Thanks
Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com
Sunday, March 10, 2019 4:34 PM | 1 vote
2) For most building it doesn't matter. But yes, the x64_x86 or amd64_x86 compiler will give you a 64 bit process that targets x86. You should see the Visual Studio 2015 x64 x86 Cross Tools Command Prompt in the start menu which will run vcvarsall with this.
3,4) The project templates were renamed from Win32 to Windows Desktop because Win32 is not a good name for the projects now. The templates add the x64 platform to the project by default, which is easily verifiable from Visual Studio itself.
You should always see the Debug x86 at the top of the Visual Studio window when you create a new project, depending on usage this may be set to something different. But if you click the x86 box and the drop down menu contains x64, then the settings for the x64 platform are already in the project and solution.
You can also open the .sln file and .vcxproj file in a text editor. If you do, you should find things like:
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|x64 = Debug|x64
Debug|x86 = Debug|x86
Release|x64 = Release|x64
Release|x86 = Release|x86
EndGlobalSection
and:
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
in these files. Even though I mostly use VS2017 these days, I still have projects created with VS2015 and they all have the x64 platform added in the project.
What's more, in Visual Studio 2017 it is possible to build applications for ARM64.
So whenever you see Win32, think Windows Desktop. It doesn't mean that it is limited to 32 bit only.
5) I will not really go into much here. Discussing Microsoft's thoughts and motivations behind removing things won't change their mind.
The things which helped porting for me when I started the effort back in ~2009 when Windows 7 was released were:
Look into the compiler intrinsics available on x64. A lot of the time you can replace ASM blocks using these.
For those annoying times where you can't, ML64 is available.
While you are getting used to writing 64 bit code (quite a lot of the time you can write code that is 32 and 64 bit compilable at the same time) keep the warnings at level 4 and don't ignore warnings. The compiler does warn on truncation or expansion of pointers:
1>c:\users\archa\source\repos\meh\source\main.cpp(7): warning C4311: 'reinterpret_cast': pointer truncation from 'void *' to 'int'
1>c:\users\archa\source\repos\meh\source\main.cpp(7): warning C4302: 'reinterpret_cast': truncation from 'void *' to 'int'
1>c:\users\archa\source\repos\meh\source\main.cpp(9): warning C4312: 'reinterpret_cast': conversion from 'int' to 'void *' of greater size
So keep an eye out.
Double check functions used if you are working with Windows. For example, GetWindowLong and GetClassLong are functions that return 32 bit values. The problem is, they return pointers. So on 64 bit versions of Windows, these wouldn't work. For 64 bit Windows, Microsoft added the Ptr versions of these functions, so GetWindowLongPtr, SetWindowLongPtr, GetClassLongPtr and SetClassLongPtr. These work as 64 bit on 64 bit Windows and get redirected to the 32 bit equivalent on 32 bit Windows.
So if you are storing user data, and you are using:
user_data *data = /*initialise somehow*/
SetWindowsLong(window, GWL_USERDATA, reinterpret_cast<LONG>(data));
you can simply replace this with:
user_data *data = /*initialise somehow*/
SetWindowsLongPtr(window, GWLP_USERDATA, reinterpret_cast<LONG_PTR>(data));
and it is now 64 bit compatible and still works on 32 bit Windows. Using the other functions is similar.
So the biggest goal should be to get code that will work on multiple platforms when you can.
But to be honest, the large codebases that I had to port weren't that bad.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Monday, March 11, 2019 2:52 AM
Hi Hector,
Welcome to the MSDN forum.
We are so glad to hear that Darran's reply solved your issues, thank you for your confirmation.
If you have any other issues in the future, please feel free to let us know.
Have a nice day!
Best regards,
Sara
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Monday, March 11, 2019 1:59 PM
2) Interesting. I never looked at this 64bit startup options. What I did was take the x86, modified the short cut to call "wcSetVars.cmd x86" which prepares the wcSDK LIB and INCLUDE first then calls "vcvarsall.bat x86" I can easily set that to x64_x86.
3,4) I see your point about the change in VS2017, but based on what you showed, I am not sure if that is going to minimize support questions. I always try to minimize support issues and I'm a firm of "being specific is terrific." We'll see when I get my hands on VS2017 or go direct to VS2019. I was trying (with VS2015) to create a new project template and followed an online guide. I see that it did with zipping up all the source files in a project that is exported as a template. I was more interesting in exporting the "configuration settings." That can be done by create a new (empty) C/C++ project, prepare your settings, then export, but it is good to know it will allow you to add prepared files to a new project.
- Thanks for your tips on 64 bit. So far, the plan is being outlined as such:
It appears the RPC Server side can be 100% 64 bit. The standalone pcode compiler can be 64 bit. All tools that do not utilize the pcode compiled images can be 64 bit. For the RPC client side, since the pcode RTE must remain 32 bit for maximum backward compatibility, the RPC client hosting servers that use the pcode images must be 32 bit. We have a one main client side component (Online Connection Controller) where upon startup, it preloads some legacy 32bit DLLs related to ODBC and MSJET, remember that?!? <g> So for the client side, its going to be a major 32 bit compatibility testing phase.
Thanks for all your assistance and tips
Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com