Choice of compile method (CVF/Intel)

Choice of compile method (CVF/Intel)

Post by Terenc » Sun, 10 Sep 2006 08:18:17

I want to write a text editor using Fortran.
Fortran works very well indeed for text processing (surprising to

The text may be considered as blocks of single-byte character symbols
in any modern human language, and also for the moment, left-to right
sequences of these. I'll eventually get to Arabic and Hebrew later, but
Romanji is already included.

Text lines must allow up to 136 international (or special) ascii
characters (note potential screen line-length problems).

The most important point to understand why I seem to be inventing the
wheel, is that each block is pre-defined and coded as a special type of
block (intention of use) and so as changes are made in these codes by
the user, the blocks of texts are constantly re=processed in their
presentations (visible or currently off-screen).
The texts and codes are stored either together or separately on a line
number basis.

I have done this sucessfully in Fortran since the early 1980's for
CP/M and MSDOS and for Windows command-line executions, but now want
to consider allowing Windows cut-and-paste assembly of pre-worked
sections from other sources.

The question is, which of the various target situations and compile
methods would be most suitable for current and forthcoming operating
systems? Note the line size on screen must allow for 136 characters,
even if the viewpoint has to shift as typing occurs. Is command-line
really a Windows native execution, even if limited in scope?

Choice of compile method (CVF/Intel)

Post by Bob Walto » Sun, 10 Sep 2006 10:34:04


If your choice is between CVF and Intel Fortran (as your title
indicates), you should take note of the following quotation from the
Compaq/HP web site:

"We wish to announce that Hewlett-Packard no longer sells or supports
Compaq Visual Fortran. However, A partnership has been established with
Intelto help you migrate to Intel Visual Fortran Compilers..."

Bob Walton


Choice of compile method (CVF/Intel)

Post by jon » Sun, 10 Sep 2006 14:04:37

Writing apps for Windows (or XWindows) needn't involve such such
low-level tasks as writing an editor. There are methods available that
do virtually everything you need with editing. For example, simply
purchasing Winteracter and using one subroutine call lets you open an
editing window with most all the features you know and love, including
RTF, access to the Windows printer dialogs, file i/o dialogs, cut,
paste, DDE, whatever. One week of my time is worth a lot more than the
cost of Winteracter, which also comes with full graph and graphics
support, grid and dialog management, ODBC data connectivity, 3D
modelling, graphics editor, help system constructor aid, Windows
resource editor, Full Fortran-friendly text editor, Integrated
Development Environment, installation builder, full OpenGL
connectivity, and so on... .

There are other libraries and components available to do the same
things, I just know that the Winteracter edit windows work fine for me.
To burden my users with a cobbled-together, primitive text editor would
be insulting to them. They aren't used to such a thing :-).

OTOH, I have done such things in the past (under DOS). I don't use
those apps any more.

Choice of compile method (CVF/Intel)

Post by jon » Sun, 10 Sep 2006 14:07:17

Also, Winteracter just happens to be available for several Fortran
compilers and virtually the same Winteracter is available under
Windows, Linux, and Mac OS X.

(No, I don't work for Winteracter, they just do a lot for me).

Choice of compile method (CVF/Intel)

Post by Terenc » Sun, 10 Sep 2006 18:17:35

I know about CVF/DVF/Intel Fortran Compilers. We have the last of each.
I know about Winteracter and have conversed with that company and two
The result was that we wrote our own user interface; partly because we
didn't need graphics, partly because our clients execute our compilers
on their machines, (which would be very cosltly in cross-licenses) and
also because we/client need to change the treatment of the current text
whenever the corresponding associated code to that text is changed.
This involves moving text around unmovable character positions (like
milestones) and no other existing screen treatment interfacesoftware
can do that.

Imagen a grid on the screen with symbols on some of the intersections.
The grid spacing never changes but the number and positions of the
symbols on any given line does change. Any nearby text has to leave
these positions alone, however the text changes. This is an important
part of preparing and later automatic image processing of previously
printed documents which have been anotated.

I am looking for suggestions on choosing between command-line,
one-window, and multiple window compilations. Currently our compiler
generates any needed multiple windows by our own interface in a command
line compiled module. But as a result we don't have cut-and-paste
facilities between our screen and other sources, and we only have one
font (actually an advantage) size in 256 colours.

Choice of compile method (CVF/Intel)

Post by Lynn » Mon, 11 Sep 2006 23:51:22

>I know about CVF/DVF/Intel Fortran Compilers. We have the last of each.

You might want to look into adding a fortran interface to WxWidgets:


Choice of compile method (CVF/Intel)

Post by Craig Powe » Thu, 14 Sep 2006 00:43:25

In its own way, a command line program is actually less limited than a
"traditional" Windows program, since it starts out with a console and
thus a target for stdin and stdout. A "traditional" program would have
to create and attach a console window. As far as I know, in all other
respects the two are equivalent in capability. (The canonical form of
the main program is slightly different.)