I'm using the latest FTN95 version. Is there anyone who can help...I've written a huge number cruncher in Fortran and compiled it for both 32 and 64-bit processors but I need to test the user's processors within the Fortran code before calling the appropriate routine. Likely there is a system call or whatever that I could use to test for this but I can't see it in the docs for FTN95 (probably missed it!!). Help appreciated thanks.
Code to test for 32 or 64-bit compiler in Fortran
Clarify what you mean by 'test the user's processor'. The user's processor these days will probably be a 64-bit processor, but such a processor may be running 32-bit Windows or 64-bit Windows. Under 64-bit Windows, an EXE being run can be a 32-bit EXE or a 64-bit EXE.
The CPUID instruction can be used to get details about the processor. The PROCESSOR_ARCHITECTURE environment variable could be queried. You could check for the existence of the Program Files (x86) folder.
Hi mecej4, Thanks for your reply. I think, as usual, I didn't explain properly...I need to test for a 32 or 64-bit computer before generating millions of numbers. If 64-bit then I can generate more numbers but the reverse for 32-bit. Possibly a check, as you mentioned, for 'Program Files (x86)' folder may well do it but just wondered if there was a System command that is easily accessible. Thanks.
I don't think that you have explained what you mean by 'test for a 64-bit computer'. The user's computer can have a 32-bit or 64-bit CPU. If the latter, the computer could be running a 32-bit version of Windows or a 64-bit version. On Windows 64, your FTN95-compiled EXE could be 32-bit or 64-bit.
You could deliver two versions of your program, say, NQN32.EXE and NQN64.EXE. Within each version, you could call GET_COMMAND_ARGUMENT(0,pgm_name), and test for the presence of the substring '32' in pgm_name.
I understand this but I'm wondering if a user had a 64-bit CPU, why would they install a 32-bit version of Windows? You are highly likely correct but I don't get this. Scenario... I'm using an Intel i7 64-bit CPU with 64-bit Windows and have generated 32 and 64-bit versions of my program with FTN95 (called Superposition32.exe and Superposition64.exe) which I call from a VBA routine in Excel 32-bit Office. I can call either .exe file successfully. If a user has installed 32-bit Windows with a 64-bit CPU will both files still run? Also, if a user has a 32-bit CPU then I assume the 64-bit version wouldn't run anyway (my logic)? Perhaps I'm 'muddying the waters' here... Thanks.
'If a user has installed 32-bit Windows with a 64-bit CPU will both files still run?'
No.
For a 64-bit EXE to run natively, here are two necessary conditions:
1. A 64-bit CPU whose instruction set encompasses all the instructions in the code of the EXE.
2. A 64-bit operating system that supports the structure of the EXE and all the instructions that the EXE uses.
'if a user had a 64-bit CPU, why would they install a 32-bit version of Windows?'
1. Early 64-bit PCs came with Windows XP (32-bit). Early versions of Windows-64 had many limitations. If a user has everything working fine in 32-bit Windows, that user can choose to just keep using Windows-32-bit.
2. To run 16-bit programs (including MSDOS EXEs).
You may want to look at the thread : General > '64-Bit FTN95 Compiler', 7-Mar-2019:
https://forums.silverfrost.com/Forum/Topic/1305&postdays=0&postorder=asc&start=30
This uses GlobalMemoryStatusEx or GlobalMemoryStatus@ to determine the amount of available memory(64-bit) or addressable memory (32-bit). There is an example.
A significant problem with 64-bit calcs is trying to use more memory than is installed, (or not more than 80% of installed)
Not sure I understand why 32-bit is needed ? XP was last 32-bit OS and I am not sure of what 32-bit processors are now in use.
Thanks everyone...now I understand a bit more (excuse pun!) about my original confusion. Tried it and it works on my computer nicely.
In my VBA code I can simply check the CPU as 32 or 64-bit and the same for Windows Office so I can now call the correct version of my Fortran .exe files before calling the wrong one and find my program going off 'into space!!'. VBA code below for anyone interested in calling a Fortran .exe file from within Excel. Works for Office 2016 and 2019...don't know about other versions.
Dim WshShell As Object Dim waitOnReturn As Boolean Dim mydir As String
Rem Call Fortran routine 'superposition.exe' for 32-bit processors Rem or 'superposition64.exe' for 64-bit processors for number crunching If Not Environ('ProgramFiles(x86)') = '' Then MsgBox '64-bit Windows' waitOnReturn = True Application.ScreenUpdating = False Set WshShell = CreateObject('WScript.Shell') WshShell.Run Chr(34) & mydir & '\superposition64.exe' & Chr(34), 0, _ waitOnReturn Application.ScreenUpdating = True Else MsgBox '32-bit Windows' waitOnReturn = True Application.ScreenUpdating = False Set WshShell = CreateObject('WScript.Shell') WshShell.Run Chr(34) & mydir & '\superposition.exe' & Chr(34), 0, _ waitOnReturn Application.ScreenUpdating = True End If
Rem Now check for Office version (32 or 64-bit) If InStr(Application.OperatingSystem, '32-bit') Then MsgBox '32-bit Office' End If If InStr(Application.OperatingSystem, '64-bit') Then MsgBox '64-bit Office' End If
Why should anyone install a 32-bit OS on a 64-bit-capable cpu?
Reason 1: to run software that won't run under a 64-bit OS. I have a help-compiler of that sort. I've never tried in with 32-bit Windows 10, and keep a computer running Windows 7 for it. The hardware in that computer would easily run a 64-bit version of Windows, but its value is in running the help-compiler. It's also 13 years old, and 64-bit capable cpus were the norm even when 64-bit Windows was a novelty.
Reason 2: It's a laptop or all-in-one with soldered RAM, say of 1 or 2Gb which won't run a 64-bit OS reliably. Yep, I've got one of those too. Not that I use it now, but I did revert to a 32-bit version of Windows 10 which gave me about 6 months of extra life.
Note that even with 64-bit capable CPUs, depending on which model it is it may not support all opcodes.
Eddie