How to get started building 64-bit applications

[DavidWhite]

I have VS 2010 Pro installed, along with the latest version of Visual Fortran Studio.

I cannot find any installation settings or anything in VS that enables me to build 64-bit applications.

According to the Release Notes, for VS 2010, I don't need to do anything extra to set this up, but obviously I have missed something.

What do I need to do?

Thanks,

David

[IanH]

With an open project, if you select Build > Configuration Manager, then click on the Active solution platform drop down, do you see a "<New...>" item?  If so, select it and report what happens.

[DavidWhite]

Curiouser and curiouser, I'm beginning to feel like Lewis Carroll, I must be on something. ;-/

x64 is there now, but wasn't there earlier.  I tried to do a change installation for VS, but it said that everything was already there, so I don't believe I have actually changed anything.

Thanks,

David

[DavidWhite]

Next question: I have a solution with 3 projects.  When I change the configuration to x64 it says that there is nothing to build with that configuration. How do I set up the individual projects? In configuration manager with x64 solution platform, it lists these 3 win32 projects. When I try to create a new x64 project platform and copy the settings from the win32 project, I get the message that "This platform cannot be created because a solution platform of the same name already exists"

Thx

David

[IanH]

When you create the platform for each project, is the checkbox for "Create new solution platforms" deselected?
 

[DavidWhite]

Ian,

I think I'm making progress.  What I think was happening was that I was trying to create project/solution files with the same name and location as the existing ones.

I have now started creating new projects for the x64 versions, and attempting to add the same source files to each.

I assume that mod files are specific to win32/x64, so I need to recreate all of these in a separate location for x64.

As I am also using XEffort, I think I am going to need to rebuild these libraries as 64-bit too.

I notice under Batch Build for the x64 projects that there are options for both Win32 and x64.  Is this how I can maintain both 32-bit and 64-bit versions of my apps? Does this mean that eventually, I will be able to eliminate the current 32-bit projects and solutions, and only keep the new 64-bit ones?

Thanks,

David

[IanH]

Something sounds astray.  The model is that a specific project can have a set of configurations for each platform.  You don't have to create new projects for the platform - you just create a new set of configurations for the existing projects.  That Configuration manager thing is the interface for doing that.

(You don't have to stick to that model, but I would unless some good reason to the contrary emerges.)

The set of configurations is typically a Debug configuration and a Release configuration - so you end up with four sets of properties (two configurations by two platforms) in total - Debug|Win32, Release|Win32, Debug|x64 and Release|x64.

There's a conceptual difference between the solution platform and the individual project platforms - the project platforms will only ever be x64 or Win32 for current ifort (perhaps also ia64 for itanium for older versions, but that's beyond me) because that's all that the compiler supports.  For a particular solution platform (there can be many) you then can specify the project platform to be built for each project.  Typically (and sanely - but there are unfortunate exceptions if you are using Visual Studio compilers other than ifort) they are named the same - if you select x64 as the solution platform then each project will be directed (using that configuration manager) to build the x64 project platform.  This is the same sort of arrangement as for solution and project configurations.

The default setup for x64 in ifort terms of directories is a little different to Win32 - they use the platform name in the first level of the intermediate and target directory hierarchy - so what used to go in ProjectName\Debug now goes in ProjectName\x64\Debug.  This means that, by default, you don't get collisions between the various mod, obj, exe, etc files, regardless of the platform your are targeting.

You will need to build any third party libraries that you use for x64, and perhaps customize the references to those libraries in the properties for each configuration.  With some planning, you can locate libraries in folders that can then be referenced in the properties for the project using the $(PlatformName) macro and save on the amount of customization that you need to do.  Looking at my projects I'm apparently not very good at planning.

[DavidWhite]

Ian,

Thanks.

I appear to be able to do this for new projects, but appear to have had problems with existing ones. Perhaps, as in your earlier post, I had the create new solution platforms checked, so it was attempting to create a new file when one already existed. I assume that if I clear the checkbox, then it will add the x64 details to the existing project files.

Like you, my file structures are not the best. I have been using common modules, intermediates and libraries folders, which could go pearshaped- with multiple platforms.

Thanks,

David

[andrew_4619]

