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, ideas@lahey.com. 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:

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.

Regards,

Tom

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, 5^th-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:

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:

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.

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 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
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!

Windows
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.

Dialogs
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.

PlotConv
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 http://www.lahey.com to check it out. Put a Windows front on that old Fortran code.

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.

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.)

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.)

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,

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
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 support@lahey.com.
• 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

• Step-by-step problem description

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.

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.

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.

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.

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

Why
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.