Previous: 25 Departing from the norm
Next: 27 How I came to write this book
In this section:
There are many aspects of FTN95 that way exceed my needs, and the title of this chapter is a curtailed form of the full quotation, which implies that there are places where Angels fear to tread. I’m no Angel, and it isn’t always fear that has kept me from many of the aspects of FTN95 and ClearWin+ - usually it has been a question of need (or not). My ambition in this book is to give you information that you can’t glean from FTN95’s online help, but which you have to learn by other means. It isn’t intended to include or to replace those help files, but sometimes has to duplicate them in part.
The list of things I haven’t covered is extensive, and in particular in respect of Fortran source codes and compilation, I have skipped over:
I have said nothing or almost nothing about the third-party graphics libraries and applications SIMFIT and SIMDEM, and glossed over SimplePlot.
There are also quite a number of format codes that haven’t made it into this book. The whole point is that at some time or other, curiosity will get you looking at what’s on offer, and you will explore the help files without my bidding. For example, I’ve said nothing about TreeView and BranchView (%tv and %bv), but some of their philosophy of use is similar to ListView (%lv) and if you want them, you’ll have to teach yourself.
You can get two programs compiled with ClearWin+ to ‘talk’ to each other. They do this through Windows messaging. Assume that you have a master program and a servant program. The master program may well have a button in a toolbar that you want to send a message. Maybe it starts the servant program. Here is the callback function for that toolbar button, which launches the servant program Servant.EXE, in the example below without a datafile. Now, we don’t want multiple Servant(s) all answering the same button press, and one way of doing that might be to grey out the toolbar button that called it up. Another way to do it is to ask is Servant.EXE is already running. Now the Servant program ‘knows’ that it has a ‘class name’ of BUTLER, so we broadcast a message to BUTLER asking, in effect, ‘are you already running?’ This is done in the code fragment with the message ‘RUNNING’, sent using the function SEND_TEXT_MESSAGE@, which also has a return possibility REPLY.
INTEGER FUNCTION Launch()
C -------------------------
C Launch Whatever.exe C
INTEGER START_PPROCESS@, SEND_TEXT_MESSAGE@
CHARACTER*(25) REPLY
INCLUDE <WINDOWS.INS>
IA = SEND_TEXT_MESSAGE@ ('BUTLER', 'RUNNING', REPLY)
IF (REPLY .NE. 'YES') THEN
IA = START_PPROCESS@ ('Servant.EXE',' ')
C … IF IA isn't 0, then the secondary program didn't start
ENDIF
Launch = 2
END
Now, in the Servant.EXE program we have to tell it what classname to use with %nc, and what the return message callback should be:
C ... setting the class, and a callback function to respond to C messages
IA=WINIO@('%nc[BUTLER]%rm&',MESSAGE_FN)
Now, if the Servant receives a message ‘RUNNING’, the callback replies ‘YES’, which tells the Master program not to START_PPROCESS@ to launch another copy. I have added the response to a ‘CLOSE’ command, which will close down the Servant.EXE program.
INTEGER FUNCTION MESSAGE_FN()
C -----------------------------
C This is the message handler
C -----------------------------
CHARACTER*(255) MESSAGE
INCLUDE <WINDOWS.INS>
MESSAGE = CLEARWIN_STRING@('MESSAGE_TEXT')
IF (MESSAGE .EQ. 'CLOSE') THEN
MESSAGE_FN = 0
RETURN
ELSE IF (MESSAGE .EQ. 'RUNNING') THEN
CALL REPLY_TO_TEXT_MESSAGE@('YES')
ENDIF
MESSAGE_FN = 1
RETURN
END
Now, in these code fragments you can see not only the sending of messages, but what to do if they are received, and how to return messages. Indeed, if you know the Class Name of a program you didn’t write yourself, you can send it messages – although what reply you might receive, and whether the message you sent would be understood, let alone acted on, is beyond me.
In my example, I have a sort of pop-up calculator application that tells the user the result of a specific calculation, independent of the calling program. You could launch multiple instances of a program to do a task for you. However, you need to launch fewer minions than there are CPU cores, as Windows might just queue them up to use its favourite core!
Minion apps can communicate using Windows messaging, but they can also communicate by leaving files, say on a particular disk, or even on say a network attached storage or fileserver if running on different machines. The possibilities, I suspect, are endless.
You can share memory, and for that matter, files between two of more Fortran programs. The instructions for doing so can be found in the online help file under ‘Extended ALLOCATE statement’
Early speed improvements with PC processors were obtained by increasing the clock speed, or basically making the CPU run faster. Another speed improvement was by adding an x87numeric co-processor, which speeded up some arithmetic operations and function evaluations. X87 numeric co-processor functions became a standard functionality about the time of the introduction of 80486DX CPUs, and x87 code is used by the 32-bit version of FTN95. At about the same time, CPUs were speeded up by not only increasing the external clock speed, but multiplying that clock speed internally. Then, gradually, CPUs had additional cores internally. It took some time for Windows to learn to spread its workload over multicore CPUs, but it does so now. A further step was adding instructions so that multiple arithmetic operations can be done at the same time, basically by stealing the stack of registers in the x87 part of the CPU. 64-bit FTN95 does that, not explicitly using x87 as it was originally intended.
The question is, can we write Fortran programs that spread their workload over multiple CPU cores? The answer has many dimensions, including the fact that some cores are faster than others, some use more power or generate more heat, and in short, it isn’t always obvious what gains there are in practice, when you’d probably have to fight Windows’ allocation of jobs to its minions. I have little doubt, however, that ways will be found, and that FTN95 will allow some of them to be employed.
You should read the interesting, but complex, Notes_on_parallel_processing.txt file that FTN95 slips unobtrusively into its documentation folder! (and everything else there that catches your eye).
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.