Volume 16, Issue 1

Welcome to the Lahey Fortran Source Newsletter.
The new millennium has finally arrived. Some things have changed; most have stayed the same. The same is true for us here at Lahey. We are implementing several changes intended to improve the quality of the products and services we provide to the Fortran community. One of these changes is the Fortran Source newsletter itself. This is the first edition to be published and distributed electronically. We have tried to provide the information in this newsletter in as non-intrusive a manner as possible. However, if you donít want to receive future issues of the newsletter, unsubscribe instructions can be found at the end of this letter.

Message from Tom Lahey - Founder of Lahey Computer Systems, Inc.
Fortran and the Space Program - Article from Jack Crenshaw
Lahey and Canaima Partnership - Announcement
Winteracter Enhancements - New features in v2.2
GINO for Linux - GUI builder for Linux
Using LF95 Linux Express for Linux Clusters - Article
Tech Support Policy - How to optimize response time
Tech Support Tips - Questions and Answers
CoEx Program Retired - Announcement
Fortran 95/GINO Workshop - Where, when, and how much

Message from Tom Lahey
(Back to Contents)

Dear Fortran Programmer,

Change. April 21, 1967, Phoenix, AZ. Lahey Computer Systems, Inc., is incorporated. 33 years later and still running. Lahey shipped its first PC FORTRAN 77 during September 1984. Looking back, the only thing that's certain is change, and as you read this edition of Fortran Source, I hope you see that we continue to change to meet your needs and changing market conditions.

To improve how we stay in touch with your needs, Lahey has created a special e-mail address, If you have any reaction to this newsletter, or any idea that you would like us to consider, please send them to this address - we'd appreciate hearing from you.

Speaking of change, here are three I see in the Fortran programmer's future:

  1. Fortran 2000
  2. Windows 2000 versus Linux
  3. IA-64

All of these changes are exciting. Will Linux replace Windows as the OS of choice for Fortran programmers? For the most part, the Fortran 2000 language is defined. The language will move further in the direction of object oriented programming. What impact will the changes have on our programming? Will Intel's 64-bit chip impact Sun and SGI? It's no secret that Intel has been working towards entering the workstation market for some time. My prediction:

The Fortran programmer's bang for the buck will continue to improve dramatically!

Preparing for the IA-64. As you are probably aware, Fortran 90 formally introduced the idea of default types. There are five intrinsic default types:


Note: No DOUBLE PRECISION which is still a standard type, but not a default type.

Fortran 90 also formalized extended-precision COMPLEX. How would the standard have us declare extended-precision COMPLEX variables and functions so that the code will run single precision on a Cray (64-bit chip) and extended precision on a PC (32-bit chip)? One way is:

     COMPLEX( SELECTED_REAL_KIND( P=40, R=50 ) ) :: Z1, Z2, ...

For REAL variables, the syntax is:

     REAL( SELECTED_REAL_KIND( P=40, R=50 ) ) :: x, y, z, ...

Two reasons for using this approach:
  1. Some thought is given to the numerical analysis of a problem; and
  2. when the Intel IA-64 chip makes it to our desk, code will not have to be modified to avoid doing 128-bit REALs when all that is needed is 64-bits.

Workshop XVII. Lahey has planned Fortran 95 Workshop XVII for May 15:17. Tim Zeisloft and I will lead the sessions here at Lake Tahoe - bring a camera and a FORTRAN program you want to begin to modernize. Following Lahey's six-session/three-day workshop, Bradly Associates will offer an introduction to their GINO family of graphics products on Thursday and Friday. You can sign up for either or both, there's room for twelve.

Based on feedback from Workshop XVI, the syllabus has been improved slightly (as it is for most workshops). For the first time we will be using Truckee Meadows Community College facilities so you won't have to bring a computer.

Fujitsu Visit. Bill Lassaline and I visited Japan during the week of March 6 to work on Lahey's relationship with Fujitsu. I'm happy to tell you that Fujitsu has committed to advancing the Windows and Linux Fortran 95 products. Lahey makes definitive product-announcements when we have the release ready to go - stay tuned.

Porting Service. In closing, I'd like to mention the Lahey Porting Service. If you have programs you would like ported to Fortran 95, I would like to work on them. No code is too small; no code is too ugly; no code that is important to your organization is too anything. To get started, we work in $1,000 advances. You can cancel at anytime and only pay for what has been accomplished. Sometimes, the user has taken over after I showed what could and/or needed to be done. Finally, Lahey has no claim on the work I do. Give Lahey a call.



Fortran and the Space Program
(Back to Contents)

