converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++, part 2

[Lynn McGuire]

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
lines of code engineering software product to C++. With all that code,
we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
Win64 EXEs and three Win64 DLLs to the product with the same
capabilities as the Win32 versions (console, windowed, Excel callable,
Excel embeddable). Plus support for Unicode named files and Unicode
file paths.

I am using a customized version of f2c at the moment to automate 80% of
the conversion from F77 to C++. I have added support for logical*8,
changed the output file from *.c to *.cpp, added an include for the
Fable fem.hpp template library, removed the trailing underscores from
the subroutine and common block names, removed the ftnlen arguments from
the character arguments, converted all F77 comments to the // instead of
the /* */, and a few other items. If desired, I am willing to post a
copy of my modified f2c on my website with the source code.
https://netlib.org/f2c/
https://en.wikipedia.org/wiki/F2c

f2c does not get me totally there. The Fortran character strings were
poorly handled so they will probably needed fixing for proper sizing and
alignment. The f2c i/o code is crap so I take the original F77 i/o code
and translate it by hand. The arrays in the argument list are still
based at an index of one so I convert those to base index of zero by
hand. All of the local and common block arrays were converted to a base
index of zero by f2c. I add the new *.cpp file to my Visual Studio
project. I then add the new function prototypes to my prototypes.h file
and I add any new common block structures to my commons.h file. I then
compile and fix until I get a clean compile.

I have converted over 29,000 lines of F77 code to C++ now. Almost a
hundred subroutines and several dozen common blocks. Most are compiling
cleanly in Visual C++ 2015. My testing is working well with the
problems being in the character string area. I am still aiming for
Christmas for completing the small data analysis program in my
calculation engine. It is somewhere around 150,000 lines of F77 code.
Tough to tell since it shares so much code with my big calculation
engine which is around 600,000 lines of F77 code and 50,000 lines of
C++. They share about 75,000 lines of F77 and C++ code.

Thanks,
Lynn

[Tran Quoc Viet]

Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?

[Lynn McGuire]

I am having problems mixing C++ and Fortran code in Visual Studio so I
am trying to move to all C++. I suspect if I was all Fortran then my
life would be easier.

Lynn

[JRR]

Am 19.11.22 um 07:01 schrieb Lynn McGuire:

>
> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
> hundred subroutines and several dozen common blocks.  Most are compiling
> cleanly in Visual C++ 2015.  My testing is working well with the
> problems being in the character string area.  I am still aiming for
> Christmas for completing the small data analysis program in my
> calculation engine.  It is somewhere around 150,000 lines of F77 code.
> Tough to tell since it shares so much code with my big calculation
> engine which is around 600,000 lines of F77 code and 50,000 lines of
> C++.  They share about 75,000 lines of F77 and C++ code.
>
> Thanks,
> Lynn

From the experience in my field of physics, for all the codes that have
not been written from scratch, but translated from Fortran77 to C(++)
the main struggle started _after_ the codes had been translated. That is
because after the translation many codes are in state of pure C, not C++
code, and basically are not using any of the nice features of C++. Then
using things like OO, polymorphism and features of the C++ stdlib took
the authors much more time than the simple translation from Fortran77 to
C(++).


--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
------------------------------------
invalid is desy .and. com is de

[Thomas Koenig]

JRR <juergen...@invalid.com> schrieb:

> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>
>> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
>> hundred subroutines and several dozen common blocks.  Most are compiling
>> cleanly in Visual C++ 2015.  My testing is working well with the
>> problems being in the character string area.  I am still aiming for
>> Christmas for completing the small data analysis program in my
>> calculation engine.  It is somewhere around 150,000 lines of F77 code.
>> Tough to tell since it shares so much code with my big calculation
>> engine which is around 600,000 lines of F77 code and 50,000 lines of
>> C++.  They share about 75,000 lines of F77 and C++ code.
>>
>> Thanks,
>> Lynn
>
> From the experience in my field of physics, for all the codes that have
> not been written from scratch, but translated from Fortran77 to C(++)
> the main struggle started _after_ the codes had been translated. That is
> because after the translation many codes are in state of pure C, not C++
> code, and basically are not using any of the nice features of C++. Then
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to
> C(++).

Which begs the question - why not introduce the OO featues that
modern Fortran can do, without first converting to the common
subset of C and C++?

[FortranFan]

On Wednesday, November 23, 2022 at 6:36:28 PM UTC-5, vie...@gmail.com wrote:

> ..

> Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?

@vie...@gmail.com,

Can you please elaborate on "I stopped that job because I found its nonsense"?

Our experience suggests what OP's pursuit - "converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++" - to be UTTER NONSENSE.

Please note OP is the President and CEO of a commercial software company, WinSim Inc. https://www.winsim.com/staff.html

And the software in question is primarily the *calculation engine* in the area of chemical process simulation in steady-state conditions (d/dt - where t is time - terms in the physical relations starting with the laws of conservation of mass and then energy applied to simulate the chemical processes are not applicable at steady-state). The simulator may have dynamic modes where the PDEs and the ODEs in terms of time become relevant. Anyways, what is stake is heavy-duty number-crunching using arrays of floating-point variables for which Fortran is extremely strong. Moreover there is an extremely rich, powerful, performant, and validated legacy and set of Fortran libraries.

