Help on Open Watcom Dialog Editor

[Fortransaurus]

Hello:

I'm a newbie user of Open Watcom, and I need help about usage of Open
Watcom Dialog Editor. I searched the web whitout sucess.
My question is: How to program a simple GUI that request some variable
values? How integrate this in a Fortran program that process this
values?

Thanks in advance

[dpb]

W/ difficulty... :)

OW is of an age that essentially predates Win32 and doesn't include the
interface pragma's for the Win32 API prepackaged.

You have to write the callbacks and linkages all manually and build the
pragmas for the API calls you need to call them.

I _believe_ the IDE will generate the barebones winMain code (but I've
not done anything in the IDE recently enough to remember for certainty)
when you request a Win32 app but there's the limit of any help you have
prepackaged, unfortunately.

The closest there is is the "KITCHEN" sample project that is a graphics
Win32 app that does have the necessary pragmas in the .fi files for it
and a functioning winMain w/ menus and graphics interaction but it
doesn't have any other common controls.

Truthfully, if a fullblown Windows app is the target, you're probably
better off with one of several alternative paths than OW F77 alone--

a) if want/need to use OW for a specific reason, write the main in OW
C/C++ that has at least a modicum of support and call the Fortran as
dlls from there to do the computation,

b) go to a supported compiler that has integerated Windows support, or

c) use another form of interlanguage linking to do the GUI and again use
Fortran as a dll for the computation if desired. VB is one, if you know
some of the other scripting languages like Tk/Tcl or perl, they work,
too. (I built a Tk/Tcl GUI around an existing OW F77 character-mode app
that required no changes to the console application other than making
sure to FLUSH the output buffers for the Tcl input to be timely that
processed user inputs and program outputs in the GUI and piped the data
back/forth transparently to the user as an example).

All in all, of the above, I'd recommend the second as the overall better
choice...

--

[dpb]

On 1/20/2012 9:07 AM, dpb wrote:
...

> Truthfully, if a fullblown Windows app is the target, you're probably
> better off with one of several alternative paths than OW F77 alone--

...

> b) go to a supported compiler that has integerated Windows support, or

...

I'll add the following link if this is a "for real" job rather than just
playing or personal...

<http://www.winteracter.com/>

--

[dpb]

On 1/20/2012 9:07 AM, dpb wrote:
...

> Truthfully, if a fullblown Windows app is the target, you're probably
> better off with one of several alternative paths than OW F77 alone--
>

> a) if want/need to use OW for a specific reason,...

One other thought...

Unless there is a solid reason for OW F77, while it is a fine F77
compiler, it is F77 and that is an obsolete Standard that is now some
30+ years out of date.

I would strongly recommend going to one of the other open Fortran
compilers that is still active and includes F95+ features for any new
project or as noted, if this is a paying job, consider a commercial
compiler in the mix as well.

You can still call F77 from F95, but it makes no sense at all in my mind
to restrict new development to lose the new features of the language.

--

[dpb]

On 1/20/2012 9:07 AM, dpb wrote:
...

> I _believe_ the IDE will generate the barebones winMain code (but I've
> not done anything in the IDE recently enough to remember for certainty)
> when you request a Win32 app but there's the limit of any help you have
> prepackaged, unfortunately.

To see if I was right, I just tried (probably for the first time) the
IDE w/ a windowed .exe rather than console app under Win32.

No joy; it creates the write info for the makefile but doesn't add
anything into the source file(s) so there's no help there, either.

--

[Lynn McGuire]

On 1/20/2012 9:07 AM, dpb wrote:

I wrote all our Windows code in C++ and am gradually
converting the rest of the fortran 77 code to C++
also. This is a commercial software package though.

Lynn

[Lynn McGuire]

There is also http://www.wxwidgets.org/ and
http://www.dislin.de/ .

Thanks,
Lynn

[dpb]

On 1/21/2012 2:54 PM, Lynn McGuire wrote:
...

> converting the rest of the fortran 77 code to C++

> also. ...

