Fortran subroutine interfacing with MS-C call 
Author Message
 Fortran subroutine interfacing with MS-C call


Quote:



> > Topic "About fortran Subprograms"  has again raised the subject of C
> interfacing..
> > which reminds me of my topic of 2 years back when I threw out the
> following statement:

> >  sub1(a,b,&c);    ( the routine is to return the real sum a+b in c )

> > I challenged the newsgroup to write a Fortran subroutine that could
> interface with above MS-C
> > subroutine call.

> (snip)

> My belief is that the C code should adapt to the Fortran, not the other way
> around.

> -- glen

You seriously expect originators of released C code to go back and adapt to Fortran compatible
interfacing?
If as I suspect, you are a user of  IBM PL/I for Windows, how would you translate one of the Fortran
interfaces to WinInet API functions using PL/I ( see: F90 source below) ?
I suspect this is yet another of my examples of Fortran that you guys over in comp.lang.pl1 cant
translate
(altho the PL/I FAQ proudly claims its MORE POWERFUL than Fortran)..

      http://www.*-*-*.com/

      http://www.*-*-*.com/

ALL are invited to try my new utility getfile.exe at above link, and let me know problems
encountered.
AND non-CVF users are challenged to generate a version of getfile.f90 for their compiler.



Thu, 23 Jun 2005 17:27:32 GMT  
 Fortran subroutine interfacing with MS-C call
To anyone encountering heartburn trying to adapt my CVF GETFILE.F90 source to their compiler
with its 1 remaining CVF   !DEC$ OBJCOMMENT LIB: 'WinInet.lib' statement, and explicit interfaces,
I provide a 2nd version without them, with  a USE WININET statement replacing them.

see:       http://home.cfl.rr.com/davegemini/getfile2.f90

Soo, can Lahey, Salford, etc compilers for Windows compilers, now compile/execute this revised source?
If not, why not?



Fri, 24 Jun 2005 16:40:57 GMT  
 Fortran subroutine interfacing with MS-C call

Quote:

> To anyone encountering heartburn trying to adapt my CVF GETFILE.F90 source to their compiler
> with its 1 remaining CVF   !DEC$ OBJCOMMENT LIB: 'WinInet.lib' statement, and explicit interfaces,
> I provide a 2nd version without them, with  a USE WININET statement replacing them.

> see:       http://home.cfl.rr.com/davegemini/getfile2.f90

> Soo, can Lahey, Salford, etc compilers for Windows compilers, now compile/execute this revised source?
> If not, why not?

For Lahey F95 v5.5 with original Getfile source- yes with required
changes to winapi declarations/calls. Problems encountered:
rewrite Interface (remove [Reference]s, declare string arguments as
integer);
change parameters in #n form to z'n' form;
use "getcl" cmd line extension;
winapi calls with carg/carg(offset) as appropriate. Pass Null strings
as carg('') (no need for null ptr).

The above was simple and expected on first viewing of the code. More
serious was a problem with the standard Fortran part of the code. Fmt
91 raised a runtime error (invalid edit descriptor) with the line
"READ (*,91) sUrl". Changed fmt 91 to "A" and new fmt 92 with "A,I0"
and used this with the line "'GETFILE: SUCCESS #bytes =
',nTotalBytes". Who's got the correct syntax here.

Gordon.



Mon, 27 Jun 2005 08:11:05 GMT  
 Fortran subroutine interfacing with MS-C call



Quote:
> > To anyone encountering heartburn trying to adapt my CVF GETFILE.F90 source to their compiler
> > with its 1 remaining CVF   !DEC$ OBJCOMMENT LIB: 'WinInet.lib' statement, and explicit interfaces,
> > I provide a 2nd version without them, with  a USE WININET statement replacing them.

> > see:       http://home.cfl.rr.com/davegemini/getfile2.f90

> > Soo, can Lahey, Salford, etc compilers for Windows compilers, now compile/execute this revised source?
> > If not, why not?

> For Lahey F95 v5.5 with original Getfile source- yes with required
> changes to winapi declarations/calls. Problems encountered:
> rewrite Interface (remove [Reference]s, declare string arguments as
> integer);
> change parameters in #n form to z'n' form;
> use "getcl" cmd line extension;
> winapi calls with carg/carg(offset) as appropriate. Pass Null strings
> as carg('') (no need for null ptr).