Also, note >80% of the computation time is expended in the libraries toward chemical process thermodynamics, particularly in the procedures toward the so-called equation-of-state and activity coefficient (Gexcess) models for fluids involved in the chemical processes. Toward these, there is again a rich legacy and history of codes and libraries in Fortran.

OP - MICHAEL LYNN MCGUIRE, P.E. - is absolutely on a wrong path to convert the existing code to basically C but which OP wrongly calls as C++ which is primarily due to Microsoft lumping C and C++ together with its Microsoft C/C++ compiler product.

Those who like to bet can place any odds and bets that OP shall make use of very little C++ should this conversion effort proceed to its fullest. If at all anything, the C++ will be a few features here and there from the days prior to C++ 98 standard which was over 25 years ago. Note C++ only became competitive with Fortran in the compute domain applicable to OP - as explained above - starting with its C++14 standard revision, but it appears unlikely any of the C++14 standard features will be picked up by OP in this "conversion" pursuit.

OP needs HELP, SERIOUS HELP. OP, as President and CEO of a company, should focus first on hiring and contracting top-quality professionals for the task.

OP should CEASE the non-sensical "conversion" to C using F2C.

Instead OP should FIRST contract and consult with top talents such as Archaeologic Codes and complete a through review of the existing "landscape" around the legacy nonstandard FORTRAN codes in the WinSim commercial software. That is, the so-called 700,000 LOC routinely mentioned by OP - and have Archaeologic Codes deliver feedback and possibly a proposal for a true modernization effort using modern Fortran. Here is the website for Archaeologic Codes for OP's benefit:
https://www.archaeologic.codes/about

Please know OP has been pursuing this conversion exercise at least since the 2008-2010 timeline, one can find posts at comp.lang.fortran stating the same as the original post going that far back.

In the meantime, modern Fortran has advanced tremendously and Intel now offers FREE compilers in IFORT and IFX that integrate reasonably well with Microsoft Visual Studio. In addition there are other powerful and free Fortran compilers such as gfortran. Compared to the workflows OP likely employs currently with WATFOR, etc., the modern Fortran processors can serve WInSim's developer staff very well. Moreover IFORT supports all of Fortran 2018 including the enhanced operability with C facilities, meaning the calculation engine of WinSim can work highly efficiently with the rest of C/"C++" code, often in the graphical user interface and other data preprocessing and post-processing sections of the chemical process simulator.

