Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!seismo!rochester!bullwinkle!uw-beaver!uw-june!isabel
From: isabel@uw-june (Isabel Domenech)
Newsgroups: net.micro,net.micro.pc
Subject: MS FORTRAN 3.31 : a question and a flame.
Message-ID: <601@uw-june>
Date: Fri, 4-Apr-86 01:59:33 EST
Article-I.D.: uw-june.601
Posted: Fri Apr  4 01:59:33 1986
Date-Received: Sat, 5-Apr-86 11:58:00 EST
Organization: U of Washington Computer Science
Lines: 45
Xref: watmath net.micro:14259 net.micro.pc:7679

Does anybody know how to patch the Microsoft FORTRAN compiler v. 3.2, or the
resulting executable files, so that the presence of a 287 math co-processor is
properly checked at run time?

The check works well on a PC, but on an AT it seems the code always decides
that there is a 287, even when one is not present. As a result the machine
hangs, waiting for the 287 to respond.

I bought the current version (3.31) because it has fixed the problem, but it
is unusable to me right now because Microsoft has decided to change the memory
model and my programs will no longer work.

I wrote a finite element analysis package, which requires big arrays. To avoid
having to create different versions for machines with different memory sizes
(512K, 640K, ...) the programs check the available amount of memory in the
machine at runtime and use it if needed.

This is possible because in version 3.2 the named COMMON blocks are allocated
after everything else and, therefore, the last one may be expanded to the top
of the memory very easily.

But now the last thing allocated is the stack, with the named COMMON blocks
buried somewhere in the middle. Of course, to expand the stack is now a piece
of cake, but what good does it do in FORTRAN?

I suspect that Microsoft wants us to use FORTRAN the same way we would use C,
which in my opinion is not the way to go. Their compiler still has many things
missing from the 77 standard but they seem more interested in adding
non-standard features (C strings, INTERFACE, Attributes (ALIAS, NEAR, HUGE...))
than in supporting the full ANSI standard. What a joke!

Another thing that irks me is that their documentation still shows the old
memory model (Section 10.3.2) and you don't discover the problems until you
either look at the map provided by the linker or notice that a table in one
of the appendices (A.11) contradicts the information presented in much more
detail in the main text.

In summary, I am most unhappy with this product and with the unprofessional
attitude of Microsoft. Anybody looking for a FORTRAN 77 compiler should try
to look elsewhere because Microsoft efforts to support the language do not seem
very serious.

Thanks in advance to anybody that may help me fixing the 287 bug.

                                        Fernando G. Loygorri (isabel@uw-june)