Volume 16, Issue 1 Welcome to the Lahey Fortran Source Newsletter.
Welcome to the Lahey Fortran Source Newsletter.
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
(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, firstname.lastname@example.org. 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:
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:
CHARACTER, COMPLEX, INTEGER, LOGICAL, and REAL
Note: NoDOUBLE PRECISION which is still a standard type, but not a default type.
Fortran 90 also formalized extended-precisionCOMPLEX. 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, ...
ForREAL variables, the syntax is:
REAL( SELECTED_REAL_KIND( P=40, R=50 ) ) :: x, y, z, ...Two reasons for using this approach:
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.
(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:
SUBROUTINE ADDV(A, B, C, N)
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:
SUBROUTINE MATX(A, B, C, L, M, N)
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.
(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:
Stay tuned. We'll let you know when f90SQL v2.0 is available.
(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:
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.
(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
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.
(Back to Contents)
Linux versus Windows
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."
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
"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 http://www-unix.mcs.anl.gov/mpi/mpich.
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 email@example.com 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.
(Back to Contents)
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 save your environment variables in a text file, go to a command prompt and redirect the output of the SET command to a file:
SET > SETCMD.OUT
Attach the SETCMD.OUT file to your e-mail to firstname.lastname@example.org.
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 email@example.com. 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 firstname.lastname@example.org.
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.
(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.
does ED fail to print my source files?
If when printing from ED you get any of the following scenarios:
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.
Note, iffile='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).
Note, iffile='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')".
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.
Why do I have to use the
command to reference
a DLL_EXPORTed subroutine
within my DLL code.
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
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.