In addition, there is a fast advancing ecosystem around modern Fortran with free REPL environments in Lfortran (https://lfortran.org/), Fortran stdlib efforts that will produce rich Fortran libraries including numerical ones that WinSim can make use of, also various other tooling including Microsoft Visual Studio Code, and so forth that will serve the future WinSim staff extremely well, should OP steer toward modernization with modern Fortran now with the help of folks such as Archaeologic Codes.

OP would do well to STOP the conversion of legacy nonstandard FORTRAN codes in WinSim now and instead get in touch with modern Fortran experts - PRONTO!

[FortranFan]

On Thursday, November 24, 2022 at 8:29:03 AM UTC-5, JRR wrote:

> ..

> From the experience in my field of physics, for all the codes that have
> not been written from scratch, but translated from Fortran77 to C(++)
> the main struggle started _after_ the codes had been translated. That is
> because after the translation many codes are in state of pure C, not C++
> code, and basically are not using any of the nice features of C++. Then
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to

> C(++). ..

@JRR is exactly right. This link on 1967 ASME Steam Tables code with "steam.c" file is the "best" that can come out from OP's exercise:
https://www.winsim.com/steam/steam.html

It will be far better for modern codes, especially commercial ones, to avoid working with "raw pointers" which are highly likely from OP's "translation" effort. OP would do well to reconsider as indicated here:
https://groups.google.com/g/comp.lang.fortran/c/NmQkbtALkyo/m/xWYvXlx0CAAJ

[FortranFan]

On Thursday, November 24, 2022 at 10:00:12 AM UTC-5, Thomas Koenig wrote:

> ..

> Which begs the question - why not introduce the OO featues that
> modern Fortran can do, without first converting to the common
> subset of C and C++?

OP, as the President and CEO of a commercial software company, should be in the "business" of hiring and contracting top talent and coordinating and directing and managing and executing projects with them rather than trying out a discontinued tool like F2C and converting code.

https://www.archaeologic.codes/services
Archaeologic Codes can provide services to OP and WinSim Inc. that can help modernize the WinSim's legacy nonstandard FORTRAN code base to IEC ISO standard modern Fortran and then introduce all the relevant programming paradigms starting structured and modular programming accompanied by, as applicable OO, and functional programming along with parallel programming also, all in standard Fortran which can integrate most efficiently with the rest of the code for GUI, data processing, etc. which, for various other reasons, tends to be not in Fortran.

[Lynn McGuire]

On 11/24/2022 7:28 AM, JRR wrote:
> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>
>> I have converted over 29,000 lines of F77 code to C++ now.  Almost a
>> hundred subroutines and several dozen common blocks.  Most are
>> compiling cleanly in Visual C++ 2015.  My testing is working well with
>> the problems being in the character string area.  I am still aiming
>> for Christmas for completing the small data analysis program in my
>> calculation engine.  It is somewhere around 150,000 lines of F77 code.
>> Tough to tell since it shares so much code with my big calculation
>> engine which is around 600,000 lines of F77 code and 50,000 lines of
>> C++.  They share about 75,000 lines of F77 and C++ code.
>>
>> Thanks,
>> Lynn
>
> From the experience in my field of physics, for all the codes that have
> not been written from scratch, but translated from Fortran77 to C(++)
> the main struggle started _after_ the codes had been translated. That is
> because after the translation many codes are in state of pure C, not C++
> code, and basically are not using any of the nice features of C++. Then
> using things like OO, polymorphism and features of the C++ stdlib took
> the authors much more time than the simple translation from Fortran77 to
> C(++).

Interesting. Are there any public writeups to the experiences ?

I wonder if the problems were due to a lack of familiarity with C++ or
the fact that C++ has a much larger toolset than Fortran does.

Thanks,
Lynn

[Lynn McGuire]

The problem that I have run into in modern Fortran is that there is not
a good IDE (interactive development environment) on Windows. Since we
do not have any current customers on Unix / Linux, I do not know about
those platforms.

I tried Simply Fortran using GCC and GFortran and was very unsatisfied
with the debugger, we need to be able to stop at the 459th call to a
certain method. I tried Visual Studio 2019 with Intel Fortran and
Visual C++ and was very unhappy with the poor integration of Intel
Fortran into the IDE.

I like the modern features that C++ offers such as polymorphism but I am
very happy with the fact that C++ is a better compiler than C. I do
happen to use polymorphism in some of our common methods (pow, abs,
writing to an output file, etc) but it is a matter of convenience rather
than a goal of the project.

I will report next when I get my small data analysis tool running if
anyone is interested.

Thanks,
Lynn

[FortranFan]

On Friday, November 25, 2022 at 12:38:27 AM UTC-5, Lynn McGuire wrote:

> ..

> The problem that I have run into in modern Fortran is that there is not
> a good IDE (interactive development environment) on Windows. Since we
> do not have any current customers on Unix / Linux, I do not know about
> those platforms.
>
> I tried Simply Fortran using GCC and GFortran and was very unsatisfied
> with the debugger, we need to be able to stop at the 459th call to a
> certain method. I tried Visual Studio 2019 with Intel Fortran and
> Visual C++ and was very unhappy with the poor integration of Intel

> Fortran into the IDE. ..

Re: "The problem that I have run into in modern Fortran is that there is not a good IDE (interactive development environment) on Windows,"

- that's a fair criticism that is consistently felt in the Enterprise domain (e.g., large companies such as Bayer, BASF, DuPont, Dow, Exxon, Shell, Linde, etc. and the vendors such as WinSim, Inc. who sell products and services to them) where Windows OS is the primary or the sole OS platform for computations even.

Re: ".. very unhappy with the poor integration of Intel Fortran into the (Visual Studio) IDE .."
- that too is a fair criticism that many a manager in the Enterprise domain have expressed and I have been feeding that back to Intel software team for quite a while now, but Intel team faces many challenges.

In spite of the above challenges, OP and others would do well to look at other recent developments e.g., those getting discussed and planned and extended at the Fortran Discourse site and know things are starting to move faster now with in the modern Fortran space and it is worth giving modern Fortran a strong consideration, especially if you have a code base in legacy nonstandard FORTRAN (77 and its prior/later dialects).

The benefits of investing in modern Fortran in the chemical process simulation domain of interest to OP specifically and scientific and technical computing generally are significantly better than going with generic C++. With C++, one would have to make major strides in complete redesign and refactoring to modern C++ e.g., C++17 and perhaps some of C++20 and later features. But that's a massive task, adding big layers of computational complexity. Methinks modern Fortran will be better.

[Gary Scott]

On 11/24/2022 11:38 PM, Lynn McGuire wrote:
>snip

>
> I tried Simply Fortran using GCC and GFortran and was very unsatisfied
> with the debugger, we need to be able to stop at the 459th call to a
> certain method.  I tried Visual Studio 2019 with Intel Fortran and
> Visual C++ and was very unhappy with the poor integration of Intel
> Fortran into the IDE.
>

VS on windows is the premier option. When the IVF integration works, it
is pretty good. What I've found though is that the integration breaks
frequently. In my case at present, it is broken and I can't seem to get
it repaired. The repair mechanism/upgrades think it is already
integrated when it isn't. So the help integration works, but the IDE
doesn't recognize the existing solutions (VS 2019) that worked a few
months ago. Very frustrating. I'll probably have to
uninstall/reinstall VS and then reinstall IVF in order to fix the
problem. It stopped working when VS installed one of it's own updates.

[Lynn McGuire]

Unfortunately, Microsoft does not care about Fortran. They showed that
many years ago when they dropped Powerstation. I do not know why Visual
Studio does not work with Intel Fortran more but it is disappointing.
We use Visual C++ 2015 to build our Windows user interface with 450,000
lines of C++ code. It works extremely well for us even though our code
dates back to Windows 1.0.

The only thing that I know to do at this time is to move my Fortran code
to a Microsoft supported language. After all, there is some evidence
floating about that Microsoft is getting ready to follow Apple, once
more, and jump to the ARM cpus and leave Intel behind.

Thanks,
Lynn

[Mut...@dastardlyhq.com]

On Fri, 25 Nov 2022 13:58:20 -0600
Lynn McGuire <lynnmc...@gmail.com> wrote:
>Unfortunately, Microsoft does not care about Fortran. They showed that
>many years ago when they dropped Powerstation. I do not know why Visual
>Studio does not work with Intel Fortran more but it is disappointing.
>We use Visual C++ 2015 to build our Windows user interface with 450,000
>lines of C++ code. It works extremely well for us even though our code

450K lines just for the interface?? How many windows does it have, a few
hundred??

>The only thing that I know to do at this time is to move my Fortran code
>to a Microsoft supported language. After all, there is some evidence
>floating about that Microsoft is getting ready to follow Apple, once
>more, and jump to the ARM cpus and leave Intel behind.

MS have tried that a number of times. Unless they can get the PC makers along
with them it'll be another failure. People who buy Apple don't have a choice
about the CPU, PC buyers do.

[FortranFan]

On Friday, November 25, 2022 at 2:58:25 PM UTC-5, Lynn McGuire wrote:


@Lynn McGuire,

> The only thing that I know to do at this time is to move my Fortran code

> to a Microsoft supported language. ..

Please try to follow this discussion also at the Fortran Discourse site and perhaps provide comments there:
https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808?u=fortranfan

> After all, there is some evidence
> floating about that Microsoft is getting ready to follow Apple, once
> more, and jump to the ARM cpus and leave Intel behind.

Are not the higher-end Apple macOS laptops still using Intel CPUs, as opposed to ARM? In an Enterprise domain like at the influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run software such as WinSim are still likely to be on higher-end laptops i.e., Intel CPUs for the foreseeable future.

[FortranFan]

On Friday, November 25, 2022 at 12:38:27 AM UTC-5, Lynn McGuire wrote:

@Lynn McGuire,

> ..

> I tried Simply Fortran using GCC and GFortran and was very unsatisfied
> with the debugger, we need to be able to stop at the 459th call to a
> certain method.

Separately, note with Intel Fortran and Visual Studio, one can do this i.e., "be able to stop at the 459th call to a certain method" Note there are quite a few users at the Intel Fortran forum as well as the Fortran Discourse now who are able to perform graphically debugging with Intel Fortran in Visual Studio and who are ever willing to help other users, say if WinSim Inc. had a dozen developers doing this, or only Lynn McGuire even, they could post online and get top-notch real-time help and assistance to get going with their Fortran debugging. Here's a comment from a reader at the Fortran Discourse site:

"I find visual studio with intel one api fortran a very good IDE for debugging in modern fortran on a Windows machine. It used to be very expensive but now it’s free. What I like the most about it is that you can set breakpoints and step through the code very easily. You can also inspect variables in smth called immediate window in the bottom right of the screen."
https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808/6?u=fortranfan

> I tried Visual Studio 2019 with Intel Fortran and
> Visual C++ and was very unhappy with the poor integration of Intel
> Fortran into the IDE.
>

Sure there are some installation challenges and if one were to get into a compare mode with other languages such as Microsoft's own C# in Visual Studio, Fortran will look poor.

But the larger picture I suggest keeping in mind are the benefits of modern Fortran for scientific and technical computing. There is great movement to improve the ecosystem around Fortran. There is already feedback that modern Fortran works very well with Visual Studio Code, the other editor product from Microsoft. There will more editor and IDE support forthcoming with modern Fortran.

[Lynn McGuire]

On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
> On Fri, 25 Nov 2022 13:58:20 -0600
> Lynn McGuire <lynnmc...@gmail.com> wrote:
>> Unfortunately, Microsoft does not care about Fortran. They showed that
>> many years ago when they dropped Powerstation. I do not know why Visual
>> Studio does not work with Intel Fortran more but it is disappointing.
>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>> lines of C++ code. It works extremely well for us even though our code
>
> 450K lines just for the interface?? How many windows does it have, a few
> hundred??

One main diagrammatic window with multiple sheets and about 150 dialogs
for the users to specify their simulation. The main window looks a lot
like Visio.
https://www.winsim.com/screenshots.html

Writing commercial software requires a lot of code.

>> The only thing that I know to do at this time is to move my Fortran code
>> to a Microsoft supported language. After all, there is some evidence
>> floating about that Microsoft is getting ready to follow Apple, once
>> more, and jump to the ARM cpus and leave Intel behind.
>
> MS have tried that a number of times. Unless they can get the PC makers along
> with them it'll be another failure. People who buy Apple don't have a choice
> about the CPU, PC buyers do.

This is true. But the lower energy requirements of the ARM chips makes
them very interesting, especially for laptops. Plus, several USA states
)California, etc) are starting to regulate cpu power levels, these will
probably drop as time goes on.

