Need for Windows 32-bit binaries and STDCALL /iface:cvf

[Ron_Green]

The Intel Fortran team is asking for your feedback on the Intel(R) Fortran Compiler for Windows*.

This discussion is focused strictly on Windows.  Linux* 32-bit support is a different and niche side topic for another thread.

For Intel's compilers for Windows

As of today, our plan is for our new Intel(R) Fortran Compiler (ifx) for Windows to support creating 64-bit (x64) binaries only.  Currently, there is no plan for ifx to support creating 32-bit binaries, or support of /iface:cvf, or support for STDCALL.     

So the questions are:

Will the lack of ability to create Windows 32-bit (ia32) binaries prevent you from moving to IFX?

Do you anticipate an absolute need for creating 32-bit Windows applications and libraries?  If so, why?

For how long? Through 2024, 2025 or even beyond 2025?

Do you have a timeline for moving away from building and distributing your applications and libraries for 32-bit (ia32) Windows? 

Tell us about your needs for Windows 32-bit (ia32) binary creation.

[andrew_4619]

We finally stopped building any 32bit applications about two years ago and not one company in our userbase as complained about it. I realise that the call interface, decoration etc is quite different  but our code has zillions of windows SDK and call-back routines that are bind(c) with !DIR$ ATTRIBUTES STDCALL ::  when you say "no support for STDCALL" in IFX that code already works in IFX in X64?

 I personally have no problems with no x32 in IFX it will make that confounded configuration manager a step less confusing.....

[mecej4]

In Windows X64 programs, "stdcall" is mostly syntactic sugar. According to this MS page,

On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.

Thus, your programs should do fine as long as the IFX compiler accepts source code with __stdcall (but ignores the attribute). The downside is, as we have just seen, that people who see the __stdcall in X64 program sources may think that its presence does something significant.

[andrew_4619]

Yes it does work fine in IFX /x64 I suppose the question is would it still work fine without it as it effects the defaults for value/reference ..... I never tried that.

[Steve_Lionel]

ATTRIBUTES STDCALL also downcases external procedure names unless you also used BIND(C). I would hope that ATTRIBUTES STDCALL remained available exactly as it is for x64. As for ATTRIBUTES CVF and /iface:CVF, my opinion is that ifx should not support those.

I'd assume that some older version of ifort would remain available for a few years afterward.

[JohnNichols]

This will break things, and we will fix them.  I am having a problem with a recent DISLIN update and ONEAPI, which is due to the lack of documentation for DISLIN, but the developer corrected my mistake.  

part of being a programmer, but really nothing has been any good since MS Fortran 3.31 and dual 5.25 inch drives, but we live with the future shocks. I could make a nice cup of tea in the compilation time, now I can have a swig of Italian water, shipped across the atlantic. 

[JohnNichols]

Not to mention, the computer that cannot be mentioned on this site, but it was heavy, but I was young. 

[Neels]

I supply software that is used by engine builders and tuners, and they do not change or update their computers very often. The last one to still use WinXP eventually updated about 3 months ago. The problem is that their computers are connected to their test equipment and they often cannot upgrade without breaking the compatibility with "old" instruments. Going by history, I will have to supply 32bit versions for at least the next 10 years. My customer base is not that big though, around 600 users.

[Mark_Lewy]

Will the lack of ability to create Windows 32-bit (ia32) binaries prevent you from moving to IFX?

Yes, we still build a 32-bit version of our client applications; I believe this is because they depend on some 3rd party GIS components that don't exist as 64-bit.

Do you anticipate an absolute need for creating 32-bit Windows applications and libraries?  If so, why?

Yes, until we no longer need to support 32-bit clients.

For how long? Through 2024, 2025 or even beyond 2025?

I don't know offhand, I posted these questions to our development team, but haven't had a reply as yet (will update if and when I do).  I would hope that we can go 64-bit only sooner rather than later.

Do you have a timeline for moving away from building and distributing your applications and libraries for 32-bit (ia32) Windows? 

See above.

Tell us about your needs for Windows 32-bit (ia32) binary creation.

We are building 32-bit console applications, DLLs and static libraries; some of these use stdcall to call procedures in external libraries.