Bitness of command processor for ifort command prompts

[IanH]

On a 64 bit Windows 7 machine, I've noticed that the various command prompt shortcuts installed with ifort all invoke their startup batch file using "C:\Windows\SysWOW64\cmd.exe".  This means that the resulting instance of cmd.exe is the 32 bit variant, which is then subject to the various filesystem and registry redirections that come into play when hosting 32 bit apps on a 64 bit system.

Is there a particular reason for this?

The difference between the two cmd.exe's is perhaps inconsequential (and this is only relevant to the command processor, not executables invoked from that processor), but there is the odd windows system utility that becomes unavailable as a consequence.

[Steven_L_Intel1]

I became aware of this a short time ago but don't know why this is. I will ask. Issue ID is DPD200371995.

[Steven_L_Intel1]

The problem is this - the installer is a 32-bit program, and on a 64-bit system, when it asks the Windows Installer API for the path to the Windows System folder, it comes back with the WOW64 path. What I've been told is that they've found a way to get the System32 path for the shortcuts that target Intel 64, but the IA-32 build shortcuts will still use the WOW64 path. I hope this helps.

You can, of course, always make your own copy of the shortcut and change the path to cmd.exe to be whatever you want. For myself, I make my own copy and change other properties, such as Start In and the window size, and put these on my desktop.

[IanH]

I'm not sure that the bitness of the command processor has to be tied to the bitness of the target of compilation.  From one perspective it is just a difference in the capability of a tool used in the build environment (sort of similar - on a 64 bit machine you don't have to use the 32 bit executable variant of ifort.exe to build a 32 bit target - there is a 64 bit ifort executable that can build 32 bit apps).  Not that I can ever recall having ever done anything in a command processor that could conceivably require it to have a 64 address space (though the path length in the 2016 beta command prompts are tending in that direction...).

From another perspective - if the bitness of command processor and target matches then any batch files run on that command processor see the same environment that the target would see if the target was run on the same machine that it was built on, which might be handy for configure-build-install type batch scripts, if such beasts exist.

I don't know what's best, I just got confused when `dir` blatantly lied to me recently about the content of a system directory..

[Steven_L_Intel1]

I agree - but the install devs told me that this is how they had to do it. I didn't fully understand it myself.

[Steven_L_Intel1]

I am told that this has been changed for 2016 Update 1 to not force the 32-bit command processor.