These days, fewer and fewer engineers remember, firsthand, the glory days of the space program, culminating in the historic Apollo moon landing. Fewer still recall just how intimate was the connection between three converging new technologies: Space science, computer science, and Fortran. In the earliest days of the space program, computers were nonexistent, and Fortran was barely so. When I joined NASA in 1959, to say that computing facilities were primitive would be an understatement. Like every new NASA engineer, I was given a standard, government issue, 18" slide rule. The standard "computer" was a 50-pound, mechanical marvel, the Friden calculator. Spreadsheets were something you did by hand, using the Friden; trig functions were something you got from a book of tables; and graphs required drafting instruments, french curves, and a sharp pencil. You could tell a lot about an engineer by the quality of the graphs he drew.

Laugh if you like, but it was mostly slide rules, spreadsheets and graphs, not computers, that launched Alan Shephard and John Glenn into space. NASAís Langley Research center had one (1) computer, a 32k IBM 702. My first dynamic simulation, for a solid-state rocket booster, was written in assembly language, mainly because thatís all we had. As for things like lunar and interplanetary simulations, there were maybe 10 in the entire country. When you consider the challenge of writing a precision simulation in assembly language using, say, 5th-order Adams-Moulton integration, you can appreciate why there werenít many of them.

By 1969, the year of the Moon landing, aerospace companies all over the country had IBM 7094ís, Univac 1108ís, and CDC 6600ís coming out their ears, all busily grinding out solutions of complex trajectory problems, and virtually all written in Fortran. Fueled by the Apollo effort, we had computing power to spare, and dynamic simulations were a dime a dozen. Each of us had an N-body simulation to help solve Apollo trajectories, and many were being used to plan the next step: Mars. Thousands of engineers, worldwide, pored over fan-fold printouts and X-Y plots.

As computers evolved, mathematical methods evolved with them. At the beginning of the space program, we used what existed, which were methods developed by astronomers to compute the orbits of comets. They were methods intended to be used by hand, and they often involved decisions concerning precision, signs of results, etc., that required human intelligence to make. They also tended to make heavy use of spherical trig. The methods did not translate well into computer programs. So we developed new methods that depended on vector math, and algebraic rather than trig-based solutions; things the computer was good at. The patched-conic method, the unified two-body theory, the f-g series solutions, Deystís method, Lambertís theorem methods, all were brand-new methods, better suited to computer solutions than manual ones. Practical application of the now-famous Kalman filter came straight out of the Apollo program inspired by the need for efficient midcourse guidance. I think itís no exaggeration to say that it was computer technology, not money or space science, that helped us land on the Moon.

And Fortran was right in the middle of it. What made Fortran so important? It was designed, from the get-go, to help programmers solve math problems. If there was something we had in abundance, it was math problems, and Fortran was the perfect tool to help us solve them quickly AND efficiently.

Two features of Fortran were of special significance. One was the subroutine with calling lists. Though the notions of modularity and reusable software were still thirty years away, we knew a good thing when we saw it. We were all building subroutine libraries, and using them to build bigger ones. My very first Fortran "program" was the ubiquitous vector add routine:

      DIMENSION A(1), B(1), C(1)
      DO 10, I=1, N
10      C(I) = A(I) + B(I)

I still use that same routine to this very day.

The second "feature" was not really a feature, but an accidental result of the primitive state of compiler technology. The original Fortran passed all parameters by reference, not value. To identify a passed parameter as an array, you had to mention it in a dimension statement. But we quickly learned that the size didn't matter; the compiler didnít do range checking. It only needed to know that the variable was an array. This meant that we could use tricky constructs like the dimension statement above to operate on vectors of any size. Doing the same with matrices was a little trickier, because we had to do our own 2-d to 1-d indexing conversion, but we did it.

By the time Fortran IV came along, this practice had become so popular that it couldnít have been removed from the language, even if they wanted to. So they formalized the syntax into something called "variable dimensions," AKA conformant arrays. Now it was possible to write general functions operating on two-dimensional arrays:

      DIMENSION A(L, M), B(M, N), C(L, N)
      DO 20 I = 1, L
        DO 20 J = 1, N
          SUM = 0.0
        DO 10 K = 1, M
10        SUM = SUM + A(I, K) * B(K, J)
20        C(I, J) = SUM

Today, some people consider Fortran passé. More modern languages like Pascal and C are the rage and object-based languages like C++ even more so. To this day, not one of them support conformant arrays. Why is this? Frankly, I consider this a national disgrace. Surely, if Fortran could support the concept in 1967, some compiler wizard could figure out how to do it in C++, in the year 2000. I can only conclude that the people who design modern languages don't really care much about (or even understand) the needs of those of us who still do numerical computing. That's why Fortran remains the premiere language for number crunching.

