Opening a file in main program and writing to it in a DLL seems impossible under Windows

[Arjen Markus]

Hello,

we have run into a somewhat awkward problem:
We open a file in the main program and one of the routines in a DLL is
supposed to write to that
same file. However, we find that the file that was opened at a
particular LU-number, is not written to in the
DLL. It seems a common problem under Windows (not specific to a
particular compiler), whereas
under Linux the same file can be written to using the same LU-number.

Here is a small, complete, program that exhibits this behaviour:

--- main program ---
! chklu.f90 --
! Check if a LU_number is attached to the same file in program and
DLL
!
program chklu
implicit none

logical :: opend
character(len=80) :: filename

call openfile( 10, 'chklu.out' )

inquire( 10, opened = opend, name = filename )
write(*,*) 'opened: ', opend
write(*,*) 'name: ', trim(filename)

end program

--- code for the DLL ---
! openfile.f90 --
! Open a file at a specific LU-number
!
subroutine openfile( lu, filename )
implicit none

integer :: lu
character(len=*) :: filename

open( lu, file = filename )

end subroutine

Under Windows:

$ gfortran -o openfile.dll openfile.f90 -shared
$ gfortran -o chklu chklu.f90 openfile.dll
$ chklu

opened: F
name:

Under Linux the program writes:

opened: T
name: chklu.out

(rather as I had hoped for).

I have seen similar behaviour with other compilers.

Is there any way around this (apart from closing and opening the file
again and again)?

Regards,

Arjen

[Jugoslav Dujic]

Arjen Markus wrote:
> Hello,
>
> we have run into a somewhat awkward problem:
> We open a file in the main program and one of the routines in a DLL is
> supposed to write to that
> same file. However, we find that the file that was opened at a
> particular LU-number, is not written to in the
> DLL. It seems a common problem under Windows (not specific to a
> particular compiler), whereas
> under Linux the same file can be written to using the same LU-number.
>
> Here is a small, complete, program that exhibits this behaviour:

Please identify the "particular compiler".

I can tell you how it works in ifort: when you open a LUN, the run-time
library allocates certain resources (file handle, file buffer) and
associates it with the LUN.

If the calling .exe and the called .dll have their distinct copies of
the run-time library, those will be unaware of each other and associate
different resources with the LUN. If you want to share the LUN across
module boundaries, you must link both the .exe and the .dll with dll
version of run-time library (and redistribute it -- libifcoremd.dll).

(Actually, that setting -- /libs:dll is the default when building the
dll, but you must also use it when you build the calling .exe).

(And I don't like unit sharing between modules, because IMO it
beats encapsulation, but that's another issue. Send a file name
to the dll rather than its LUN.)

--
Jugoslav
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.

[Arjen Markus]

I have run into it with gfortran, g95 and CVF on Windows. gfortran,
g95 and Intel Fortran on Linux do not give this particular problem.

Well, we use a DLL in this case, mainly because it allows the user
to add his/her own version of certain aspects of the computation.
The file in question is a report file, so that the user can check
that all is going correctly (or not). I am not sure how one would
comfortably do that via a file _name_, but I agree that this
sharing is not a clean solution either.

Hm, /libs:dll - I could try that.

Regards,

Arjen

[Arjen Markus]

> Arjen- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Marvellous! It works indeed (tested with CVF) - thanks.

Regards,

Arjen

[Jugoslav Dujic]

<snip>

You're welcome.

I'd still prefer CLOSEing the file in the program before calling
the .dll, and then giving the .dll the chance to OPEN it with
POSITION='append'. It's admittedly somewhat slower than having
a single OPEN, but gives a cleaner interface.

An alternative method is to provide a function in a separate
dll which could act as a tracing/callback, e.g.

WriteReportLine(CHARACTER(*) line)

With a little luck, you could even get the .dll and .exe
from different compilers to get together. I suppose it depends
if you're providing end-users an "official" well-documented
plugin interfaces, or just a quick'n'dirty backdoor.

--
Jugoslav