Lynn

[JRR]

Am 25.11.22 um 06:06 schrieb Lynn McGuire:

> On 11/24/2022 7:28 AM, JRR wrote:
>> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>>

>

> Interesting.  Are there any public writeups to the experiences ?
>
> I wonder if the problems were due to a lack of familiarity with C++ or
> the fact that C++ has a much larger toolset than Fortran does.
>
> Thanks,
> Lynn
>

There was a data format, called StdHEP, in high energy physics that is
still in use in legacy applications (for data sets of experiments that
have been run in the 1990s e.g.). This uses common blocks for the data
structures, and a lot of F77 code, interfaced with C TIRPC libraries.
This has been converted and partially rewritten under a new name, HepMC,
in 2001. It was a very basic new implementation, more C, than C++, and
less efficient than the old implementation. It took them 16 years until
2017 to come with a modern C++ version of this data format.

[Lynn McGuire]

On 11/26/2022 2:38 PM, JRR wrote:
> Am 25.11.22 um 06:06 schrieb Lynn McGuire:
>> On 11/24/2022 7:28 AM, JRR wrote:
>>> Am 19.11.22 um 07:01 schrieb Lynn McGuire:
>>>>
>
>>
>> Interesting.  Are there any public writeups to the experiences ?
>>
>> I wonder if the problems were due to a lack of familiarity with C++ or
>> the fact that C++ has a much larger toolset than Fortran does.
>>
>> Thanks,
>> Lynn
>>
>
> There was a data format, called StdHEP, in high energy physics that is
> still in use in legacy applications (for data sets of experiments that
> have been run in the 1990s e.g.). This uses common blocks for the data
> structures, and a lot of F77 code, interfaced with C TIRPC libraries.
> This has been converted and partially rewritten under a new name, HepMC,
> in 2001. It was a very basic new implementation, more C, than C++, and
> less efficient than the old implementation. It took them 16 years until
> 2017 to come with a modern C++ version of this data format.