Once again, my condolences, Lynn... <vbg>

--

[dpb]

On 1/21/2012 2:56 PM, Lynn McGuire wrote:
...

> There is also http://www.wxwidgets.org/ and
> http://www.dislin.de/ .

Are there any Fortran bindings for wxwidgets, Lynn? I didn't look very
hard but didn't notice it listed at the top of the front page.

I hadn't looked for quite a while; I see there is a binding listed for
OW F77 for Dislin.

I'm not sure about Winteractor altho I'm sure they would answer the
question promptly.

I still wouldn't want to start new code limiting myself to F77 (even w/
the Watcom extensions) though.

(I don't do windows (GUIs, anyway :) ) )

--

[dpb]

On 1/20/2012 9:07 AM, dpb wrote:
...

> c) use another form of interlanguage linking to do the GUI and again use
> Fortran as a dll for the computation if desired. VB is one, if you know
> some of the other scripting languages like Tk/Tcl or perl, they work,
> too. (I built a Tk/Tcl GUI around an existing OW F77 character-mode app
> that required no changes to the console application other than making
> sure to FLUSH the output buffers for the Tcl input to be timely that
> processed user inputs and program outputs in the GUI and piped the data
> back/forth transparently to the user as an example).

...

My recent tongue (sorta') in-cheek comment to Lynn made me think I
should comment on the above. What I did above was to demonstrate that
the concept was workable as part of a proposal to a client who was
interested in developing a gui for an interactive toolset of console
applications. There was a change in management and I essentially
retired and returned to the family farm so the full project wasn't
funded--there are several contributors at the comp.lang.fortran ng who
have/do use the technique and I did enough to convince myself it's quite
viable for existing app altho unlikely what I'd choose for new code.
And, I'd hire out the gui part now and concentrate only on the
computation engine since I'm not looking for work... :)

--

[Lynn McGuire]

There used to be an OW F77 binding for wxwidgets.
But it may not have been maintained. It has been
a decade or so since I investigated it.

Lynn

[Lynn McGuire]

On 1/22/2012 8:27 AM, dpb wrote:

BTW, the chief problem in using OW F77 for GUI
programming is that OW F77 does not have an
unsigned integer data type that can be used for
pointer storage. My decision a decade ago was
that a programmer was tempting fate without this
data type.

Lynn

[dpb]

I've never heard of a case where that was an issue w/ the Win32 API w/
any other Fortran compiler, either, though. Unsigned is not a part of
the Fortran Standard w/ any compiler (and I don't believe it's been
added w/ the later Standards either altho I could be wrong there).

Of the issues regarding using the Win32 API from Fortran, this is the
least of the problems I would consider as being a show-stopper--there
are just too many instances where it's being done routinely for it to be
a problem (and there would be too many complaints to vendors if it were
for it to not have a fix).

--

[dpb]

On 1/23/2012 2:10 PM, dpb wrote:
> On 1/23/2012 11:52 AM, Lynn McGuire wrote:

...

>> BTW, the chief problem in using OW F77 for GUI
>> programming is that OW F77 does not have an
>> unsigned integer data type that can be used for
>> pointer storage. My decision a decade ago was
>> that a programmer was tempting fate without this
>> data type.
>
> I've never heard of a case where that was an issue w/ the Win32 API w/
> any other Fortran compiler, either, though. Unsigned is not a part of
> the Fortran Standard w/ any compiler (and I don't believe it's been
> added w/ the later Standards either altho I could be wrong there).

...

I should note that while unsigned integer types have not been
introduced, the F2003 Standard did define an intrinsic module for C
interoperability and a set of intrinsic functions to handle the details
in a Standard-conforming way between compatible compilers.

While there's no absolute guarantee that two randomly chosen C and
Fortran compilers will/can interoperate, there is now a defined source
code compatible syntax for those which can/do interoperate.

In general, what this does is not add any additional functionality that
one couldn't achieve manually by delving into the guts of the two
implementations and using vendor-specific extensions to specify the
details of argument passing, types, name-mangling, etc., etc., but
simply moves it to a source-compatible level and leaves those details to
the compiler implementer to sort out in the compatibility module.

IOW, w/ say OW, it would provide a fixed interface that would be a
wrapper around the necessary pragmas that otherwise would be required to
be manually written or physically included in every source file to do
the same thing.

--

[Lynn McGuire]

We are currently using OW F77s signed integers for
pointer storage and have not gotten burned yet. It
is just a little scary. We do have some old code
that is
if (iptr .gt. 0) then
do some work
end if
that has been changed to
if (iptr .ne. 0) then

But we continually find that we have missed a couple
of if checks. In 700K lines of code, it is not hard.

Lynn

[Lynn McGuire]

We are still working on getting rid of the zero
initialization of our OW F77 code. All the crashes
are gone, now we are working on computational
differences. Do not do this at home ! <g>

Lynn

[dpb]

On 1/25/2012 10:49 AM, Lynn McGuire wrote:
...

> We are currently using OW F77s signed integers for
> pointer storage and have not gotten burned yet. It
> is just a little scary. We do have some old code
> that is
> if (iptr .gt. 0) then
> do some work
> end if
> that has been changed to
> if (iptr .ne. 0) then

Well, the root of the problem there is badly written code to begin with
as opposed to the fundamental problem of having an insurmountable problem.

> But we continually find that we have missed a couple
> of if checks. In 700K lines of code, it is not hard.

Granted, altho one could do a search on the API names instead of the
test and ensure at least seeing all the calls.

--

[dpb]

On 1/25/2012 10:50 AM, Lynn McGuire wrote:
...

> We are still working on getting rid of the zero
> initialization of our OW F77 code. All the crashes
> are gone, now we are working on computational
> differences. Do not do this at home ! <g>

...

That's progress, indeed...

Will Intel compile it yet?

--

[Lynn McGuire]

Not even going to try. Bought a group license
of FOR_C and will be using that next.

Moving to C++ will give us another excellent
benefit, crash tracebacks from our users with
function names and code lines. Our user
interface does this and is wonderful. The code
tracebacks that we get from OW F77 are worthless
after the DLL entry point.

Lynn

[dpb]

On 1/25/2012 5:36 PM, Lynn McGuire wrote:
> On 1/25/2012 11:50 AM, dpb wrote:
>> On 1/25/2012 10:50 AM, Lynn McGuire wrote:
>> ...
>>
>>> We are still working on getting rid of the zero
>>> initialization of our OW F77 code. All the crashes
>>> are gone, now we are working on computational
>>> differences. Do not do this at home ! <g>
>> ...
>>
>> That's progress, indeed...
>>
>> Will Intel compile it yet?
>
> Not even going to try. Bought a group license
> of FOR_C and will be using that next.

That, to me at least, seems a shame to not check it out once you get the
code base cleaned up. I really can't fathom what you can gain from
having auto-generated C code over Fortran for the computational
portions...but, of course, it's not my code.

> Moving to C++ will give us another excellent
> benefit, crash tracebacks from our users with
> function names and code lines. Our user
> interface does this and is wonderful. The code
> tracebacks that we get from OW F77 are worthless
> after the DLL entry point.

Traceback information isn't a function of the language per se; it's a
compiler implementation issue almost entirely. Were these DLL's written
in Fortran and were the production executable(s) generated with the
required traceback code? Also, the level of optimization used can
effect the granularity of traceback significantly and one would presume
that the optimization level is fairly high in production computational
code whereas it may not be significant at all in the UI.

All to say (for the possible future readers of the conversation), don't
confuse compilers and quality of implementation w/ the language--the
ability to have a traceback is more dependent on the former than the
latter by far. And, just in case the OW F77 traceback isn't all it
could be in your particular case if you did what can in the compile/link
step, to defend OW it is at this point 20 years or more since any
serious development has happened and while it was pretty good for the PC
at the time, Fortran and Fortran compilers have moved on since then (as
well as those fore that other language not to be named :) ).

