From: George White on
On Sun, 7 Mar 2010, Terence wrote:

> My kids draggged me screaming away from my roomful of faithful museum-
> quality DOS and Windows--running computers and presented me with a
> MacPro Professional, with Windows 2000 loaded under simulation.
>
> After facing the grief of an entirely new user interface to learn,
> what do Forum members recommend for me, to aquire a trustable Fortran
> compiler, with which I can continue to compile my (F77) code and have
> it run on Apple AND Windows systems (even if two versions are
> needed)?

Don't be afraid to use a Fortran 9x or 200x compiler unless you rely
heavily on some vendor-specific extensions to f77 or specific layout of
common blocks in memory the changes should be minor. For legacy f77
code I see current compiler standards as just cleaning up gratuitous
vendor-specific differences.

Gfortran is pretty solid and the price is right. At work we use a large
NASA application that has required commercial compilers for the past 13
years but is now working with gfortran-4.5. Some things are faster with
the commercial compilers, but overall gfortran is only slightly slower.
Installing free fortran on Windows has been a bit of a headache as it
relies on tools that you don't normally find on Windows. These days I
just install Octave, which includes a fortran compiler.

For Apple, there have been way too many buggy builds of gfortran, but
the R-project's Apple people provide a reliable build of gfortran-4.2.


Windows 2000 is about to reach "end of life" and already new versions
of some apps have dropped Win2K support, so you may find your options
limited.

> I note that the Apple MAC is really based on an Intel chip and nVidia
> graphics and happily runs my DOS code under the VMware Fusion
> application.
> ( Here I inteject to note that I had to eliminate some Fx key
> shortcuts and write new ASM software to get real Funtion keys, and ALT-
> arrow simulations of the "missing" Home, End, Page up, Page down and
> control-arrow keys. Unfortunately there is no Delete function as "we"
> know it, but a "Delete"-labelled backspace erasing key that starts in
> the "wrong" place, and there is no insert key; that makes running
> good old software a little difficult. But the kludge works).
>
> So: Fortran compilers to run on Apple MAC (or Windows simulation) with
> target systems of native Apple MAC and Windows 2000 or V7?
> (Not really happy with XP; and Vista is Dodo-bound).



--
George White <aa056(a)chebucto.ns.ca> <gnw3(a)acm.org>
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
From: Tim Prince on
On 3/8/2010 10:49 AM, Richard Maine wrote:

>
> BootCamp doesn't support a whole lot of Windows versions, though.
> Quickly checking Apple's support pages, I see that it doesn't support
> 64-bit XP at all. So if you are talking x64 .exes, I guess that must be
> either Vista or Windows 7, neither of which I have even token experience
> with - never so much as touched a keyboard or mouse on a system running
> them. Bootcamp supports those only on pretty recent systems. Are you
> saying that one of those doesn't have working network drivers in
> bootCamp?
>
> I'd think a bigger factor would be that bootCamp might not support your
> favorite Windows version at all. In particular, if you are looking for
> x64 support and don't have one of the machines listed as supporting
> that, then you'd have a problem. I suppose that perhaps lack of the
> needed drivers might be exactly why Apple doesn't support some
> combinations.
>
> P.S. Another possibility for keyboard unhappiness is to use a 3rd party
> keyboard. I haven't done so, but most/all? USB keyboards ought to work.
> I do use 3rd party mice (well, trackballs).
>
We installed Windows 7 X64 with reasonable success under bootcamp on a
new Mac 2 months ago. As you say, Apple made no mention of supporting
it. Win-7 home premium doesn't support LAN connection, while bootcamp
didn't provide wireless support for win-x64. We looked every which way.
Win-7 Pro and above support a LAN connection, and that did work in
bootcamp.
I don't spend enough time running an IPod to be proficient on the Mac
mouse pad or whatever it's called.

--
Tim Prince
From: Terence on
My Mac is a MacBook Pro, it says here).
I tried my old F77 compiler and it runs OK.
I tried several ancient DOS programs an all worked except when page up
or down were needed (not on MAC), and the alternative ctl-up and ctl-
down arrows gave no response at all!
I tried using a keyboard test program that was compiled with MS F77
V3.31, that itself call a standard dos service call to read an
extended keyboard as two byte scancodes.
The result is strange.
All keystrokes that would be expected to produce a character code plus
a key number do so.
But the Function keys is all shift combinations yield results with a
half-second pause.
The unshifted arrow keys give a normal response.
But the ctl and alt key combinations of the arrow keys return codes
after a 5 second pause!

I tried a Fotran program that used both Int 16h with 16H in AH, and a
read string (Int 10 with #0902 in AH), as two different input
keystroke methods.
Same result.

I then tried the MS EDIT program and used arrow keys to navigate.
Response speed was normal, but this uses no extended keyboard keys.
I gather there must be a problem with getting the extended keyboard
codes and somewhere a time-out is built in, in the emulator.

And I was trying to move on...
From: Gordon Sande on
On 2010-03-11 06:32:13 -0400, Terence <tbwright(a)cantv.net> said:

> My Mac is a MacBook Pro, it says here).
> I tried my old F77 compiler and it runs OK.
> I tried several ancient DOS programs an all worked except when page up
> or down were needed (not on MAC), and the alternative ctl-up and ctl-
> down arrows gave no response at all!

The absence of page-up and page-down is more associated with it being
a laptop than its being a Mac. The mini keyboards on laptops all look a
lot alike so PC laptops would have similar problems. Full size Mac
keyboards look a lot like other full size keyboards back to the days of
VT100s with both a numerical pad and cursor and function cluster. Many
laptops support using a full sized leyboard through an i/o port. These
external keyboards are both Mac abd PC comapatible. Most laptops even
support an auxilary monitor to become replacements for a desktop.

Macs normally run MacOsX and not DOS. So you must be using an PC emulator
as you tell us at the end. There are three of them! You forgot to say which
one. In any case they all have their own sources of support for a problem
which is not a Fortran problem. You will almost certainly have better luck
asking is a place concerned with whichever emulator you are using. They
may even know the their way of emulating the keys missing from a full size
key board. Common ways are a multi finger salute or a sequence of keys. For
all I know they may even offer choices of which method or combination of keys.

The other way would be to ask the support folks who handle MS F77.

> I tried using a keyboard test program that was compiled with MS F77
> V3.31, that itself call a standard dos service call to read an
> extended keyboard as two byte scancodes.
> The result is strange.
> All keystrokes that would be expected to produce a character code plus
> a key number do so.
> But the Function keys is all shift combinations yield results with a
> half-second pause.
> The unshifted arrow keys give a normal response.
> But the ctl and alt key combinations of the arrow keys return codes
> after a 5 second pause!
>
> I tried a Fotran program that used both Int 16h with 16H in AH, and a
> read string (Int 10 with #0902 in AH), as two different input
> keystroke methods.
> Same result.
>
> I then tried the MS EDIT program and used arrow keys to navigate.
> Response speed was normal, but this uses no extended keyboard keys.
> I gather there must be a problem with getting the extended keyboard
> codes and somewhere a time-out is built in, in the emulator.
>
> And I was trying to move on...


From: user1 on
Terence wrote:

>
> And I was trying to move on...

Still using a 16bit DOS based compiler and old fashioned DOS interrupts.
Time to move on indeed.