> The above was simple and expected on first viewing of the code. More
> serious was a problem with the standard Fortran part of the code. Fmt
> 91 raised a runtime error (invalid edit descriptor) with the line
> "READ (*,91) sUrl". Changed fmt 91 to "A" and new fmt 92 with "A,I0"
> and used this with the line "'GETFILE: SUCCESS #bytes =
> ',nTotalBytes". Who's got the correct syntax here.

> Gordon.



Tue, 28 Jun 2005 16:00:24 GMT  
 Fortran subroutine interfacing with MS-C call



Quote:
> > To anyone encountering heartburn trying to adapt my CVF GETFILE.F90 source to their compiler
> > with its 1 remaining CVF   !DEC$ OBJCOMMENT LIB: 'WinInet.lib' statement, and explicit interfaces,
> > I provide a 2nd version without them, with  a USE WININET statement replacing them.

> > see:       http://home.cfl.rr.com/davegemini/getfile2.f90

> > Soo, can Lahey, Salford, etc compilers for Windows compilers, now compile/execute this revised source?
> > If not, why not?

> For Lahey F95 v5.5 with original Getfile source- yes with required
> changes to winapi declarations/calls. Problems encountered:
> rewrite Interface (remove [Reference]s, declare string arguments as
> integer);
> change parameters in #n form to z'n' form;
> use "getcl" cmd line extension;
> winapi calls with carg/carg(offset) as appropriate. Pass Null strings
> as carg('') (no need for null ptr).

> The above was simple and expected on first viewing of the code. More
> serious was a problem with the standard Fortran part of the code. Fmt
> 91 raised a runtime error (invalid edit descriptor) with the line
> "READ (*,91) sUrl". Changed fmt 91 to "A" and new fmt 92 with "A,I0"
> and used this with the line "'GETFILE: SUCCESS #bytes =
> ',nTotalBytes". Who's got the correct syntax here.

> Gordon.

Above is a response to a message I deleted within 15 minutes of posting, where I screwed up thinking I could
eliminate the explicit interfacing of the 4 wininet api functions without providing a Wininet.MOD file to help
non-CVF
user  to replace explicit interfacing.  (I had one of these critters in my test directory and its presence
mislead me
in thinking I could eliminate the explicit interfacing)

Knowing my message deletion would not stop some readers from seeing it,  I explained what happened in a
comment
I added to a revised getfile2.f90 replacing the original getfile2 immediately after I found out about my
misconception asking readers to ignore my message you quote above, the
http://home.cfl.rr.com/davegemini/getfile2.f90   file will now be removed.

OK, back to the challenge...
The original getfile file is what I'm asking non-CVF users to try revising
http://home.cfl.rr.com/davegemini/getfile.f90

You dont explain how Lahey accommodated the alias name changes, or the stack arg reversal.
How about posting a snip from your revised getfile showing 1 or more of your explicit interfaces?
It might be educational to see how many of your revisions are acceptable to CVF.

As to
READ (*,91) sUrl
91 FORMAT (A,I0)
producing a Lahey runtime error,  thats very strange, it should not be even looking at I0 in this use..

BUT of course the acid test is whether your revision produces a exe that works, I assume it did?

I note that my message to Salford rep? Catherine Rees Lay in topic "Does F2K eliminate need for CVF's !DEC$"
asking whether getfile.f90 can be revised for use by Salford FTN95 has drawn no reply as yet..



Tue, 28 Jun 2005 16:54:52 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Fortran subroutine interface with MS-C call

2. MS FORTRAN subroutines for calling/connecting the mouse

3. MS Fortran DLL called from MS VB 6.0 problem

4. Can you call F77 subroutines from MS Excel?

5. MS Fortran PowerStation and "getarg" subroutine

6. help linking msvc and ms-fortran 5.1 subroutine

7. passing dynamic arrays to subroutines in MS Fortran

8. Weird problem interfacing C and Fortran subroutines

9. Help: how to call a c subroutine in a fortran program

10. How do you call FORTRAN subroutines?

11. Calling IMSL Subroutines in Digital Visual Fortran

12. C call, in a Fortran subroutine, within a C main program

 

 
Powered by phpBB® Forum Software