--

[user1]

dpb wrote:
>
> since I'm not looking for work... :)

That family farm you mentioned - enough work there to keep you busy ? <g>

[Lynn McGuire]

Tracebacks in the field are a given feature of
Visual C++. They are immensely helpful as I have
crashes at customers sites go to our website and
automatically tell us that the app is crashing and
where. When one has several thousand customers,
detailed crash reports are a necessity of life.
Otherwise I may get a message, "Uh, your app crashed
while I was using it". Emphasis on the may!

There is more than one reason that we are moving
from F77 to C++. BTW, Intel Visual Fortran may be
a more modern version of fortran than OW F77 but in
my opinion, IVF is not as reliable. I have had too
many weird problems with it and judge any serious
software development with it to be fraught with
danger.

Thanks,
Lynn

[E. S. Fabian]

Lynn McGuire:

| There is more than one reason that we are moving
| from F77 to C++.

Lynn,
the only reason for switching you mentioned is the traceback implementation.
Care to tell us what the other reasons are?
--
Steve

[dpb]

Let's say there's never a lack of stuff to do... :)

--

[dpb]

On 1/26/2012 12:05 PM, Lynn McGuire wrote:
...

> Tracebacks in the field are a given feature of

> Visual C++. They are immensely helpful ...

No argument on the usefulness of a good traceback.