I will let you know how "efficient" my translation is when I am
complete. I can assure you that is definitely one of my concerns. I
time our software regularly to see what our changes have done to it.

Thanks,
Lynn

[Gary Scott]

On 11/26/2022 1:33 PM, Lynn McGuire wrote:
> On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran.  They showed that
>>> many years ago when they dropped Powerstation.  I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code.  It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
> One main diagrammatic window with multiple sheets and about 150 dialogs
> for the users to specify their simulation.  The main window looks a lot
> like Visio.
>    https://www.winsim.com/screenshots.html
>

These would have been super easy with GINO. It was designed exactly for
this type of application. A GUI API tailored specifically for Fortran.

[Lynn McGuire]

We had a Gino CAD user interface on the Vax back in the 1980s. It was
not easy to write nor was it easy to maintain. The plotter/printer
interface was absolutely horrible, you essentially had to rewrite the
driver for each plotter or printer model.

Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

> On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran. They showed that
>>> many years ago when they dropped Powerstation. I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code. It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
> One main diagrammatic window with multiple sheets and about 150 dialogs
> for the users to specify their simulation. The main window looks a lot
> like Visio.
> https://www.winsim.com/screenshots.html
>
> Writing commercial software requires a lot of code.

This is probably a few decades too late for the interface code, but
have you looked at GTK and its Fortran binding, fortran-gtk?

[Ron Shepard]

On 11/26/22 8:31 AM, FortranFan wrote:
[...]> Are not the higher-end Apple macOS laptops still using Intel

CPUs, as opposed to ARM? In an Enterprise domain like at the
influential customers of WinSim Inc., the users - mostly
process/chemical/petroleum/mechanical engineers, etc. - who have to run
software such as WinSim are still likely to be on higher-end laptops
i.e., Intel CPUs for the foreseeable future.

Apple has been switching to arm64 processors since 2020. During this
switchover period, one could buy new models (meaning fully supported
both software and hardware) with either intel or arm64 CPUs.
Specifically for the high-end MacBook Pros, the last intel model
revision was in the spring of 2021, and since the fall of 2021 all new
models have been based on arm64 hardware. The older intel machines are
still fully supported with software (OS and security updates), old intel
software is fully supported through emulation on the new arm64 hardware,
and they also support "fat binaries" where both sets of instructions
exist within a single program and the correct instruction set is
selected at run time. Apple has made this kind of transition before,
from Motorola 68xxx to PowerPC, and then from PowerPC to intel, and it
all works surprisingly well. This current transition from intel to arm64
is the same. New MacBook Pros are expected to be announced early in 2023
that are based on the latest revision of the arm64 CPUs (M2). Based on
the past history of hardware transitions, Apple is expected to continue
to support the existing intel hardware base for another three to six
years, but there will be no new intel-based Apple hardware manufactured
in the foreseeable future. I still have 20-25 year old PowerPC based
Macintosh computers that run (including IBM fortran compilers), although
Apple support ended for them about 10 years ago.

$.02 -Ron Shepard

[Scott Lurndal]

I would expect that 40 years of updates would have fixed
the problems you note below.

http://gino.co.uk/

[Gary Scott]

Its come a long way in 32 years. I've (combined with my employer) paid
them about $50k to upgrade it in many areas. It started out as output
only, similar to mainframe GDDM. But it now has full interactive
graphics editing ability (including segments and transformations and
attribute modifications for pre-drawn segments). Pretty much full CAD
capability and is integrated with openGL if you choose that driver.
It supports 2D and 3D but I've not had the need for 3D other than
playing so I've not worked through that area of support.

> Lynn
>

[Gary Scott]

I'll also note that they're really nice people and will fix anything you
need fixed. I've found them extremely responsive. Sometimes though a
problem may be hard to reproduce so providing an example helps a lot. A
problem is that it is a pretty huge code base for the size of the
development/support team, but I've had numerous examples of overnight
updates over the years.
>
>> Lynn
>>
>

[Lynn McGuire]

No, that is not the problem.

Thanks,
Lynn

[Mut...@dastardlyhq.com]

On Sat, 26 Nov 2022 13:33:46 -0600

