Use of I/O Statements in CVF Fortran Windows Applications
Craig Dedo
I am teaching myself how to write Windows application programs using
CVF 6.6.B.
I would like to know to what extent a programmer can use the regular
Fortran I/O statements (e.g., OPEN, CLOSE, READ, WRITE, etc.) rather
than the corresponding Windows API procedures (e.g., CreateFile(),
CloseHandle(), ReadFile(), and WriteFile()) in Fortran Windows
Application projects. Specifically, I would like the answers to these
questions:
1. Is it possible to use the regular Fortran I/O statements in Fortran
Windows Applications (not QuickWin) instead of or in addition to the
Windows API procedures?
2. If so, what limitations, if any, are there on use of the Fortran I/O
statements?
3. What complications, if any, are there for use in Fortran-only
Windows applications?
4. What complications, if any, are there for use in mixed-language
Windows applications?
5. What interactions are there between using the Common Dialog Boxes
and the Fortran I/O statements?
6. Any other issues?
I have done as much homework as I can. So far, I have not found any
answers to these questions. I have been using these books as teaching
and reference tools:
* Compaq Visual Fortran: A Guide to Creating Windows Applications, by
Norman Lawrence
* Digital Visual Fortran Programmer's Guide, by Michael Etzel and Karen
Dickinson
* Compaq Fortran Language Reference Manual, Sept. 1999, by Compaq
Computer Corp.
FWIW, the example programs for chapter 8 in the Lawrence book use
the Windows API procedures.
Any help would be very much appreciated.
--
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place E-mail: Craig...@execpc.com
Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869
USA Fax Phone: (262) 783-5928
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
(1759)
Jugoslav Dujic
| Dear Readers:
| I am teaching myself how to write Windows application programs using
| CVF 6.6.B.
|
| I would like to know to what extent a programmer can use the regular
| Fortran I/O statements (e.g., OPEN, CLOSE, READ, WRITE, etc.) rather
| than the corresponding Windows API procedures (e.g., CreateFile(),
| CloseHandle(), ReadFile(), and WriteFile()) in Fortran Windows
| Application projects. Specifically, I would like the answers to these
| questions:
|
| 1. Is it possible to use the regular Fortran I/O statements in Fortran
| Windows Applications (not QuickWin) instead of or in addition to the
| Windows API procedures?
Yes. I did a lot of Win32 programming under CVF and I don't recall when
I've last used CreateFile/WriteFile.
| 2. If so, what limitations, if any, are there on use of the Fortran I/O
| statements?
None that I know of. Ah, yes, minor one -- you cannot/shouldn't write to
standard output (write(*)) because there's no console to write to, and
stdout is by default set to NULL in GUI applications. But that's pretty
obvious.
| 3. What complications, if any, are there for use in Fortran-only
| Windows applications?
|
| 4. What complications, if any, are there for use in mixed-language
| Windows applications?
Hmmm... many :-). Could you be more specific?
| 5. What interactions are there between using the Common Dialog Boxes
| and the Fortran I/O statements?
If you mean Open/Save dialog boxes -- none. Open & Save dialog boxes
just let the user pick the name for the file(s) to be opened/saved.
When the dialog is dismissed, you get the file name and/or directory
name that you can use in OPEN statement. As always, take special care of
conversion between C strings (char(0)) terminated and Fortran strings
(fixed-length, blank-padded):
(C->F) fString = cString(1 : index(cString,char(0))-1)
(F-C) cString = TRIM(fString)//char(0)
| 6. Any other issues?
Well... um... many other issues, but you'll find them for yourself.
| I have done as much homework as I can. So far, I have not found any
| answers to these questions. I have been using these books as teaching
| and reference tools:
| * Compaq Visual Fortran: A Guide to Creating Windows Applications, by
| Norman Lawrence
| * Digital Visual Fortran Programmer's Guide, by Michael Etzel and Karen
| Dickinson
| * Compaq Fortran Language Reference Manual, Sept. 1999, by Compaq
| Computer Corp.
Intel/CVF developer forum is located at
http://intel.com/IDS/forums/fortran
IMO that's a huge knowledge base per se, but, being a forum, it's
not quite systematized.
Also, check out my home page below; I hope you'll find some interesting
stuff there.
--
Jugoslav
___________
www.geocities.com/jdujic
Catherine Rees Lay
Dujic <jdujic...@uns.ns.ac.yu> writes
>Craig Dedo wrote:
>| Dear Readers:
>| I am teaching myself how to write Windows application programs using
>| CVF 6.6.B.
>|
>| I would like to know to what extent a programmer can use the regular
>| Fortran I/O statements (e.g., OPEN, CLOSE, READ, WRITE, etc.) rather
>| than the corresponding Windows API procedures (e.g., CreateFile(),
>| CloseHandle(), ReadFile(), and WriteFile()) in Fortran Windows
>| Application projects. Specifically, I would like the answers to these
>| questions:
>|
>| 1. Is it possible to use the regular Fortran I/O statements in Fortran
>| Windows Applications (not QuickWin) instead of or in addition to the
>| Windows API procedures?
>
>Yes. I did a lot of Win32 programming under CVF and I don't recall when
>I've last used CreateFile/WriteFile.
>
days of Windows 3.1 and Microsoft 5.1, which had a ghastly bug with
direct access files in DLLs for Fortran i/o. And the regular Fortran
stuff is standard and portable.
>| 2. If so, what limitations, if any, are there on use of the Fortran I/O
>| statements?
>
>None that I know of. Ah, yes, minor one -- you cannot/shouldn't write to
>standard output (write(*)) because there's no console to write to, and
>stdout is by default set to NULL in GUI applications. But that's pretty
>obvious.
Just to add, you can't mix the regular Fortran statements and the API
procedures in one set of file interactions (i.e. you can't do a Fortran
OPEN then a Windows ReadFile). If you do a Fortran OPEN you need to do
Fortran READs and CLOSE on that file. But there's no reason you couldn't
handle one file with Fortran statements and another with API procedures,
or even the same file but for different instances of opening it (except
severe confusion for the programmer).
>
>| 3. What complications, if any, are there for use in Fortran-only
>| Windows applications?
>|
>| 4. What complications, if any, are there for use in mixed-language
>| Windows applications?
>
>Hmmm... many :-). Could you be more specific?
>
One basic rule much like the above allows you to avoid most of the
complications: don't try to open a file in one language and read from it
in another. Keep your i/o in one language.
Hope this helps,
Catherine.
--
Catherine Rees Lay
To email me, use my first name in front of the "at".
Jugoslav Dujic
| In article <bpcn7n$1lk7qu$1...@ID-106075.news.uni-berlin.de>, Jugoslav
| Dujic <jdujic...@uns.ns.ac.yu> writes
|| Craig Dedo wrote:
||| Dear Readers:
||
|| I've last used CreateFile/WriteFile.
||
| Ditto - I haven't used the API functions in a Windows program since the
| days of Windows 3.1 and Microsoft 5.1, which had a ghastly bug with
| direct access files in DLLs for Fortran i/o. And the regular Fortran
| stuff is standard and portable.
Actually, I do recall now as well -- it was a workaround for FPS 4 bug
related to direct-access files :-).
||| 2. If so, what limitations, if any, are there on use of the Fortran I/O
||| statements?
||
|| None that I know of. Ah, yes, minor one -- you cannot/shouldn't write to
|| standard output (write(*)) because there's no console to write to, and
|| stdout is by default set to NULL in GUI applications. But that's pretty
|| obvious.
|
| Just to add, you can't mix the regular Fortran statements and the API
| procedures in one set of file interactions (i.e. you can't do a Fortran
| OPEN then a Windows ReadFile). If you do a Fortran OPEN you need to do
| Fortran READs and CLOSE on that file. But there's no reason you couldn't
| handle one file with Fortran statements and another with API procedures,
| or even the same file but for different instances of opening it (except
| severe confusion for the programmer).
Somewhat oddly, CVF has some extensions to do even (some parts of) that
(I didn't know either until recently) -- take a look at USEROPEN specifier
in OPEN statement. I didn't use it, but it looks handy for using standard
I/O on non-real-files -- e.g. open a pipe or a serial port in USEROPEN
routine and use it as if it were a standard Fortran file.
--
Jugoslav
___________
www.geocities.com/jdujic
Paul Curtis
functionality, dialogs and so forth, then there really isn't much point
in even considering Fortran i/o. The concept of using a "logical unit"
equating to some quaint physical device such as a lineprinter or a tape
drive or a character-based display terminal simply doesn't carry over
into Windows. And besides, the Win32 functions are so much more
powerful and easier to use. The Win32 file i/o functions, in
particular, allow you to read/write a specified byte count between a
file -- with arbitrary byte position -- and any memory location (ie,
your data structure), much easier, faster and infinitely more versatile
than the antiquated Fortran record-based i/o. Screen output is
accomplished by first WRITEing to an internal file (ie, character
buffer), which is then null-terminated and used as an argument to a
Win32 output function which causes the text to appear on the screen or
in a control field. The overall answer to your questions is that native
Fortran i/o and Win32 output have almost no overlap. Unfortunately,
Norman's book is poorly written and does not provide much useful
information on how Win32 apps are constructed with CVF.
You can learn Win32 programming the same way thousands of others have:
by reading first Petzold, and then Richter. Even though these books are
written for C programmers, the Win32 fundamentals are independent of
language, and the CVF examples then start to make sense (although they
too are inconsistently written and poorly organized).
Send an email if you'd like some pointers or examples on accomplishing
specific tasks.
Jan C. Vorbrüggen
> (I didn't know either until recently) -- take a look at USEROPEN specifier
> in OPEN statement.
Given that USEROPEN was invented for the VMS Fortran compiler for some
of these purposes (e.g., to set initial file allocation and extension),
and that the WNT kernel is based on an early version of VMS, not much
of a surprise.
Jan
Jugoslav Dujic
| And besides, the Win32 functions are so much more
| powerful and easier to use.
Uh-oh. Easier to use? Your mileage may vary, but I don't see what's
so easy in having only a raw bytestream which you should interpret.
With binary files, it's more or less the same thing, but slight
complications arose with direct-access, and when it comes to ASCII,
I don't see anything that beats Fortran I/O in sense of simplicity
of use.
| The Win32 file i/o functions, in
| particular, allow you to read/write a specified byte count between a
| file -- with arbitrary byte position -- and any memory location (ie,
| your data structure), much easier, faster and infinitely more versatile
| than the antiquated Fortran record-based i/o.
Of course, working on lower level always provide more power. But I
don't think that using pure APIs are significantly faster than Fortran RTL
(which is based on native APIs anyway). Formatted files are inherently
slow, but not due to disk access, but to necessary conversions
back&forth.
If you need something like "direct-access-file-with-variable-length-records",
i.e. to access arbitrary positions in the file, then I'd certainly go for
native APIs, but I don't think it's a common requirement.
--
Jugoslav
___________
www.geocities.com/jdujic
G.F. Thomas
"Jugoslav Dujic" <jdujic...@uns.ns.ac.yu> wrote in message
news:bpdhsk$1n1mhp$1...@ID-106075.news.uni-berlin.de...
[...]
>
> Somewhat oddly, CVF has some extensions to do even (some parts of)
that
> (I didn't know either until recently) -- take a look at USEROPEN
specifier
> in OPEN statement. I didn't use it, but it looks handy for using
standard
routine and use it as if it were a standard Fortran file.
>
The USEROPEN extension was introduced by Digital in their Fortran
compilers for VMS and Unix. It wasn't available in Microsoft FPS 16/32.
When Digital released DVF on Windows NT, the extension
appeared and that was a good thing.
I second your advise that Fortran I/O be used in preference to native
API for obvious reasons.
--
Ciao,
Gerry T.