I "know nuthink!" (to quote Sgt Schultz) of current MS Visual C/C++ but
a search on web and the MS and MSDN didn't find me much useful about
what it actually does that's any different than any other compiler--I
couldn't even find a /trace switch in the commandline for the compiler.

All I did find was some information about classes for writing traceback
routines. Can you point me to anything useful, there, Lynn?

I'd like to understand what they're doing that's so different--I don't
see how one can do that unless building traceback information and
keeping debug information in the executable which would seem a
significant performance hit for the guts of what is, as I understand it,
a heavily compute-intensive application. Or do your clients now simply
have so many cpu cycles they don't notice? Or, perhaps you've not yet
gotten any of the C/C++ compute-intense modules out to know?

How does the automated code generation tool deal w/ the row- vis a vis
column-major storage problem between C and Fortran and what that can do
w/ cache on performance?

> There is more than one reason that we are moving
> from F77 to C++. BTW, Intel Visual Fortran may be
> a more modern version of fortran than OW F77 but in
> my opinion, IVF is not as reliable. I have had too
> many weird problems with it and judge any serious
> software development with it to be fraught with
> danger.

Given the issues we've discussed so much in the past in your code, I'm
reluctant to give too much blame to the compiler... :)

I know there are quite a large number of commercial users of the Intel
compiler and that they (Intel, that is) take support of issues very
seriously.

I also recognize there is a natural inclination to distrust anything
that doesn't behave the same on a code base with which one has become
familiar w/ another compiler.

And, that your corporate decision/direction is made but I continue to
wonder from afar if couldn't have managed some time ago to have gotten
somewhere if had had the chance...I've dealt w/ a number of very large,
ugly codes over the years full of machine/compiler dependencies and
never failed in moving them to other platforms.

--

[Lynn McGuire]

My good friend StackWalker has saved our rumps
many times ...
http://www.codeproject.com/Articles/11132/Walking-the-callstack

Dont know on the code generator does it yet but
I'm sure that we will get burned XXX find out
soon. It must be doable because I remember using
f2c on our first unix port (now that was nasty
looking C code but it ran fine !).

I have run into two specific IVF problems where
they had to give me patches to fix really nasty
problems like overflowing the symbol table
(doesn't everyone have 3,000 common blocks ???).
I cannot remember the other problem but it was
fairly nasty also.

Our code has stretched every platform I've been
on. Yup, we are large and ugly.

Lynn

[Lynn McGuire]

Sorry, I've been here before. The decision is
made and we are moving out.

Lynn

[Lynn McGuire]

On 1/25/2012 10:50 AM, Lynn McGuire wrote:

And we are now rid of all our zero initialization
problems. That only took a couple of months ...

Lynn