I first encountered Lahey Fortran in its 16-bit guise, back around 1986. I had been trying to sell my company on the idea of using PC's for more serious computations, but they tended to still think of them as toys. The company had a massive, highly computation-intensive covariance analysis program, that had been written in Fortran and ran on a DEC VAX-11/780. To back up my claim that the PC was for serious number-crunching, I was challenged to convert the analysis program to run on a true PC/AT (1 Mb RAM, all of 6MHz clock. The only concession I got was a hardware math chip). After some shopping around, I chose Lahey Fortran mainly for its ability to compile quickly and generate tight code.

The program took some tinkering to get it to compile under Lahey. The first time I compiled it, I got hundreds of error messages. After tracking them down, it turned out that every single one was a legitimate error. Lahey had flagged programming errors, mostly type mismatches like implicit and inadvertent double-to-real conversions, that the DEC compiler had blithely accepted. In several cases, it flagged variables that were set but never used, and, worse yet, variables that were used but never set.

Once the bugs had all been corrected, the program compiled without a hitch. Interestingly enough, not only was it small enough to run in the AT's 640k RAM space (the DEC version had been 1.5Mb), but it also ran 2-3 times FASTER than on the VAX.

In bringing this system up and working out the bugs, I had occasion to call Lahey several times. I always found them to be extremely responsive and helpful, and the compiler itself was absolutely bulletproof. In the world of PC software in 1986 (or 2000, for that matter), I found this a refreshing state of affairs.

About a year later, Tyler Sperry, editor of Computer Language, asked me Magazine, to review the current crop of 32-bit Fortran compilers. I think I reviewed seven compilers, all told, and gave each an ordinal rating. Some of the other compilers clearly were mere ports from the VAX world, and it showed. The worst of them crashed and burned on some of my benchmarks. Others were so difficult to use I simply set them aside.

Lahey came out the clear victor, not just because of its speed and reliability, but also because it was nicely integrated with a development environment. Not surprisingly, from my experience both before and since, the compiler itself was rock solid. I've come to expect nothing less from Lahey.

This review became something of a cult classic because I pulled no punches; I told things as they were. Needless to say, Tyler took a lot of flak from the vendors I'd rated low. One told him that their sales had been cut in half. But Tyler stuck to his editorial guns and refused to bend to pressures to retract any of my comments. Interestingly enough, other software vendors - the ones who had good products, and knew it - found the approach a refreshing breath of fresh air. More than one told Tyler they wanted the magazine to review their product also, but only if I agreed to do the review. I found that attitude a most uplifting one.

Before closing, I should mention one other outstanding feature of Fortran: It changes. Other languages, like Algol and PL/1, have come and gone. Fortran is much more dynamic than C or Pascal; it continues to evolve, and change to meet new concepts like objects. That is a great part of its power. But most of all, Fortran has never forgotten its roots: It still remains a language for crunching numbers. And Windows programming to the contrary, sometimes itís number crunching that we need.

Jack W. Crenshaw holds a Ph.D. in Physics from Auburn University. He has spent over 40 years in the aerospace program, beginning with seminal work on Project Apollo. He is currently a senior principal design engineer for ATK, Inc., a defense contractor. He does math-intensive software and system design. He is a contributing editor for Embedded Systems Programming Magazine, and his popular column, "Programmer's Toolbox," has enjoyed an 8-year run with no signs of letup. He is a sometimes president of Crenshaw Technologies, a software/systems consulting firm, and his book, "Software Toolbox for Embedded Systems," is due for release in August. In his "spare" time, Crenshaw raises ducks and chickens, and helps to rehabilitate wild orphan baby birds and animals of all kinds.

Lahey and Canaima Partnership
(Back to Contents)

Canaima Software and Lahey Computer Systems have entered into a partnership to market f90SQL-Pro. Nick Vogel of Canaima Software notes, "Since the emphasis of our company is software development and consulting, it made sense to enter into an agreement with a partner to handle marketing, sales and distribution. We anticipate that this change will increase the service and convenience to you, our customer."

f90SQL is a library of functions and subroutines that works as an interface between your Fortran programs and the Microsoft Windows Open Database Connectivity (ODBC) API. f90SQL offers a convenient and familiar way to manipulate many database formats directly from your Fortran program. Supported database and spreadsheet formats include: Excel, Lotus 1-2-3, Microsoft Access, FoxPro, Paradox, Oracle, Sybase, Ingres, Informix, and Microsoft SQL-Server. As long as the application offers an ODBC interface to its data files, f90SQL lets you manipulate data to the native application's format directly from your Fortran programs.