If it is any consolation David, your experience seems to pretty much mirror my own pain when I tackled this activity a few months back. I would consider myself normally pretty good at quickly sorting out such things, but has you have found there are a number of aspects that are not that intuitive and our experiences strongly suggest that some 'idiots guide' in the help system would be useful to others.

As an aside, I have forgotten now most of what I was learned as I was only wanting to understand/solve  the problems of moving a complex application to x64, I have no particular benefit in doing so at this time and the dis-benefit that I would need to maintain both x32 and x64 versions if I did so.

[Anthony_Richards]

For what it's worth, I have installed the 32-bit and 64-bit versions of the Intel Composer  on a 32-bit Windows XP Pro platform with MS Visual Studio 2005 and I needed to produce a 64-bit version of an application to run on a colleagues 64-bit platform that dd not have VS2005 installed. I thought it would be difficult, but it was amazingly straightforward.

I just selected Configuration manager (see VS2005 window) and changed the Active solution platform to x64 and the configuration platform to x64 from the drop-down lists (see configselectbox and platformselect.jpg) and selected Build and hoped for the best. I was amazed that it worked first time! An x64 folder is automatically created for the debug or release version created (see foldercreated.jpg).

I then had to copy the 64-bit release version executable over to my colleagues computer along with the Microsoft Visual C++ redistributable libraries that are required to run the executable on a machine that does not have Visual Studio 2005 installed (look for help on the downloadable installation package that matches the version of Visual Studio you are using if you have to do the same). i think I downloaded VCREDIST_X64.EXE and w_fcompxe_redist_msi_2011.10.325.zip.

[andrew_4619]

@Anthony: Yup just change the platform to x64 and it makes (for example) a release build and it will create an x64 sub folder below the project and a release folder within that. But is then doesn't build correctly as all the custom build settings in the x32  release configuration aren't carried forward. So you update all the settings in the x64 release configuration (of which there are lots), change any third party library refs to the x64 variants and away you go.

In effect you have created a new configuration specifically for x64, however if you pick that config you which is specifically for x64 you still have to pick the x64 platform from the drop down on the tool bar. Unless I am doing it all wrong (which I might be) it just does not seem very logical or friendly. If there is a better way, it would be good to have an idiots guide.

In ref to the OP, another small pitfall was if you have sizeof(thing) as an argument of function calls as this flips from 4 to 8 bytes which may or may not then work. Check interfaces normal picks this one up or sometime it is a link error as the number of bytes on the call do not add up so the call is unresolved. you see lots of examples of api calls using sizeof that do not work flipping from x32 to x64 within adding some kind conversion.

[jimdempseyatthecove]

Another issue to watch out for, In 32-bit Windows HANDLE == INTEGER, in 64-bit Windows HANDLE==INTEGER(8) (sizeof VOID*). If your old code did not use INTEGER(HANDLE) then you may be in for some problems.

There was a similar issue (can't recall precisely) when using Dialog Boxes where you could get away with using INTEGER in 32-bit but not in 64-bit.

Jim Dempsey

[bealeja]

I find it helpful to copy the setting from an existing project when creating the x64 "platform".  Also, I find it incredibly helpful for personal sanity to use the macros $(Platform) and $(Configuration) to automatically specify x64, Win32, Debug and Release without having to customize the many Property pages needed to maintain 32bit and 64bit versions.

I hope this helps.

Cheers,

Jim

[Jarvus_L_]

I have a question on the Batch Build editor (I realize this may be a VS question not an Intel question, but this looked like a good thread).

I have switched from 32 bit to 64 bit.  Under Build > Configuration Manager, I deleted my 32-bit configurations.  However, the Batch Build editor still shows a Win32 "platform".  I have seven different projects with both a Debug and Release configuration and both a x64 platform and Win32 platform.  There is not a 32 bit solution (that I am aware of) but the Win32 platform adds 14 lines of clutter (to an extremely small window that cannot be enlarged).  Yes, you change the sort order, but the editor closes when you build and everytime the editor opens up it defaults back.  I do all my builds from this editor and I am constantly changing what I have checked.

Am I missing something or any suggestions?

Thanks.

[Steven_L_Intel1]

I am not familiar with the Batch Build editor (and am not sure that even works for Fortran), but I do know it is a rather arcane process to remove configurations from a solution. Rather than delete the configuration, you need to delete the platform using Active solution platform > Edit...