Open, Write, & Read in WIN32 program

[ahasan]

Are there any restrictionproblemsugs for using Open, Write, and Read statements in a Fortran WIN32 program. More specifically, I would like to use theB edit descriptor toRead and Writefloating point numbersto direct access binary files.

I remember reading somewhere that there may be some restrictions/problems doing this, but can't remember where Isaw that, or maybe my memory is incorrect!

Thanks for any information.

[Jugoslav_Dujic]

There are no restrictions whatsoever, except that Win32 applications do not have a console by default, so WRITE(*) and READ(*) won't work unless the console is created via AllocConsole or I/O redirected via SetStdHandle.

Jugoslav

[Paul_Curtis]

Well, if you plan on writing/using code in a Windows environment for any length of time, you might consider using Win32 file API calls instead of native Fortran. Doing so makes your code Win32-specific and thus not portable, but the performance is MUCH better than any native Fortran i/o, and from a programming point of view, especially if you plan on extensive binary i/o, much more convenient and "natural". Basically, you can set a file pointer to any byte offset within a file, and read/write from/to any structure in memory, eg,

INTEGER

, PARAMETER :: npoints = some_large_number

REAL, DIMENSION(npoints) :: myarray

! get the data from a saved file (using Win32 functions in module)

ihandl = open_the_file ("c:data emparray.dat"//CHAR(0), 'R')

IF (ihandl > 0) THEN

CALL rw_file ('R', ihandl, npoints*SIZEOF(myarray(1)), LOC(myarray(1)))

CALL close_file (ihandl)

END IF

The att. module provides the details.

[Paul_Curtis]

Second try for attachment...

[ahasan]

Thanks for the replies, and I will take a good look at the example code. Probably have some additional questions. Again, thanks.

[Jugoslav_Dujic]

Paul, could you provide some benchmarking/samples to prove your point? I don'tthink that there would be asignificant overhead of Fortran I/O library comparedto native API calls, but I'm open-minded if you could prove otherwise. (Of course, if you measure only binary or unformatted files -- formatted ones have inherent overhead).

Jugoslav

[ahasan]

Paul, I did look at your sample code then wrote a simple program to write and read one real number using WriteFile and ReadFile. Very straight forward, just point at the real variable and write 4 bytes.

JugoSlavDujic and Paul, I noticed that theFortram Write statementusing the B edit descriptor appears to convert areal number into 32 ASCI 1s and Os (using Notepad to look at the file) rather than simply writing 4 bytes of binary to the file. So it takes 32 bytes to represent a real number rather than 4. Is this correct or am I missing something. Thanks!

[Steven_L_Intel1]

That is correct - that's what formatted output does. Formatted output is always going to be slower than direct binary writes, as conversion is done. You can use A format with formatted if you want to just copy bits of a numeric, but you will have difficulty reading such files with formatted I/O as certain numbers will be misinterpreted as record delimiters.

Use FORM='UNFORMATTED' or FORM='BINARY' for binary I/O. (The latter has no record structure.)

[ahasan]

Steve, thank youfor the info.