The next release of f90SQL will include the new f90SQL Wizard. The f90SQL Wizard is a set of utilities that helps you build your f90SQL applications. The Wizard includes the following utilities:

  1. DB Explorer: A database browser that you can use to check the ODBC Data Sources installed in your system, as well as the tables and fields in a database.
  2. SQL Editor: The SQL Editor is useful for writing and executing SQL queries against an ODBC database. You can write queries, check the syntax of your SQL statements, and see the results returned by the query.
  3. Query Assistant: With the Query Assistant you may create queries by selecting tables and columns using a Graphical User Interface. You can check the syntax of your queries and see the results from the query. When you are satisfied, you can ask the Query Assistant to generate an SQL statement that can be included in your f90SQL programs.
  4. Module Wizard: With the Module Wizard you can write a Fortran program to access your data in less than 10 minutes. The Module Wizard receives your SQL statement and generates a Fortran module that takes care of the database access details. Once you have the module, all you need to do is USE the module in your main program and call a few functions.

Stay tuned. We'll let you know when f90SQL v2.0 is available.

Winteracter Enhancements
(Back to Contents)

Winteracter v2.20 is now available! (Actually, it's been available since November 26, 1999.) If you havenít upgraded to the latest version of Winteracter yet, you are missing out. Upgrades from earlier releases include a new manual with loads of new features:

Graphoria emulation
The emulation of Lahey's Graphoria library (of F77L and EM/32 fame) has been extended.

HelpEd is the newest addition to an already extensive set of visual development tools. Need to create Windows help files for your program? Use HelpEd to create and edit a topic list and an optional contents file. You can prepare help topic text using the built-in RTF editor (see Text Editor below) and build the finished help file from within HelpEd.

Text Editor
The built-in text editor now offers RTF (Rich Text Format) support for font style and formatting control. The editor includes a new print option.

Graphics Primitives
Full 24-bit color is now available. You can directly specify a 24-bit RGB value allowing up to 16 million simultaneous colors in Windows GDI, PostScript, PCX, BMP, CGM, Draw, PCL, and ESC/P2 output. There's also a new graduated color fill primitive, IgrPolygonGrad, that takes advantage of 24-bit color control. Line width control is available in screen output in addition to hardcopy.

Bitmap Files
The routines that save PCX and BMP files from raw data and from a virtual raster have both been extended to support the 24-bit color file formats. You can display PCX files of any color depth (previously only 256-color files could be viewed). On 16-, 24-, and 32-bit video drivers, PCX screen image files are now saved in 24-bit color mode.

Graphics Import
IGrReplayArea allows you to zoom in on a specified area of an image when importing HP-GL, HP-GL/2, CGM and PIC files. 24-bit color information is reproduced when importing HP-GL/2, CGM, WMF and HP-GL files. IGrLoadImage now automatically recognizes the input file type (PCX or BMP).

Presentation Graphics
Marker frequency can now be specified on line plots. Text-labeling on scale points is available on 3D surface and scatter plots. User scaling is available on histogram X axes and bar-chart Y axes. 3D surface plots allow for transparent tiles. The number of decimal points in scale values can be enforced. And plotting speed in 2D fill-based contour plots is substantially improved when a granularity value greater than one is requested. Whew!

You can now open child windows in a hidden state thereby delaying their appearance until converted to a text editor or bitmap viewer. You can now specify the border style of each field in a status bar.

Memory Bitmaps
The bitmap put and get routines now operate on the current "drawable" rather than simply the current window. This allows bitmaps to be displayed in dialog fields and bitmap-to-bitmap copying.

You can specify the color of specific columns, rows, or cells grid controls. The cut and copy facility in grid controls is extended to support multiple rows and columns. The currently selected tab in a tab control can now be interrogated directly. You can selectively disable individual tabs in a tab control. Fields can be selectively hidden at run-time. A common dialog is included for text file printing.

PCX files of any color depth can be viewed, printed, and converted. The picture field no longer requires a (potentially slow) redraw when exposed. Printing options are extended with greater control over PostScript, HP-GL, and HP-GL/2 output.

So, what is Winteracter anyway? Winteracter is a 32-bit Windows user-interface and graphics package for Fortran 9x developers. It's available on Windows 9x, NT, and 2000 for all the major Fortran 9x compilers. Winteracter is developed by Interactive Software Services Ltd. and available from Lahey. Click on Products at to check it out. Put a Windows front on that old Fortran code.

GINO for Linux
(Back to Contents)

GINO is the name of a collection of portable graphics and GUI development tools available on a wide range of platforms including Win95/Win98/Win2000/NT, Linux, UNIX and OpenVMS. GINO products offer everything from simple line-drawings to complex fully-interactive three-dimensional applications with a fully-featured GUI front-end.

GINO-F Bundle for Linux

Following on from the release of Lahey LF95 Linux Express, GINO-F Bundle has now been ported to LF95 Linux Express. The GINO-F Bundle under Linux comprises GINO F v4.3, GINOGRAF v4.2, GINOSURF v3.2 and GINOMENU v3.1 (compatible with GINOMENU under UNIX). GINOMENU v3.1 provides a unique programmable GUI with emulation styles of Windows 3.1, Windows 95 and MOTIF available. The Bundle is supplied with drivers for X-Windows, Postscript and JPEG and other drivers such as HPGL2, HP-Paintjet, Epson and Canon are also available. The GINO-F Bundle for Linux is routine-name compatible with the GINO-F Bundle for Windows providing seamless portability of applications between the two platforms.

Price: $2100 ($1470 for educational license.)

GINOMENU v4.0 for Windows

Tabbed Dialog Box
A new tabbed dialog box (or property sheet) can now be displayed, and automatic scroll bars are provided if too many tabs are defined for the visible area.

Tree Views
Create hierarchical selection structures with the new Tree View widget..

Dockable Toolbars
Toolbars can float or be docked.

Bubble help
Bubble help can now be attached to most widget types and when the mouse pauses over the widget, the text can be displayed either as a standard bubble or displayed in the status bar.

Mouse-sensitive Icons
Icons can now be set to mouse-sensitive and therefore can have three associated images; greyed-out, unselected and selected.

Panel Backgrounds
An enhancement to the panel widget allows users to set a background image to the widget using a resource bitmap.

Security Text
A new security text type has been added which echoes 'xxxx' when text is entered.

Price: $2100 ($1470 for educational license.)

Special Offer
Attendees of the F95/GINO Workshop qualify for significant discounts on GINO products. Read the notice in this newsletter for details.

Using LF95 Linux Express with Linux Clusters
(Back to Contents)

Linux versus Windows
What is the fastest way to start an argument? Religion? Politics? No, if you really want to spice things up just ask, "What is better, Windows or Linux?" Then step back -- you are sure to get a spirited answer. Each operating system has features that attract loyal, enthusiastic followers. Windows users will point to ease of use and main stream acceptance as the main attractions of Windows. Linux users will counter that the open architecture and performance of Linux make it the operating system of choice.

We hear anecdotal reports that Fortran compilers perform better under Linux than Windows on single processor systems. The reasons cited vary such as the way Linux handles disk I/O or the memory limitations of Windows. We decided to get an expert opinion on the subject. Dr. John Appleyard of Polyhedron performs benchmarks on all the major Fortran compilers for both Windows and Linux. The plusFORT analysis package produced by Polyhedron is the industry standard for analysis tools. According to Dr. Appleyard,

"My own view is that for most Fortran related tasks, the two O/Ss give similar performance. Our benchmarks, which emphasize CPU and memory speed, appear to confirm that. Differences may be more apparent in areas such as web-hosting and transaction processing, which require more from the operating system."

Linux Express
The debate will no doubt continue. On one point, though, there is no debate. The new LF95 Express for Linux has been enthusiastically accepted by the Linux community. For the first time, Linux power users have a high performance Fortran compiler for a price of only $249. We have received gratifying testimonials from all over the globe. A typical response comes from the University of Helsinki, an institute that ought to know a little bit about Linux.

"That was quick! We did receive LF95 next day! We have now installed the first two of them and our first impression is very positive. Compared to Gnu g77 (which we used before) LF95 is several times more effective and the debugging information is excellent. Installation was also very straightforward."

Jukka Piironen, Department of Astronomy, University of Helsinki

MPICH for Linux
There is one feature of Linux that has a clear edge over Windows. MPICH is an implementation of MPI (message passing interface) that allows Linux LF95
Express users to create parallel applications that can run on more that one processor. Knowledgeable users have successfully installed Express on their Linux cluster.

"Linux Express was easily installed on our K7 Beowulf. With the complete [online] manuals provided by Lahey, the learning curve was extremely short. Performance using Linux Express versus g77 has significantly increased."

Richard C. Martineau, Staff Scientist, Idaho National Engineering & Environmental Laboratory

We have reports of people using LF95 with MPICH on 64-node systems, with faster performance than other Fortran compilers. The word is spreading fast. We have received requests to document the process to use LF95 Express with MPICH. By popular demand here is the process:

Code and documentation for MPICH can be downloaded from

Once the package has been downloaded and unzipped, it can easily be configured for use with LF95 by using the configure script in the ~/mpich directory. Documentation for configure can be viewed by issuing the command: ./configure -help | more. Configuring MPICH for LF95 is straightforward, from the ~/mpich directory, issue the command: ./configure -fc=lf95 -f90=lf95 . This command will set lf95 as both the Fortran 77 compiler and the Fortran 90 compiler. It will find and test lf95 and generate a makefile to direct the actual building of MPICH. Before running make, the output of configure should be inspected for errors, and any problems found should be resolved. When we configured MPICH on our Redhat 6.0 system, no errors occurred. If errors are encountered, they most likely will involve older versions of packages required by MPICH. Downloading the latest stable version of the package in question will likely fix the problem.

Once configuration is complete, you can build MPICH by typing make. If the configure was successful, it is most likely the make will proceed without a hitch. Once the make is complete, you may have to modify a couple of files. The first is machines.LINUX in the ~/mpich/util/machines directory. This file should contain the domain name of every machine that will run your program, with one name per line. To start with, this file will only contain the name of the machine building MPICH, repeated several times. MPICH will run multiple jobs on the same machine if it is listed more than once. The second file that needs to be created or modified is the hosts.equiv file in the /etc directory of every machine that will run MPICH. This file should contain the domain name of the machine that contains MPICH. Each node must have the LD_LIBRARY_PATH set with the path to the LF95 runtime libraries resident on the machine that has MPICH installed.

A set of test routines comes with MPICH that can be used to validate the installation. Some simple tests are in the ~/mpich/examples/basic directory. You need to first build the fortran examples with the make utility. Do this with the commands make fpi and make fibon . You can run the examples using mpirun. For example, mpirun -np 4 fpi will run the fpi program on four processors. A more extensive test suite is in the ~/mpich/examples/test directory. These need to be configured with the command ./configure -cc=mpicc -fc=mpif77. You can then run the test suite by issuing the command make testing. Note that the test routines are still under development, and some difficulties might occur. If problems arise, first make sure you have the most up-to-date version, then contact the MPICH developers at for assistance.

Although you can use MPICH on systems with a variety of characteristics, performance is best when all the machines have identical hardware and software configurations, as in a Beowolf cluster. This greatly simplifies the problem of load balancing Ė deciding which machine gets the next piece of the job. When different hardware and software are used, the slowest machine will dictate performance.

MPICH provides a significant breakthrough in the availability and cost of high performance computing. LF95 and MPICH, when used with a larger cluster can provide supercomputing capabilities at a fraction of the cost of todayís supercomputers.

Technical Support Policy
(Back to Contents)

Technical Support
If you haven't already noticed we have made a few changes to Technical Support in the last few months. These changes have been implemented in an attempt to improve the quality of the Technical Support we provide to our customers.

We'll continue to offer FREE e-mail, fax, and postal mail support on current product releases. Free support will continue to be available for previous versions of a product for 60 days after the release of a new version.

Technical Support Policy
To expedite support services, we prefer to process queries via e-mail. E-mail communications receive higher priority service because of the speed that it allows us to communicate and the level of detail that can be provided quickly. We realize that when you have a problem you want help as fast as possible. The best way to ensure optimum response is to provide the following information with your problem.

  • Registered user name
  • Registered serial number
  • Product title and version (for example LF95 v5.5)
  • Patch level (for example h patch)
  • Operating system (for example Windows 98 or Redhat Linux v6.0)
  • A short source code example
  • This will allow us to reproduce the problem. Please make sure the source code is as short as possible to allow us to analyze your issue quickly. Attach the source code file to your e-mail to
  • Third-party products used
  • If you are using an add-on library (such as Winteracter) or productivity tool (such as Visual Analyzer), provide the name and version of this product. If your application is mixed-language (such as Fortran and Visual Basic), provide the name and version of the non-Fortran language system.
  • System environment settings

To save your environment variables in a text file, go to a command prompt and redirect the output of the SET command to a file:


Attach the SETCMD.OUT file to your e-mail to

  • Step-by-step problem description
    1. Tell us the sequence of commands or buttons used that lead up to the problem occurring. Remember, if we can't reproduce it, we can't fix it for you.
    2. Compiler, linker, or Make/Automake messages.
    3. While simply typing the complete error message is always an option, you can save extensive messages to a text file to send to us, if that is easier. To save the messages as a text file, from the command line redirect the command output as in the following example:

      your_command_line > CMD.OUT

      Attach the CMD.OUT file to your e-mail to If you are using the ED editor, run your compile command and attach the ERRS.* file of the working directory to your e-mail to

    4. Exact text of error message or Window message box.

Support is provided free to solve problems with our products, and to answer questions on how to use Lahey products. Support personnel are not available to teach programming, debug programs, or answer questions about the use of non-Lahey products or tools (such as MS Windows, MS Visual Basic, etc.). These services are provided on a paid consulting basis.

In our effort to provide better technical support, we will continue to streamline our procedures to meet the changing needs of our customers. Our goal is to automate the tech support process as much as possible in order to provide the fastest, most complete response possible to as many customers as possible. We will also be extensively modifying the FAQ section of our web site. By expanding and organizing this resource, many problems may be immediately resolved.

Currently, e-mail requests for support allow us to organize an efficient tech support department and allow for quick turnaround time if the pertinent information is provided. Furthermore, e-mail is the most cost affective way for our customers to communicate with us. Our porting services and consulting contracts are always available to help you to solve difficult technical challenges or to get your Fortran projects finished.

Tech Support Tips
(Back to Contents)

We've compiled a list of hints and suggestions in question and answer form that may be helpful to you. These topics range from commonly asked questions about printers to undocumented switches. We hope you find them useful.

Q. Why does ED fail to print my source files?
A. A few of our customers have run into problems when using ED to print file contents. Luckily, there is an "easy" solution to most of these problems.

If when printing from ED you get any of the following scenarios:

  • "Program Error" or "Stack overflow" error message displayed by Windows, or
  • "This program has performed an illegal operation & will be shut down. If the problem persists, contact the program vendor" error message displayed by Windows, or
  • A string of messages like, "config.ces not found," "ed_exit.ces not found," "win_bar.ces not found," or "stat_bar.ces not found" in the ED status bar.

You're due for a new printer driver.

First try and get an updated printer driver for your specific printer. Try the your printer manufacturer's web site or Microsoft's web site.

Many times this happens only if you use the Font or Appearance dialogs before printing. If a new printer driver does not resolve the problem and you need to use the Font or Appearance dialogs then first change to a plain printer, start ED, select the printer and change the font/appearance options as required. Then close ED again. This will ensure the options are saved. When you start ED again, select the real printer and only use Print (not Font/Appearance) and it should work. Another method is to make changes via the Font or Appearance dialog, print to a file to save these changes, then print to the desired printer.

Q. My program compiles without error but at runtime I get an EXCEPTION_ACCESS_VIOLATION, why?
A. An EXCEPTION_ACCESS_VIOLATION error at runtime usually means that the program is trying to access memory not allocated to it. To help you determine where and why it is doing this, try compiling the source with -chk and -trace. This should provide more detail at runtime, including the location of the syntax that is causing the error and the variable using more memory than it has been allocated.

Q. Is there a way to limit the checking done with the -chk compiler option?
A. As is, the -chk compile option switch will check for 1) array and string subscript bounds violations, 2) agreement of type in dummy arguments, 3) array shape conformance, and 4) undefined variables.