Lynn McGuire <lynnmc...@gmail.com> wrote:
>On 11/26/2022 4:01 AM, Mut...@dastardlyhq.com wrote:
>> On Fri, 25 Nov 2022 13:58:20 -0600
>> Lynn McGuire <lynnmc...@gmail.com> wrote:
>>> Unfortunately, Microsoft does not care about Fortran. They showed that
>>> many years ago when they dropped Powerstation. I do not know why Visual
>>> Studio does not work with Intel Fortran more but it is disappointing.
>>> We use Visual C++ 2015 to build our Windows user interface with 450,000
>>> lines of C++ code. It works extremely well for us even though our code
>>
>> 450K lines just for the interface?? How many windows does it have, a few
>> hundred??
>
>One main diagrammatic window with multiple sheets and about 150 dialogs
>for the users to specify their simulation. The main window looks a lot
>like Visio.
> https://www.winsim.com/screenshots.html

Looks like it was designed in the 90s. I still fail to see how even with
what you've mentioned it can possibly require 450K lines of C++.

>Writing commercial software requires a lot of code.

Not that much for just the interface alone. One commercial windows package
I worked on which was heavily mathematical and had complex graphics in numerous
sub windows was "only" 100K lines.

[Lynn McGuire]

On 11/24/2022 12:05 PM, FortranFan wrote:
> On Wednesday, November 23, 2022 at 6:36:28 PM UTC-5, vie...@gmail.com wrote:
>
>> ..
>> Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?
>
>
> @vie...@gmail.com,
>
> Can you please elaborate on "I stopped that job because I found its nonsense"?
>
> Our experience suggests what OP's pursuit - "converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++" - to be UTTER NONSENSE.
>
> Please note OP is the President and CEO of a commercial software company, WinSim Inc. https://www.winsim.com/staff.html
>
> And the software in question is primarily the *calculation engine* in the area of chemical process simulation in steady-state conditions (d/dt - where t is time - terms in the physical relations starting with the laws of conservation of mass and then energy applied to simulate the chemical processes are not applicable at steady-state). The simulator may have dynamic modes where the PDEs and the ODEs in terms of time become relevant. Anyways, what is stake is heavy-duty number-crunching using arrays of floating-point variables for which Fortran is extremely strong. Moreover there is an extremely rich, powerful, performant, and validated legacy and set of Fortran libraries.

I note that you outed me all over the place. That is very uncool, even
for a guy living in his mother's basement. You have zero credibility in
my opinion when you start up personal attacks like this. What are you, 15 ?