An equivalent to -chk is the undocumented switch -lfe "-Hsaeu". Note that this switch is case-sensitive. The functionality of this switch can be broken down in the following fashion:

     s - check array subscripts (bounds)
     a - check dummy argument agreement
     e - check shape conformance
     u - check for undefined variables

Using this alternative allows you to select which of the four checks should be done at runtime and to control how much slower your executable will run. For example, if you want to check for everything but undefined variables to avoid a known and accepted runtime error, compile with -lfe "-Hsae". To check only for array bounds checking use -lfe "-Hs" . To check only for dummy argument agreement, use -lfe "-Ha". To check both, use -lfe "-Hsa". Similarly "-He" can be used to check shape conformance, and "-Hu" will check undefined variables. These switches can be used alone or in combination. So, the following is a valid command line that will check for both undefined variables and array bounds:

     lf95 source.f90 -lfe "-Hu" -lfe "-Hs"

Q. Why do I get linker errors for valid Windows API functions when compiling with -ml winapi ?
A. Many WinAPI functions are not supported by win32mod. There is an alternative which make available all of the WinAPI functions supported by Kernel32 routines. If you compile with -ml bc instead of -ml winapi you can access Kernel32 routines. Doing so should allow you to link any WinAPI functions declared in your source with the INTEGER and DLL_IMPORT statements.

Q. How can I print directly to a printer from the LF95 runtime?
A. The following information has been collected regarding printing directly from the LF95 runtime to a printer. To send information to a printer via a WRITE or PRINT statement you will have to create a link between an I/O unit number and the printer via an OPEN statement. The name of the file in the OPEN statement will depend on how the printer is connected to the operating system, via a direct cable connection or via a network. Please see the details for each scenario below.

Local Printer:
If the printer is connected directly to the PC, use file='prn' in the
OPEN statement. It is not necessary to capture the printer port when printing to a local printer. Example:

     open (11,file='prn')

Note, if file='LPT1' is used for a local printer LF95 will generate multiple copies of the output and a Bad File Number I/O error at runtime (after all executable statements).

Network Printer:
If the printer is connected via a network use
file='lpt1' in the OPEN statement, and capture the printer port via Windows. Example:

    open (11,file='LPT1')

Note, if file='prn' is used for a network printer the executable can generate large amounts of 'garbage' to be printed.

Before you can write to a printer port from windows for a network connected printer, you must first set up a "capture" of the printer port. See your Windows documentation for details.

Q. How can I control form feeds when printing directly to a printer from the LF95 runtime?
A. If you want to control form feeds when writing directly to a printer specify carriagecontrol='fortran' in the OPEN statement.

     open (11,file='LPT1',carriagecontrol='fortran')