And my software already has dynamic memory usage in it all over the
place for when we converted to sparse matrixes back in 1977 using the
dynosor ( https://dl.acm.org/doi/10.1145/954654.954661 ) technology.
It enabled us to live on the 2 megaword Univac 1108 until 1982. And
then on the 6 megaword IBM 370 until their replacements in the late
1980s. Here is a sample of our code:

IFLBLO = VDY(KPDSP+5) + 0.1
C EQUIPMENT IS ADD/FTN BLOCK IF NECALL BETWEEN 18 AND 35
if (necall .lt. 18 .or. necall .gt. 35 .or. iflblo .ne. 2) then
call amoco (jeqno, nin, nout, ncp, neqp, ndsp, vdy (ivpfr + 1),
* vdy (itemp + 1), vdy (ipres + 1), vdy (ienth + 1),
* vdy (ientr + 1),
* vdy (imole + 1), vdy (icomp + 1), vdy (isikv + 1),
* vdy (ovpfr + 1),
* vdy (otemp + 1), vdy (opres + 1), vdy (oenth + 1),
* vdy (oentr + 1),
* vdy (omole + 1), vdy (ocomp + 1), vdy (osokv + 1),
* vdy (kpeqp+1), vdy (kpdsp+1), vdy (kpscp+2),
* ivdy (kpin + 1).i, ivdy (kpout + 1).i)
else
NBLOCK = NECALL - 17
CALL LINECK(2)
WRITE (OUFILE,61) NBLOCK
61 FORMAT ('0IN-LINE FORTRAN - SIMULATE BLOCK ',I6)
CALL LCBK ('DRCT',NDRCTO,LDRCTO)
call adinlf (jeqno, nblock, ivdy(ndrcto+1).i ,
* nin ,nout ,neqp ,ndsp ,
* ivpfr ,itemp ,ipres ,ienth ,imole ,
* icomp ,isikv ,ovpfr ,otemp ,opres ,
* oenth ,omole ,ocomp ,osokv ,kpeqp ,
* kpdsp,
* ieqp, extnum, eqnam, max_streams_per_equipment,
* equipment_connections, immsav)
end if

No thanks to your advice,
Lynn

[Lynn McGuire]

We abandoned our Gino front end on Vax VMS in 1993 and moved totally to
Windows. We could not support both.

Lynn

[Gary Scott]

GINO has been primarily a windows product since the 80s. Other OS are a
subset in terms of GUI support.

> Lynn
>
>

[Gary Scott]

er...90s.

>> Lynn
>>
>>
>

[FortranFan]

On Monday, November 28, 2022 at 12:50:48 PM UTC-5, Lynn McGuire wrote:

> ..You have zero credibility in

> my opinion when you start up personal attacks like this. What are you, 15 ?
>

> ..

> No thanks to your advice,

@Lynn McGuire,

You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.

I have a lot of stake in the industry you sell into and it is likely that several of my important vendors/suppliers are your unknowing customers. Going by your posts, I really worry what kind of product they might be relying upon. I also wonder of the kind of staff and consultants you hire as the President and CEO of your company that low-level code issues persist like so and that your colleagues let you make such posts online! Your posts would make anyone in the know about chemical process simulations really wonder and worry about the quality of code behind WinSim.

What in the hell you think the code snippet you post with 'call amoco' and 'CALL LCBK' will illustrate, huh? That somehow you managed to use the memory management techniques back in 1977 when there was no Fortran, only nonstandard FORTRAN in actual use and that the `ALLOCATE` statement was yet unavailable, but somehow you have remained stuck there ever since?

Re: "No thanks to your advice" - that much was long clear. Well before I started on this forum around mid-2010s, you received plenty of good advice from many others regarding the use of modern programming techniques in your codes including those from modern Fortran and C++. You seem to have ignored all of it. Put me aside, it appears you have a massive problem generally with accepting any advice. So what are you then, a toddler?

Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.

Instead of worrying about who's living in whose basement and insinuating any mothers, you should ask yourself which gutter of a mindset are you in. You represent an important and crucial industry, especially in the US, but your posts really make WinSim and its code look highly suspect and it casts a long shadow of incompetence on chemical process simulation and the chemical industry also.

[Objexx Engineering]

On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:

> You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.

> ...

> Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.

> ...

A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the oxygen expended!

[Lynn McGuire]

Are you the guy who wanted $75,000 up front plus 5% of my future sales
in perpetuity ?

Lynn

[Objexx Engineering]

On Monday, November 28, 2022 at 10:20:41 PM UTC-5, Lynn McGuire wrote:
> Are you the guy who wanted $75,000 up front plus 5% of my future sales
> in perpetuity ?

Very classy! No, we never take a cut of client sales or any ongoing license costs. I suspect the real issue is that WinSim is not profitable enough for you to afford any outside expertise, ergo the years of floundering and endless posts in multiple forums.

[Thomas Koenig]

Objexx Engineering <obj...@objexx.com> schrieb:

> On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:
>
>> You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
>> ...
>> Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
>> ...
>
> A number of years ago I explained our system for Fortran-to-C++
> conversion to this person that would have provided them with clear,
> validated C++ (instead of the mess that F2C produces) and got a lot
> of (to me nonsensical) "reasons" why that wouldn't meet his needs.

Insulting potential customers is a great way to earn business,
and bad-mouthing people who have consulted and decided not to use
your services is even better.

That will let _anybody_ feel confident about talking to you in
the future. Professional behavior at its finest!

[Objexx Engineering]

I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!

[Lynn McGuire]

On 11/29/2022 1:28 AM, Objexx Engineering wrote:
> I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!

I am sorry that you disagree with me about my methods of getting things
done. I would urge you to killfile me.

I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
/ C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for
$4,000 and thought that I had tested it fairly well. When I started the
translation project about six months or a year later (I live in the
tyranny of the now), I got burned in that it did not handle Fortran data
structures which are extensively used in my F77 source code. In the
meantime, the guy closed his business down. I offered to add the
support myself if he would forward the source code to me but he would
not. So here I am down the road, rolling my own solution since I have
serious trust issues now and very non standard F77 / F66 code.

Lynn

[pehache]

Le 26/11/2022 à 15:31, FortranFan a écrit :
>
>> After all, there is some evidence
>> floating about that Microsoft is getting ready to follow Apple, once
>> more, and jump to the ARM cpus and leave Intel behind.
>

> Are not the higher-end Apple macOS laptops still using Intel CPUs, as opposed to ARM? In an Enterprise domain like at the influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run software such as WinSim are still likely to be on higher-end laptops i.e., Intel CPUs for the foreseeable future.

There are no more intel-based laptop in the Apple catalogue, all of them
have been converted to ARM. There are still 2 desktop models that are
Intel based, including their high end machine, the Mac Pro. But it's
just because they don't have yet the appropriate ARM CPU to put in, and
it's planned for early 2023. At that moment thre wil be no Mac with an
Intel CPU.

The experience show that major software vendors quickly propose a ARM
version to follow the clients, and that it's not a big deal.

As for the Windows world, I don't think ARM CPUs will replace Intel ones
soon. It may happen in some future, but at the very least there will be
a very long period where both architectures will cohabit. The ARM
Windows version has been around for years now, and there are still very
few PCs with an ARM CPU (and almost all of them are on the
ultra-portable segment)

--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2h...@mid.individual.net>

[Robin Vowels]

On Wednesday, November 30, 2022 at 6:26:32 AM UTC+11, Lynn McGuire wrote:
> On 11/29/2022 1:28 AM, Objexx Engineering wrote:
> > I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
> I am sorry that you disagree with me about my methods of getting things
> done. I would urge you to killfile me.
>
> I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
> / C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for
> $4,000 and thought that I had tested it fairly well. When I started the
> translation project about six months or a year later (I live in the
> tyranny of the now), I got burned in that it did not handle Fortran data
> structures which are extensively used in my F77 source code.

F77 didn't have data strctures. That was your mistake. You didn't
really have F77 source.

[Lynn McGuire]

Yup, such is life. I am getting rid of the Fortran data structures in
my C++ port, even though C and C++ natively support structures. F2C
does not handle Fortran data structures in its conversion to C/C++
either. I am also getting rid of my automatic zero initialization and
not converting all local variables to globals.

I am converting all of my integers and logicals to integer*8 as we store
C pointers in them so that is getting us ready for the Win64 port. All
of our data is stored in sparse memory banks which will be kept as I do
have some customer files that are hitting 1 GB in size at runtime. The
sparse arrays and matrices are still needed.

We got rid of the Hollerith characters several years ago. And we added
"implicit none" to our code several years ago. Both of those are
helping significantly in the C++ port.

Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

> I am converting all of my integers and logicals to integer*8 as we store
> C pointers in them so that is getting us ready for the Win64 port.

That sounds very dangerous. This violates the C standard, and
another revision of the optimizers might just break your code.

[Lynn McGuire]

Can you educate me a little bit more please ? How does this violate the
C standard ? The C pointers are currently returned from calls to malloc
and realloc.

Thanks,
Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

Hm, I think I oversimplified.

In the latest draft of the C standard, 6.2.3.2 states

# An integer may be converted to any pointer type. Except as
# previously specified, the result is implementation-defined,
# might not be correctly aligned, might not point to an entity of
# the referenced type, and might be a trap representation.
#
# Any pointer type may be converted to an integer type. Except as
# previously specified, the result is implementation-defined. If the
# result cannot be represented in the integer type, the behavior is
# undefined. The result need not be in the range of values of any
# integer type.

So, if the documentation of yor C compiler tells you that you can
freely convert between some ints and some pointer, you're likely
to get the results you want. You'll be locked to that compiler,
though, but it might just work, unless it doesn't.

But of course, C++ isn't C, and I don't know C++ well enough
to tell you what is dangerous there and what isn't.

As for logicals, that's a can of worms. Old Fortran did not specify
the values for logicals, and different compilers supplied different
interpretations - reading true or false written by one compiler did
not necessarily represent a true or false value in another compiler.

There are at least three conventions: Some compilers use C's
"nonzero is true" convention. Others just test for the least
significant bit. And there is a faction which just allows
for (in representation) 0 and 1, and anything else is undefined,
and liable to break if you test for a .eqv. b where a has the
numerical value of 1 and b of 2.

Soo... not sure what your code actually looks like, but intermixing
logicals with is asking for interesting effects.

[Lynn McGuire]

F2C is converting my logical and logical*8 types to a "long long" in C++
for me. I made some changes to F2C to make this happen. I can easily
change the "long long" to int64_t but I have yet to decide what is best.

In Win64 programs, an int is 4 bytes, a long is 4 bytes, and a long long
is 8 bytes, all signed.

Thanks,
Lynn

[Ron Shepard]

On 11/29/22 1:26 PM, Lynn McGuire wrote:
> So here I am down the road, rolling my own solution since I have serious
> trust issues now and very non standard F77 / F66 code.

That is what we have been telling you for well over a decade here in
c.l.f. You long ago needed to eliminate the nonstandard code in order to
move forward to modern standard fortran and where your code would be
portable to many hardware and software environments. Now apparently that
same nonstandard code is preventing you from automatically converting
your code base to another language.

Back in the pre-f90 days, hardware vendors were also the compiler
vendors. They added nonstandard extensions in order to lock in their
users to their hardware. This was no secret, they did it out in the open
for everyone to see.

I feel your pain regarding your extensive use of those nonstandard
features, which include structures and automatic zero initialization, as
you have told us about many times here. I have used those features
myself on a much smaller scale back in the 1970s, so I know their
appeal. As I understand your situation now, your code only works with a
single fortran compiler and a single operating system. I certainly do
not claim to know what you should do now to dig out of that hole, but I
do hope you succeed with whatever path you choose.

$.02 -Ron Shepard

[gah4]

On Wednesday, November 30, 2022 at 11:45:26 PM UTC-8, Ron Shepard wrote:

(snip)

> I feel your pain regarding your extensive use of those nonstandard
> features, which include structures and automatic zero initialization, as
> you have told us about many times here. I have used those features
> myself on a much smaller scale back in the 1970s, so I know their
> appeal. As I understand your situation now, your code only works with a
> single fortran compiler and a single operating system. I certainly do
> not claim to know what you should do now to dig out of that hole, but I
> do hope you succeed with whatever path you choose.

For problems this size, there is never an easy answer.

It seems that some answers are less helpful, and seem not
to hope for success. Presumably more than one person has
worked on this over the years. Even decisions based on the best
choice at the time, might turn out later to have been wrong.

So, yes, good luck!

[Lynn McGuire]

Around a hundred chemical and mechanical engineers, half of them were
PhD or PhD candidates, were the main programmers since 1965. I have
been meaning to make a list of them some day. I have been working on it
since 1975 to 1982, and 1992 to now.

Over the years it has been ported to a dozen+ platforms: Univac 1108,
CDC 7600, IBM 370 CMS and MVS, Prime OS, IBM AT 370, Vax VMS, Sun OS,
Apollo Domain, IBM 3090, IBM RS 6000, PC DOS 32, Windows Win32s, Windows
Win32. The goal of this port is Windows Win64.

About seven or eight actual software engineers who had actually read the
Dragon book (Principles of Compiler Design). The guy who wrote our
built in Fortran interpreter was a real software engineer, he wrote his
own lex and yacc in Fortran 66 code in 1980-1981. It is not pretty but
it works.

Thanks,
Lynn