To force a form feed use the following format specifier, without the backslash as with previous versions of the compiler, "('1')".

 5   format('1')

Q. I have LF90 code that calls the Windows API. What do I have to do to use it with LF95?
A. Recompile it with LF95 using -ml bc instead of -ml winapi. You shouldn't have to change your source code.

Q. When my allocatable arrays become very large, why does program execution slow down dramatically?
A. When a program starts to use more memory space than there is physical RAM available, the system starts "paging" and stores parts of the executing program on disk. Since the amount of time needed to access a disk is much greater than the time needed to access RAM, a significant slowdown occurs.

Q. Why do I have to use the DLL_IMPORT command to reference a DLL_EXPORTed subroutine within my DLL code.
A. The DLL_IMPORT command must be used because the exported subroutine or function name must be "decorated" to match the convention of the target system. The DLL_IMPORT declaration tells the compiler a subroutine will need to use the same decorations when calling an exported routine.

Q. I just read the question and answer above. What does decorated mean?
A. Decorate means to add a prefix or suffix to a procedure name in the object code to uniquely identify the name.

Q. My Linux program always stops when it encounters NDP exceptions. How can I make it continue processing?
A. Use the runtime switch "-Wl,-i" as an argument when executing your program. To always use this switch, set the environment variable FORT90L="-Wl,-I".

Q. My older program makes calls to the Lahey Video Graphics Library (LVGL). Does LF95 Standard or PRO support LVGL?
A. Yes! The WiSK gui library bundled with LF95 Standard and PRO contains an emulation of the LVGL. To pull in the LVGL emulation, use the -wisk switch when linking. When running the program, the graphics output may look different than the original program. This is mainly due to the emulation being Windows API based rather than DOS interrupt based.

Q. I want to run LF95 on one computer and create MPICH parallel programs that run across multiple computers. Do I have to buy a license for each computer?
A. No, as long as you run LF95 only on the one computer. You don't need additional licenses to run programs you create.

Q. In what movie did a Lahey language system first appear?
A. Contact, starring Jodie Foster.

CoEx Program Retired
(Back to Contents)

All good things must come to an end. As of April 1, the Lahey Corporate Express (CoEx) program has been phased out. No new memberships will be accepted. Existing memberships will not be renewed. Currently enrolled members will be offered a choice of exit options. These choices are:

  • Accept a free LF95 Express.You have the option of either LF95 Express for Windows or LF95 Express for Linux. (Shipping will be paid by Lahey.)
  • Continue to keep their CoEx active until they receive the next version of LF95. Their subscriptions will be extended until the next release.

The long running Lahey Corporate Express program was first introduced in the 1980's. Lahey compilers were first appearing on little computers called "personal computers." IBM picked an operating system called DOS from a little known software company in the state of Washington called Microsoft to run their little computers. In response to customer requests, Lahey introduced the Corporate Express program to allow Lahey customers to receive new updates promptly without the annoyance of going through the usual approval/purchasing cycle. This service was appropriate for that era.

How the times have changed! Microsoft has long since passed IBM in size and stature. DOS has become Windows 2000. An open architecture named after a 21-year-old student from the University of Helsinki has become the latest contender for operating system of choice. The hardware in those little computers has grown in performance and sophistication to levels unimagined in the 1980's. The evolution of operating systems and hardware configurations shows no signs of slowing down as the new century begins.

Future software from Lahey will be as varied and diverse as the computer industry itself. No single release, service, or feature can adequately address the requirements of our widening customer base. Rather than automatically distributing a new software release to CoEx members, we prefer to give them the freedom to choose which update is of value to them.

What now
CoEx members should contact Lahey at with their choice of options as described above. Please be sure to include your serial number and your current address in order to expedite your request. If you have any questions about your account or the CoEx program don't hesitate to ask. One thing that hasn't changed over the years Ė Lahey's commitment to our customers.

Help us end waste. Let us know if you change your address, receive duplicate copies of Fortran SOURCE, or would like to be removed from our mailing list.  Call us toll-free at 1-800-548-4778 or send us e-mail at  Thank you.