Win32 API and gfortran
James Van Buskirk
C:\gfortran\test>type hello.f90
! hello.f90
module mykinds
implicit none
integer, parameter :: ik4 = selected_int_kind(9)
integer, parameter :: ik8 = selected_int_kind(18)
end module mykinds
module Win32
use mykinds
implicit none
private
public GetStdHandle
interface
function GetStdHandle(nStdHandle) bind(C,name='GetStdHandle')
use mykinds
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T) GetStdHandle
integer(C_LONG), VALUE :: nStdHandle
end function GetStdHandle
end interface
public WriteConsoleA
interface
function WriteConsoleA(hConsoleOutput,lpBuffer, &
nNumberOfCharsToWrite,lpNumberOfCharsWritten, &
lpReserved) bind(C,name='WriteConsoleA')
use mykinds
use ISO_C_BINDING
implicit none
integer(C_LONG) WriteConsoleA
integer(C_INTPTR_T), VALUE :: hConsoleOutput
character(kind=C_CHAR) lpBuffer*(1)
integer(C_LONG), VALUE :: nNumberOfCharsToWrite
integer(C_LONG) lpNumberOfCharsWritten
integer(C_INTPTR_T) lpReserved
end function WriteConsoleA
end interface
end module Win32
program hello
use mykinds
use Win32
use ISO_C_BINDING
implicit none
integer(C_LONG) nStdHandle
integer(C_INTPTR_T) hConsoleOutput
integer(C_LONG) status
character(80) Buffer
integer(C_LONG) nNumberOfCharsToWrite
integer(C_LONG) NumberOfCharsWritten
integer(C_INTPTR_T) Reserved
nStdHandle = -11
hConsoleOutput = GetStdHandle(nStdHandle)
Buffer = 'Hello, world!'//achar(13)//achar(10)
nNumberOfCharsToWrite = len_trim(Buffer)
Reserved = 0
status = WriteConsoleA(hConsoleOutput,Buffer, &
nNumberOfCharsToWrite,NumberOfCharsWritten, &
Reserved)
end program hello
C:\gfortran\test>gfortran
hello.f90 -lkernel32 -mrtd -enable-stdcall-fixup -ohel
lo
C:\DOCUME~1\James\LOCALS~1\Temp/ccOusTVl.o:hello.f90:(.text+0x26): undefined
ref
erence to `GetStdHandle'
C:\DOCUME~1\James\LOCALS~1\Temp/ccOusTVl.o:hello.f90:(.text+0x8f): undefined
ref
erence to `WriteConsoleA'
collect2: ld returned 1 exit status
C:\gfortran\test>gfortran --v
Using built-in specs.
Target: i386-pc-mingw32
Configured with:
../trunk/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --dis
able-werror --enable-bootstrap --enable-threads --disable-nls --build=i386-pc-mi
ngw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.3.0 20071017 (experimental) [trunk revision 129419] (GCC)
The issue is that the name of a Win32 API function can't be converted
into the name ld.exe likes, except for a small number of functions
such as GetModuleHandleA, ExitProcess, and Sleep. In 64-bit gfortran
this is not a problem because the name-mangling issue is not present
there. In g95 it's possible to work around this issue by appending
the @n suffix to the name. In 32-bit gfortran, however, the compiler
doesn't permit the @n suffix, complaining that it's a bad C name or
something with ICE soon to follow.
There was a thread on this subject in the gfortran mailing list and
one of the suggestions was to take it to c.l.f., so here we are.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Steve Lionel
> The issue is that the name of a Win32 API function can't be converted
> into the name ld.exe likes,
The problem is bigger than that. All Win32 API routines on 32-bit
Windows use the STDCALL calling mechanism, which has a naming
convention adding the @n at the end of the name to signify the number
of bytes to pop off the stack on return. gfortran, like most Fortran
compilers on Windows (except for CVF and MSFPS) default to the C
convention. If you call a STDCALL routine but the compiler thinks it
is a C routine, the stack gets popped twice and you corrupt the
stack. Things go downhill from there.
You will have to see what gfortran offers for specifying that an
external routine is STDCALL. Whatever it is, it's going to be an
extension and probably not part of BIND. In Intel Fortran, for
example, one uses !DEC$ ATTRIBUTES STDCALL :: routinename
Never, ever attempt to paper over the naming convention difference by
simply adding the @n suffix - the errors this will cause can be
mystifying.
Steve
alexzenk
> There seems to be a problem with Win32 API and 32-bit gfortran.
>
Call Win32 API from gfortran is possible, but for this you should
write for each used Win32 API functions interface subroutine on C.
In consequence of significant difficulties of the mixed programming
for Windows, such approach impractical. Writing of the whole program
on C will probably more simply.
Here is example such working program
---------------File myfirst1.f95------------------------------------
SUBROUTINE FortranSub()
integer i, j
CHARACTER(LEN = 15):: Text
CHARACTER(LEN = 15) :: Caption
i = 0
j = 0
Text = "Hello All"//CHAR(0)
Caption = "gfortran"//CHAR(0)
CALL MBox(i, j, Caption, Text)
END SUBROUTINE FortranSub
--------------File
csub.c----------------------------------------------
#include <windows.h>
#include <stdio.h>
void fortransub_();
void mbox_(int *hWnd, long int *uTape, char *lpCaption, char *lpText);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
fortransub_();
return 0;
}
void mbox_(int *hWnd, long int *uTape, char *lpCaption, char *lpText)
{
MessageBox(*hWnd, lpText, lpCaption, *uTape);
}
_____________________________________________________________________________
------------ .bat
file--------------------------------------------------
path=D:\gfortran\bin
set C_INCLUDE_PATH = D:\gfortran\include
set LIBRARY_PATH=D:\gfortran\lib
gfortran -c myfirst1.f95
gcc -I D:\gfortran\include -c csub.c
gcc myfirst1.o csub.o -o D:/gfortran/Output/myfirst1.exe -mwindows
echo off
if errorlevel 1 goto osh
echo TERMINATED WITH CODE 0
goto con
:osh
echo TERMINATED WITH CODE 1
:con
PAUSE
___________________________________________________________________________
Alex
Gary Scott
> On Nov 10, 7:35 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
>
>>There seems to be a problem with Win32 API and 32-bit gfortran.
>>
>
>
> Call Win32 API from gfortran is possible, but for this you should
> write for each used Win32 API functions interface subroutine on C.
> In consequence of significant difficulties of the mixed programming
> for Windows, such approach impractical. Writing of the whole program
> on C will probably more simply.
Not an acceptable solution. A compiler targeted at a specific OS MUST
be able to directly call OS APIs. I will never ever use a compiler
which does not support this.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
e p chandler
One of your problems is that WriteConsoleA seems not to be there at
all.
Replacing WriteConsoleA with WriteFile in your source code and
compiling with g95 gives
C:\Users\epc\temp>g95 -mrtd hello.f95 -ohello
Warning: resolving _WriteFile by linking to _WriteFile@20
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _GetStdHandle by linking to _GetStdHandle@4
C:\Users\epc\temp>hello
Hello, world!
I can't make any sense of adding --enable-stdcall-fixup or --add-
stdcall-alias in EITHER g95 OR gfortran whether as command line
options or as linker options (-wl,......).
In response to Steve Lionel, -mrtd is bit of magic that changes the
calling convention to stdcall, but it does not take care of the name
mangling required by the Win32 API.
-- e-mail: epc8 at juno dot com
James Van Buskirk
news:1194701088.5...@22g2000hsm.googlegroups.com...
> Never, ever attempt to paper over the naming convention difference by
> simply adding the @n suffix - the errors this will cause can be
> mystifying.
You mean kind of like
http://softwarecommunity.intel.com/isn/Community/en-US/forums/post/30242397.aspx
?
(Sorry, couldn't resist)
James Van Buskirk
news:1194716385.7...@o80g2000hse.googlegroups.com...
> One of your problems is that WriteConsoleA seems not to be there at
> all.
> Replacing WriteConsoleA with WriteFile in your source code and
> compiling with g95 gives
Well, I find the string 'WriteConsoleA' 5 times each in:
C:\g95\lib\libkernel32.a
C:\gfortran\lib\libkernel32.a
C:\gfortran\win64\x86_64-pc-mingw32\lib\libkernel32.a
so I don't think that's the problem. Doing the g95 thing with @n:
C:\g95\test>type hello.f90
! hello.f90
module mykinds
implicit none
integer, parameter :: ik4 = selected_int_kind(9)
integer, parameter :: ik8 = selected_int_kind(18)
end module mykinds
module Win32
use mykinds
implicit none
private
public GetStdHandle
interface
function GetStdHandle(nStdHandle) bind(C,name='GetStdHandle')
use mykinds
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T) GetStdHandle
integer(C_LONG), VALUE :: nStdHandle
end function GetStdHandle
end interface
public WriteConsoleA
interface
function WriteConsoleA(hConsoleOutput,lpBuffer, &
nNumberOfCharsToWrite,lpNumberOfCharsWritten, &
lpReserved) bind(C,name='WriteConsoleA@20')
C:\g95\test>g95 hello.f90 -mrtd -lkernel32 -enable-stdcall-fixup -ohello
C:\g95\test>hello
Hello, world!
C:\g95\test>g95 -v
Using built-in specs.
Target:
Configured with:
/src/G95/gcc-4.1.2/configure --prefix=/mingw --enable-languages
=c --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --host=i386-pc-mingw32 --enab
le-threads --disable-nls --disable-win32-registry --enable-sjlj-exceptions --ena
ble-libgcj --without-x
Thread model: win32
gcc version 4.1.2 (g95 0.91!) Nov 7 2007
Steve Lionel
> "Steve Lionel" <steve.lio...@intel.com> wrote in message
>
> news:1194701088.5...@22g2000hsm.googlegroups.com...
>
> > Never, ever attempt to paper over the naming convention difference by
> > simply adding the @n suffix - the errors this will cause can be
> > mystifying.
>
> You mean kind of like
>
>
> ?
No, as a matter of fact. The post you link to relates to incorrect
name decoration for a C-convention routine, where the compiler ought
to be supplying a leading underscore but doesn't. There it's just the
name that's wrong. If you want to read an Intel forum thread that IS
relevant, see http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30243178.aspx
It looks like some background would be helpful. On 32-bit Windows,
there are two calling conventions, C and STDCALL. They differ in one
way only - who pops the arguments off the stack. With the C
convention, the caller does this after the called routine returns,
whereas with STDCALL, the called routine does this at exit (using a
variant of the RET instruction that also adds to the ESP register
(stack pointer.)) STDCALL is a tiny bit faster, but requires that you
always call the routine with the same number of arguments pushed on
the stack. All Win32 API routines are STDCALL, and calls out of
Visual BASIC, Excel, etc. always use STDCALL.
Because it is critical that the caller and callee agree on the number
of arguments (actually, number of bytes pushed on the stack),
Microsoft created a naming convention for STDCALL routines where the
@n suffix is added. The value of n is the number of bytes expected to
be pushed and popped on the stack. The idea is that if there is a
mismatch, the linker will complain of an undefined reference. It also
allows you to create variants of a routine expecting different numbers
of arguments, each will have a different @n suffix.
You want to call some Win32 API routines from Fortran. These are
STDCALL routines and their global symbols have the @n suffix.
Compilers which support STDCALL will automatically add the proper @n
based on the number and type of arguments the routine expects. This
information can be provided in an explicit interface, or just from the
argument list of a call. If the compiler's default is to use the C
convention, as is the case for gfortran, Intel Fortran, MSVC and
others, you have to have some way to let the compiler know to use
STDCALL instead. In most cases, the compilers have a command line
switch that will change the default for all calls, but most also have
some sort of syntax that lets you specify this on a per-routine
basis. In MSVC, it's the __STDCALL prefix, in Intel Fortran it's !DEC
$ ATTRIBUTES STDCALL.
You attempted to use BIND(C) to declare the Win32 API routine, but
because gfortran assumes the C convention, it properly does not add
the @n suffix. If you try to "paper over" this by manually adding the
@n (which you say gfortran doesn't let you do but g95 does), then you
have circumvented the protection put in place to prevent stack
corruption in your application. You may not notice it, or you may get
unpredictable results somewhere down the road after the call returns.
What you need to do is find a way to get the compiler to use STDCALL
to call this routine and make sure the case of the external name is
right, You may not be able to accomplish this entirely with BIND(C) -
you can't in IVF, for example - there you must also use ATTRIBUTES
STDCALL. I don't know enough about gfortran to advise you there. If
in fact gfortran can't do this, then you should probably choose a
different compiler.
Of course, with IVF, many thousands of Win32 API routines come
predeclared in modules shipped with the compiler, so you don't have to
worry about this.
As you wrote in your original post, this issue does not arise on 64-
bit Windows, where there is only one calling convention that is more C-
like, and hence there is no @n name suffix. (There is also no leading
underscore.)
Steve
e p chandler
> "e p chandler" <e...@juno.com> wrote in messagenews:1194716385.7...@o80g2000hse.googlegroups.com...
OK it works. Please explain why 'GetStdHandle' is not decorated with
@4 yet 'WriteConsoleA@20' is decorated.
When I compile your program with
C:\Users\epc\temp>g95 hello.f90 -mrtd -lkernel32 -ohello
Warning: resolving _GetStdHandle by linking to _GetStdHandle@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
I get
C:\Users\epc\temp>hello
Hello, world!
But if I remove the @20 from the program and compile hello_x.f90 with
or without -enable-stdcall-fixup I get
C:\Users\epc\temp>g95 hello_x.f90 -mrtd -lkernel32 -ohello
Warning: resolving _GetStdHandle by linking to _GetStdHandle@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
./cc6BfmLt.o:hello_x.f90:(.text+0x6a): undefined reference to
`WriteConsoleA'
C:\Users\epc\temp>g95 hello_x.f90 -mrtd -lkernel32 -enable-stdcall-
fixup -ohello
./ccAanPIc.o:hello_x.f90:(.text+0x6a): undefined reference to
`WriteConsoleA'
Finally, when I decorate both with 'WriteConsoleA@20' and
'GetStdHandle@4'
C:\Users\epc\temp>g95 hello_z.f90 -mrtd -lkernel32 -ohello
C:\Users\epc\temp>hello
Hello, world!
It appears that GetStdHandle and WriteConsoleA are two different kinds
of critter.
James Van Buskirk
Umm... the -mrdt switch causes gfortran and g95 to use the STDCALL
convention. The equivalent on ifort would be /iface:stdcall. Does
the code from the seminal post of this thread compile on the current
version of ifort with this switch? Or for that matter
http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin.f90 ?
So I think the parallel with the post I mentioned is quite strong:
both codes should have worked without doing the name-mangling by
hand but failed due to compiler shortcomings. I examined some
disassemblies just to make sure, and in fact the caller was not
popping the stack when the -mrtd switch was in effect.
Steve Lionel
> Umm... the -mrdt switch causes gfortran and g95 to use the STDCALL
> convention. The equivalent on ifort would be /iface:stdcall. Does
> the code from the seminal post of this thread compile on the current
> version of ifort with this switch? Or for that matterhttp://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin.f90?
>
> So I think the parallel with the post I mentioned is quite strong:
> both codes should have worked without doing the name-mangling by
> hand but failed due to compiler shortcomings. I examined some
> disassemblies just to make sure, and in fact the caller was not
> popping the stack when the -mrtd switch was in effect.
I now see that you used the -mrtd switch for gfortran. I did not
recognize that earlier. Given that, I would say that gfortran should
have decorated the name on its own the way a C compiler would have if
a similar option was used (such as MSVC's /Gm). That you can't
explicitly specify the @n suffix is another issue, but I maintain that
the BIND name is not the proper place for that.
IVF, at present, will compile but not link your original source. A
bug was introduced, well-intentioned but incorrect, that removed the
automatic name decoration for BIND names. That will be fixed in the
next update. With that fix, and using /iface:stdref, the proper name
is used for GetStdHandle and the stack is handled properly.
Regarding WriteConsoleA, there is the interesting issue that the
compiler wants to pass a hidden length parameter for the character
argument. I don't think that's correct and will talk to the team
about that. If I add the appropriate attributes to disable the length,
then it works.
Steve
James Van Buskirk
> I now see that you used the -mrtd switch for gfortran. I did not
> recognize that earlier. Given that, I would say that gfortran should
> have decorated the name on its own the way a C compiler would have if
> a similar option was used (such as MSVC's /Gm). That you can't
> explicitly specify the @n suffix is another issue, but I maintain that
> the BIND name is not the proper place for that.
I guess the gfortran folks had a thread about this:
http://gcc.gnu.org/ml/fortran/2007-03/msg00162.html
At the end it seemed that the recommendation was to use -mrdt -S
and then use some kind of text-processing tool to mangle the names,
then assemble and link. You attitude appears rather more user-
oriented than that, and it's a pity that your enlightenment isn't
a bit more contagious.
I don't like the workaround of putting the @n stuff in the BIND name
either, since it would seem to limit portability to x64, where the
code was originally written and works (with gfortran).
> IVF, at present, will compile but not link your original source. A
> bug was introduced, well-intentioned but incorrect, that removed the
> automatic name decoration for BIND names. That will be fixed in the
> next update. With that fix, and using /iface:stdref, the proper name
> is used for GetStdHandle and the stack is handled properly.
Cool. I see that you are using the /iface:stdref switch whereas in
my search I stopped when I saw the /iface:stdcall switch only. It
does look like /iface:stdref is more consistent with Fortran norms,
but in the case of BIND(C) procedures everything is specified in
the interface so for these procedures the two switches should be
indistinguishable, am I right? The reason I ask is because one could
write out a module containing only interface blocks and compile the
module with a switch -mrtd -magic-names :) or /iface:stdcall and then
any program unit that USEs the module would know to call procedures
whose interfaces were described in that module to use STDCALL and
mangle the names, even if it were itself compiled with /iface:default,
right?
When is everyone going to switch to 64-bit Windows so as to make
all the above moot?
> Regarding WriteConsoleA, there is the interesting issue that the
> compiler wants to pass a hidden length parameter for the character
> argument. I don't think that's correct and will talk to the team
> about that. If I add the appropriate attributes to disable the length,
> then it works.
Yeah, that seems inconsistent with the BIND(C) characteristics, like
the fact that only character variables with length 1 are allowed.
The requirement to pass this value of 1 every time seems not to
permit the degree of control a C program has over its interface.
Actually, passing character variables is a tough issue because
C wants pointers passed by value and this is so alien to the
Fortran way of doing things. I have my own style but I don't
know whether it's standard-conforming or if it's the preferred
way of declaring the BIND(C) equivalent.
What I do is declare
character(kind=C_CHAR) lpString
in the C function interface and then declare
character(kind=C_CHAR) message*(80)
in the Fortran caller then pass message like a normal argument.
Is this the normal way even though you are telling the compiler
that the callee only wants a single character by reference? If
the caller passed an expression, would the compiler be justified
in only computing the first character of the expression and
passing a reference to that?
steve...@gmail.com
> You will have to see what gfortran offers for specifying that an
> external routine is STDCALL. Whatever it is, it's going to be an
> extension and probably not part of BIND.
Why not part of BIND? My first thought was to have something like
BIND(C,STDCALL). But you're saying this can't work, if I understand
correctly?
> In Intel Fortran, for
> example, one uses !DEC$ ATTRIBUTES STDCALL :: routinename
Is there a document somewhere that describes where the "DEC$
ATTRIBUTES" lines can appear? E.g. does it have to follow immediately
after the declaration that the attributes apply to?
Gr.
Steven
glen herrmannsfeldt
> Why not part of BIND? My first thought was to have something like
> BIND(C,STDCALL). But you're saying this can't work, if I understand
> correctly?
C functions with a variable number of arguments don't work
well with STDCALL. ANSI C (unlike K&R) requires a special
declaration for such functions, so it would be possible to use
STDCALL for C functions that didn't have a variable number of
arguments (varargs), and some other convention for ones that
did, though most don't like doing that.
STDCALL has the called routine pop the arguments off the stack.
That is convenient to do if the number is constant, as it is
coded in a special version of the RET instruction (on x86).
VARARGS tends to require a minimum number of arguments, but the
routine is not required to process all the supplied arguments.
Even so, doing a variable pop with RET would be much more
complicated.
-- glen
Jugoslav Dujic
| On Nov 10, 2:24 pm, Steve Lionel <steve.lio...@intel.com> wrote:
|| You will have to see what gfortran offers for specifying that an
|| external routine is STDCALL. Whatever it is, it's going to be an
|| extension and probably not part of BIND.
|
| Why not part of BIND? My first thought was to have something like
| BIND(C,STDCALL). But you're saying this can't work, if I understand
| correctly?
I think I was the first who raised the issue of BIND(C) and STDCALL
in c.l.f... back then... searching:
the answer was, summarily, that it would be an extension. Personally,
I like the extensions that can be handled as "ignore the keyword if
you don't recognize the semantics" by the compiler, like this one
could be, but it's unlikely... at best.
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Steve Lionel
> Cool. I see that you are using the /iface:stdref switch whereas in
> my search I stopped when I saw the /iface:stdcall switch only. It
> does look like /iface:stdref is more consistent with Fortran norms,
> but in the case of BIND(C) procedures everything is specified in
> the interface so for these procedures the two switches should be
> indistinguishable, am I right? The reason I ask is because one could
> write out a module containing only interface blocks and compile the
> module with a switch -mrtd -magic-names :) or /iface:stdcall and then
> any program unit that USEs the module would know to call procedures
> whose interfaces were described in that module to use STDCALL and
> mangle the names, even if it were itself compiled with /iface:default,
> right?
Here you're stepping into quicksand. The Intel compiler's view is
that the /iface switches and ATTRIBUTES directives change the compiler
default behavior in ways that can be overridden by other explicit
syntax. For example, if you had used /iface:stdref and the VALUE
F2003 attribute, I'd expect the argument to be passed by value. Note
that even with BIND(C), arguments are passed in the normal Fortran way
(by reference, typically) unless you say VALUE. Therefore I do not
agree that stdref and stdcall should give you the same behavior with a
BIND(C) routine.
I'll tell you that I am somewhat uncomfortable with the idea of mixing
BIND(C) and /iface switches to produce some sort of combined
characteristic. My preferred style is to never use /iface and if I
need something different in an interface I use the appropriate syntax
(whether it be BIND(C) or !DEC$ ATTRIBUTES ) to get it. I have a
personal dislike of switches that change the meaning of code. I
understand their expedient use in porting situations, but I'd try to
dissuade you from using them in new code.
There's also a quirk of our compiler you are apparently not aware of.
Compiling a module (containing interfaces) with a specific /iface
option does nothing useful. That option is applied only when the
interface is used - it is not recorded as a property of the module. It
is for this reason we added the DEFAULT attribute back in the CVF days
- this tells the "user" of the interface to ignore all command line
options that change calling and naming conventions - so that you could
say everything you wanted to in an interface and not have it change
when the user compiled with, say, /names:lowercase. Personally, I
would have not chosen to design it this way, but that's the way it was
done some 15 years ago and we have to live with it.
> Yeah, that seems inconsistent with the BIND(C) characteristics, like
> the fact that only character variables with length 1 are allowed.
> The requirement to pass this value of 1 every time seems not to
> permit the degree of control a C program has over its interface.
I agree this is odd, but the idea seems to be that you are passing an
array of characters, not a character variable in the Fortran sense.
> What I do is declare
>
> character(kind=C_CHAR) lpString
>
> in the C function interface and then declare
>
> character(kind=C_CHAR) message*(80)
>
> in the Fortran caller then pass message like a normal argument.
> Is this the normal way even though you are telling the compiler
> that the callee only wants a single character by reference? If
> the caller passed an expression, would the compiler be justified
> in only computing the first character of the expression and
> passing a reference to that?
I would not think so. It's perfectly acceptable to pass a longer
string to a routine which declares the argument to be shorter (though
not the other way around).
Steve
Steve Lionel
> Why not part of BIND? My first thought was to have something like
> BIND(C,STDCALL). But you're saying this can't work, if I understand
> correctly?
That is certainly one possible syntax for an extension, which is why I
said "probably", but I'm not aware of any compilers supporting BIND
that have extended it in this way which is why I suggested that the
method is not likely to be within BIND.
Our view at present is that we already have an extension for
specifying this and aren't inclined to invent another, especially as C
does not use STDCALL by default. I can see the neatness of such an
approach when developing interfaces for things such as Win32 API
routines, but it's not compelling enough.
> Is there a document somewhere that describes where the "DEC$
> ATTRIBUTES" lines can appear? E.g. does it have to follow immediately
> after the declaration that the attributes apply to?
There is the Intel Fortran Language Reference. The directive need not
immediately follow the declaration but it should be before the
executable code. (Offhand, I don't know if this is a requirement, but
I think it would look silly to put them in with the executable code.)
Steve
Steven G. Kargl
"James Van Buskirk" <not_...@comcast.net> writes:
> "Steve Lionel" <steve....@intel.com> wrote in message
> news:1194792877.7...@v2g2000hsf.googlegroups.com...
>
>> I now see that you used the -mrtd switch for gfortran. I did not
>> recognize that earlier. Given that, I would say that gfortran should
>> have decorated the name on its own the way a C compiler would have if
>> a similar option was used (such as MSVC's /Gm). That you can't
>> explicitly specify the @n suffix is another issue, but I maintain that
>> the BIND name is not the proper place for that.
>
> I guess the gfortran folks had a thread about this:
>
> http://gcc.gnu.org/ml/fortran/2007-03/msg00162.html
>
> At the end it seemed that the recommendation was to use -mrdt -S
> and then use some kind of text-processing tool to mangle the names,
> then assemble and link. You attitude appears rather more user-
> oriented than that, and it's a pity that your enlightenment isn't
> a bit more contagious.
The wonderful thing about open source development is that one
can take the code and modify it to one's needs. It's a pity
that too many people are better at telling others what they
ought to do rather than rolling up their sleeves to contribute.
Whether you intend a negative tone in the last sentences above
I do not know; however, the written words are subject to
interpretation.
Disclaimer: I no longer contribute to gfortran.
Tobias Burnus
> On Nov 13, 1:51 am, stevenb....@gmail.com wrote:
> > Is there a document somewhere that describes where the "DEC$
> > ATTRIBUTES" lines can appear? E.g. does it have to follow immediately
> > after the declaration that the attributes apply to?
>
> There is the Intel Fortran Language Reference.
See:
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattcst.htm
and
http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattrib.htm
Google finds the following example, http://www.xlsoft.com/jp/products/intel/cvf/examples/cursor1.f90
interface
integer(4) function CallWndRetProc(nCode, wParam, lParam)
!DEC$ IF DEFINED (_X86_)
!DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc@12' ::
CallWndRetProc
!DEC$ else
!DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc' ::
CallWndRetProc
!DEC$ endif
integer(4) nCode ! hook code
integer(4) wParam ! current process flag
integer(4) lParam ! address of message data structure
end function CallWndRetProc
end interface
Tobias
Steve Lionel
>
> interface
> integer(4) function CallWndRetProc(nCode, wParam, lParam)
> !DEC$ IF DEFINED (_X86_)
> !DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc@12' ::
> CallWndRetProc
> !DEC$ else
> !DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc' ::
> CallWndRetProc
> !DEC$ endif
> integer(4) nCode ! hook code
> integer(4) wParam ! current process flag
> integer(4) lParam ! address of message data structure
> end function CallWndRetProc
> end interface
I would write this today (and in the past seven years) as:
interface
function CallWndRetProc(nCode, wParam, lParam)
!DEC$ ATTRIBUTES STDCALL,DECORATE, ALIAS:
'CallWndRetProc' ::
CallWndRetProc
use ifwinty !(or could use IFWINTY in the module and use
IMPORT here)
integer(LRESULT) CallWndRetProc ! Function result
integer(SINT) nCode ! hook code
integer(UINT_PTR) wParam ! current process flag
integer(ULONG_PTR) lParam ! address of message data
structure
end function CallWndRetProc
end interface
Note that the conditional code is not necessary and the compiler is
left to decorate the name. Also, the use of the predefined kind
constants helps make the code portable to 64-bits.
Steve
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>Whether you intend a negative tone in the last sentences above
>I do not know; however, the written words are subject to
>interpretation.
>
>Disclaimer: I no longer contribute to gfortran.
Actually, you can "contribute" by annoying people on Usenet and making
the project look bad. Whether you intended a negative tone in your
posting I do not know; however, the written words sure read that way.
But I'll give you the benefit of the doubt.
-- greg
James Van Buskirk
> On Nov 13, 1:07 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
>> Cool. I see that you are using the /iface:stdref switch whereas in
>> my search I stopped when I saw the /iface:stdcall switch only. It
>> does look like /iface:stdref is more consistent with Fortran norms,
>> but in the case of BIND(C) procedures everything is specified in
>> the interface so for these procedures the two switches should be
>> indistinguishable, am I right? The reason I ask is because one could
>> write out a module containing only interface blocks and compile the
>> module with a switch -mrtd -magic-names :) or /iface:stdcall and then
>> any program unit that USEs the module would know to call procedures
>> whose interfaces were described in that module to use STDCALL and
>> mangle the names, even if it were itself compiled with /iface:default,
>> right?
> Here you're stepping into quicksand. The Intel compiler's view is
> that the /iface switches and ATTRIBUTES directives change the compiler
> default behavior in ways that can be overridden by other explicit
> syntax. For example, if you had used /iface:stdref and the VALUE
> F2003 attribute, I'd expect the argument to be passed by value. Note
> that even with BIND(C), arguments are passed in the normal Fortran way
> (by reference, typically) unless you say VALUE. Therefore I do not
> agree that stdref and stdcall should give you the same behavior with a
> BIND(C) routine.
What I have in mind is (from n3661.pdf, section 15.2.6):
"(5) any dummy argument without the VALUE attribute corresponds to a
formal parameter of the prototype that is of a pointer type, and
the dummy argument is interoperable with an entity of the
referenced type (C standard, 6.2.5, 7.17, and 7.18.1) of the
formal parameter"
This seems to me to say that with BIND(C), the mode of argument
passing is not the normal Fortran way, but constrained to be
interoperable with a C pointer formal parameter if VALUE is not
specified. Thus the BIND(C) should, in my view, override the
default to pass by value which could be set by /iface:stdcall.
> I'll tell you that I am somewhat uncomfortable with the idea of mixing
> BIND(C) and /iface switches to produce some sort of combined
> characteristic. My preferred style is to never use /iface and if I
> need something different in an interface I use the appropriate syntax
> (whether it be BIND(C) or !DEC$ ATTRIBUTES ) to get it. I have a
> personal dislike of switches that change the meaning of code. I
> understand their expedient use in porting situations, but I'd try to
> dissuade you from using them in new code.
I feel your pain here. I can imagine the support issues you get from
users who have to set separate switches for every source file. I am
hoping to find a syntax for invoking Win32 API functions that has a
chance to work across multiple compilers. When, in about 10 years
(isn't that about the time it takes, e.g. it took about 15 years from
introduction of the 80386 to acceptance of xp, and x86-64 was introduced
roughly 5 years ago) everyone is running 64-bit Windows, the /iface:
switches shouldn't be necessary; they're just a temporary expedient
needed to cope with the zoo that is 32-bit Windows.
> There's also a quirk of our compiler you are apparently not aware of.
> Compiling a module (containing interfaces) with a specific /iface
> option does nothing useful. That option is applied only when the
> interface is used - it is not recorded as a property of the module. It
> is for this reason we added the DEFAULT attribute back in the CVF days
> - this tells the "user" of the interface to ignore all command line
> options that change calling and naming conventions - so that you could
> say everything you wanted to in an interface and not have it change
> when the user compiled with, say, /names:lowercase. Personally, I
> would have not chosen to design it this way, but that's the way it was
> done some 15 years ago and we have to live with it.
Excellent. This is one of the reasons for my paragraph requoted above:
there were several design choices that your compiler team could have
made here, and I wanted to flesh out what your design philosophy was.
As an optimist, I assumed that gfortran and g95 might be able to make
different choices. In that way, by constraining an interface block to
be interpreted in the context of the compiler evironment in effect at
the time of its compilation, gfortran could specify different calling
conventions for different procedures invoked by the same program without
introducing any new features, just possibly fixing bugs in the current
feature set. This is something that may be more likely for an advocate
to persuade the implementors to realize than new extensions.
If that meant that every Win32 API interface block had to have a
!DEC$ attributes STDCALL, DECORATE line in addition to the BIND(C)
stuff (so that other vendors either followed my proposal or the
Directive Enhanced Compilation way), that wouldn't be so bad. Even if
every vendor needed their own line of stuff in every interface block
it wouldn't be so bad. What starts to get dicey is if all the code
that uses it need preprocessor editing all over the place to work
across different compiler systems or if you need to write wrappers
in fasm or something for all the function calls.
>> Yeah, that seems inconsistent with the BIND(C) characteristics, like
>> the fact that only character variables with length 1 are allowed.
>> The requirement to pass this value of 1 every time seems not to
>> permit the degree of control a C program has over its interface.
> I agree this is odd, but the idea seems to be that you are passing an
> array of characters, not a character variable in the Fortran sense.
Again from n3661.pdf:
"(3) the number of dummy arguments of the interface is equal to the
number of formal parameters of the prototype"
I read that as precluding the possibility of passing the length
implicitly.
>> What I do is declare
>> character(kind=C_CHAR) lpString
>> in the C function interface and then declare
>> character(kind=C_CHAR) message*(80)
>> in the Fortran caller then pass message like a normal argument.
>> Is this the normal way even though you are telling the compiler
>> that the callee only wants a single character by reference? If
>> the caller passed an expression, would the compiler be justified
>> in only computing the first character of the expression and
>> passing a reference to that?
> I would not think so. It's perfectly acceptable to pass a longer
> string to a routine which declares the argument to be shorter (though
> not the other way around).
Reading n3661.pdf a little more carefully, I am starting to feel
more confident that the way I am doing things is correct and safe.
Thank you very much for the valuable feedback!
glen herrmannsfeldt
> "Steve Lionel" <steve....@intel.com> wrote in message
> news:1194963380....@i38g2000prf.googlegroups.com...
(snip)
>>Here you're stepping into quicksand. The Intel compiler's view is
>>that the /iface switches and ATTRIBUTES directives change the compiler
>>default behavior in ways that can be overridden by other explicit
>>syntax. For example, if you had used /iface:stdref and the VALUE
>>F2003 attribute, I'd expect the argument to be passed by value. Note
>>that even with BIND(C), arguments are passed in the normal Fortran way
>>(by reference, typically) unless you say VALUE. Therefore I do not
>>agree that stdref and stdcall should give you the same behavior with a
>>BIND(C) routine.
Note that while C does call by value, it sometimes looks different.
An array name is, more or less, a (constant) pointer to the first
element of the array. So an array name in C passed by value works
the same as Fortran call by reference. It seems, then, consistent
with C to pass an array by reference with BIND(C).
> What I have in mind is (from n3661.pdf, section 15.2.6):
> "(5) any dummy argument without the VALUE attribute corresponds to a
> formal parameter of the prototype that is of a pointer type, and
> the dummy argument is interoperable with an entity of the
> referenced type (C standard, 6.2.5, 7.17, and 7.18.1) of the
> formal parameter"
> This seems to me to say that with BIND(C), the mode of argument
> passing is not the normal Fortran way, but constrained to be
> interoperable with a C pointer formal parameter if VALUE is not
> specified. Thus the BIND(C) should, in my view, override the
> default to pass by value which could be set by /iface:stdcall.
What do you mean by "normal Fortran way" here?
>>I'll tell you that I am somewhat uncomfortable with the idea of mixing
>>BIND(C) and /iface switches to produce some sort of combined
>>characteristic.
(big snip)
>>>Yeah, that seems inconsistent with the BIND(C) characteristics, like
>>>the fact that only character variables with length 1 are allowed.
>>>The requirement to pass this value of 1 every time seems not to
>>>permit the degree of control a C program has over its interface.
>>I agree this is odd, but the idea seems to be that you are passing an
>>array of characters, not a character variable in the Fortran sense.
> Again from n3661.pdf:
> "(3) the number of dummy arguments of the interface is equal to the
> number of formal parameters of the prototype"
> I read that as precluding the possibility of passing the length
> implicitly.
The inconvenience of STDCALL and STDREF is that you can't have
unexpected arguments, as the called routine won't pop them off
the stack. Otherwise, extra length arguments at the end should
not cause problems for callee pops the stack systems. See:
-- glen
James Van Buskirk
news:fhcdt7$g79$1...@gnus01.u.washington.edu...
>> http://gcc.gnu.org/ml/fortran/2007-03/msg00162.html
Well, I thought that testing highly experimental compilers and
providing technical comments constituted a contribution. In fact
testing is much more of a labor-intensive process than coding.
Heck, even creating documentation is more labor-intensive than
coding. Frederic P. Brooks seemed to think that a team was better
off to have a ratio of several people performing other tasks to
one coder. The gfortran project, even in your absence, does not
seem to have as large a ratio.
Was I wrong about the thread and was some other conclusion reached
that makes it possible to invoke Win32 API functions in 32-bit
gfortran?
Tobias Burnus
> > integer(4) function CallWndRetProc(nCode, wParam, lParam)
> > !DEC$ IF DEFINED (_X86_)
> > !DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc@12' ::
> > CallWndRetProc
> > !DEC$ else
> > !DEC$ ATTRIBUTES STDCALL, ALIAS: '_CallWndRetProc' ::
> > CallWndRetProc
> > !DEC$ endif
>
>
> !DEC$ ATTRIBUTES STDCALL,DECORATE, ALIAS:
> 'CallWndRetProc' ::
> CallWndRetProc
>
> left to decorate the name. Also, the use of the predefined kind
> constants helps make the code portable to 64-bits.
I have some implementation questions - and I have to add that I do not
know much about Windows programming - esp. not with Fortran.
Additionally, I could not find much about STDCALL itself and I found
the ifort documentation of STDCALL vs. ALIAS vs. DECORATE a bit
confusing in terms of when does what apply (does STDCALL imply "@n"
already or not?). (Probably I'm simply to tired to study it properly.)
How does ifort alias("...") interact with a bind(C,name=)? And does
the STDCALL attribute force the same conditions as Bind(C)? (E.g. no
character(len=x), x > 1 etc.?)
When is "@n" added? Only for x86 32bit Windows and x86-64 has only the
"_" prefix? Or how interpret the "#if" in the original example? I
thought Win64 does not use STDCALL or does it?
Tobias
PS: I filled now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112 for
implementing STDCALL and @n in gfortran. I don't like adding something
such target specific vendor extension, but it seems to be much needed
under Windows and there does not seem to be a good better way of doing
it. Though, I am still considering something like
Bind(c,name='...',callingmethod='...'); nevertheless, "!DEC$" has the
advantage of being already widely used. I assume that Fortran 2008 or
some interop TR pre-draft do not address this issue.
PPS: STDCALL support will presumable not be included in GCC 4.3 given
that we are now in stage 3 (bug fixes only; release targeted for
Q1/2008).
Steve Lionel
> I have some implementation questions - and I have to add that I do not
> know much about Windows programming - esp. not with Fortran.
> Additionally, I could not find much about STDCALL itself and I found
> the ifort documentation of STDCALL vs. ALIAS vs. DECORATE a bit
> confusing in terms of when does what apply (does STDCALL imply "@n"
> already or not?). (Probably I'm simply to tired to study it properly.)
If a routine has the STDCALL calling convention, the name decoration
convention is to prefix an underscore and suffix @n where n is the
number of bytes pushed on the stack for arguments.
For !DEC$ ATTRIBUTES, if ALIAS is specified without DECORATE, then the
string specified for ALIAS is exactly what is used, without decoration
and in the exact case.
If ALIAS and DECORATE are also specified, the compiler applies the
appropriate name-decoration to the string supplied in ALIAS. So for
example if one has:
!DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS:"Foo" :: Foo
and routine Foo is a subroutine taking two non-character arguments by
reference, the generated external name is _Foo@8.
Note that for DVF/CVF/IVF, if you explicitly specify STDCALL as an
attribute, this has the additional effects of downcasing the name
(absent ALIAS) and defaulting to pass-by-value (with exceptions.)
>
> How does ifort alias("...") interact with a bind(C,name=)? And does
> the STDCALL attribute force the same conditions as Bind(C)? (E.g. no
> character(len=x), x > 1 etc.?)
You don't mix ALIAS with BIND(C,name=). One or the other. I'm not
sure if the current compiler will diagnose this, but a future one
will. STDCALL does not imply BIND(C).
> When is "@n" added? Only for x86 32bit Windows and x86-64 has only the
> "_" prefix? Or how interpret the "#if" in the original example? I
> thought Win64 does not use STDCALL or does it?
Only 32-bit Windows has the STDCALL convention. You can specify this
keyword on 64-bit Windows but it has no effect on naming or calling
conventions. 64-bit Windows does not apply a _ prefix either.
> PS: I filled nowhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112for
> implementing STDCALL and @n in gfortran. I don't like adding something
> such target specific vendor extension, but it seems to be much needed
> under Windows and there does not seem to be a good better way of doing
> it. Though, I am still considering something like
> Bind(c,name='...',callingmethod='...'); nevertheless, "!DEC$" has the
> advantage of being already widely used. I assume that Fortran 2008 or
> some interop TR pre-draft do not address this issue.
Correct. Let me suggest that you follow the path of other vendors and
try to be compatible with CVF/IVF, as that's where most of the Windows
code you see needing such a thing will be coming from.
Steve
e p chandler
> On Nov 15, 1:11 pm, Tobias Burnus <bur...@net-b.de> wrote:
>
re: discussion on specifying name decoration and calling convention on
a routine by routine basis is can be done in MSF/DVF/CVF/IVF compilers
on Windows
> > it. Though, I am still considering something like
> > Bind(c,name='...',callingmethod='...'); nevertheless, "!DEC$" has the
> > advantage of being already widely used. I assume that Fortran 2008 or
> > some interop TR pre-draft do not address this issue.
>
> Correct. Let me suggest that you follow the path of other vendors and
> try to be compatible with CVF/IVF, as that's where most of the Windows
> code you see needing such a thing will be coming from.
>
What a great relic this will be! Who will remember that !DEC$....
replaced !MS$.... or that DEC once stood for "Digital Equipment
Corporation"? I bet that eventually someone will claim that DEC stands
for DECORATE :-(.
Gary Scott
Wade Ward
--
wade ward
wa...@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Jugoslav Dujic
No, Compaq/Intel Fortran folks already retrofitted !DEC$, after DEC was
purchased by compaq. !DEC$ now "officially" stands for
"Directive [of] Enhanced Compilation", or something like that. :-)
Steve Lionel
> | What a great relic this will be! Who will remember that !DEC$....
> | replaced !MS$.... or that DEC once stood for "Digital Equipment
> | Corporation"? I bet that eventually someone will claim that DEC stands
> | for DECORATE :-(.
>
> No, Compaq/Intel Fortran folks already retrofitted !DEC$, after DEC was
> purchased by compaq. !DEC$ now "officially" stands for
> "Directive [of] Enhanced Compilation", or something like that. :-)
That renaming happened after we joined Intel - Compaq didn't care. In
the Intel Fortran documentation, you will find the chapter on
directives titled Directive Enhanced Compilation. We did this to quiet
down management who wanted it changed. WE know what it really
means...
Steve
dpb
...
> That renaming happened after we joined Intel - Compaq didn't care. In
> the Intel Fortran documentation, you will find the chapter on
> directives titled Directive Enhanced Compilation. We did this to quiet
> down management who wanted it changed. WE know what it really
> means...
OK, I'm curious...how long did it take for somebody to come up w/ the
words to fit the acronym? :)
--
Steve Lionel
> Steve Lionel wrote:
> OK, I'm curious...how long did it take for somebody to come up w/ the
> words to fit the acronym? :)
I think it took Stan (project lead) about 30 seconds.
Steve
Craig Powers
> e p chandler wrote:
> | On Nov 15, 4:38 pm, Steve Lionel <steve.lio...@intel.com> wrote:
> || On Nov 15, 1:11 pm, Tobias Burnus <bur...@net-b.de> wrote:
> ||| it. Though, I am still considering something like
> ||| Bind(c,name='...',callingmethod='...'); nevertheless, "!DEC$" has the
> ||| advantage of being already widely used. I assume that Fortran 2008 or
> ||| some interop TR pre-draft do not address this issue.
> ||
> || Correct. Let me suggest that you follow the path of other vendors and
> || try to be compatible with CVF/IVF, as that's where most of the Windows
> || code you see needing such a thing will be coming from.
> ||
> |
> | What a great relic this will be! Who will remember that !DEC$....
> | replaced !MS$.... or that DEC once stood for "Digital Equipment
> | Corporation"? I bet that eventually someone will claim that DEC stands
> | for DECORATE :-(.
>
> No, Compaq/Intel Fortran folks already retrofitted !DEC$, after DEC was
> purchased by compaq. !DEC$ now "officially" stands for
> "Directive [of] Enhanced Compilation", or something like that. :-)
I believe the official term for a change like that is "retcon". :)
dpb
Kewl...
--
Steve Lionel
> Umm... the -mrdt switch causes gfortran and g95 to use the STDCALL
> convention. The equivalent on ifort would be /iface:stdcall. Does
> the code from the seminal post of this thread compile on the current
> version of ifort with this switch?
I wanted to follow up with you to let you know how we're going to
resolve this. Basically, if you want to use STDCALL, you cannot use
BIND(C). If you specify ATTRIBUTES STDCALL or one of the /iface
options along with BIND(C), you'll get an error. For STDCALL, you
must use ATTRIBUTES and not BIND, or use the switch (again without
BIND).
Our view is that if you're using BIND(C), that means interoperability
with what the "companion C processor" does by default, and you're
using this for portability reasons.
Since the !DEC$ ATTRIBUTES syntax is accepted by most of the commonly
used Fortran compilers on Windows, as they want to be CVF-compatible,
this should do what you want.
Steve Lionel
Developer Products Division
Intel Corporation
James Van Buskirk
> I wanted to follow up with you to let you know how we're going to
> resolve this. Basically, if you want to use STDCALL, you cannot use
> BIND(C). If you specify ATTRIBUTES STDCALL or one of the /iface
> options along with BIND(C), you'll get an error. For STDCALL, you
> must use ATTRIBUTES and not BIND, or use the switch (again without
> BIND).
> Our view is that if you're using BIND(C), that means interoperability
> with what the "companion C processor" does by default, and you're
> using this for portability reasons.
> Since the !DEC$ ATTRIBUTES syntax is accepted by most of the commonly
> used Fortran compilers on Windows, as they want to be CVF-compatible,
> this should do what you want.
> Steve Lionel
> Developer Products Division
> Intel Corporation
@echo off
REM Write a code generator
echo open(10,file='end.f90',form='binary',status='replace') > junk.f90
echo write(10) 'end' >> junk.f90
echo end >> junk.f90
REM Compile the code generator
ifort -nologo junk.f90
REM Generate the code
junk
dir end.f90
REM echo on
ifort -mP3OPT_emit_asm_debug_info=1 end.f90
Steve Lionel
>
> @echo off
> REM Write a code generator
> echo open(10,file='end.f90',form='binary',status='replace') > junk.f90
> echo write(10) 'end' >> junk.f90
> echo end >> junk.f90
> REM Compile the code generator
> ifort -nologo junk.f90
> REM Generate the code
> junk
> dir end.f90
> REM echo on
> ifort -mP3OPT_emit_asm_debug_info=1 end.f90
Um, so? I see what that does, but don't see the relevance to the
thread nor am I sure what you wanted this internal switch for. (I
don't even know what it does - I'll have to ask.)
Steve
Steve Lionel
> ifort -mP3OPT_emit_asm_debug_info=1 end.f90
Doctor, it hurts when I do this!
Then don't do it!
This internal option adds information to an assembly file. You didn't
ask for an assembly file and the compiler is not expecting that
combination. Add -S if you want the assembly file, otherwise omit the
option.
Steve
Richard L Walker
there is a way to make f77, f95 or gfortran to use the Win32 API ...
and here is an answer waiting for me. I notice some don't like it,
BUT, I'm looking for ANY solution that will let me pop up and use I/O
under Windows XP rather than drop to DOS and use a program in the
command line environment. When ya gotta have it, ya ain't chosey.
Thanks.
On Sat, 10 Nov 2007 09:18:08 -0800, alexzenk <zenk...@mail.ru> wrote:
>On Nov 10, 7:35 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
>> There seems to be a problem with Win32 API and 32-bit gfortran.
>>
>
>Call Win32 API from gfortran is possible, but for this you should
>write for each used Win32 API functions interface subroutine on C.
>In consequence of significant difficulties of the mixed programming
>for Windows, such approach impractical. Writing of the whole program
>on C will probably more simply.
>Here is example such working program
>
>
>---------------File myfirst1.f95------------------------------------
>SUBROUTINE FortranSub()
>integer i, j
> CHARACTER(LEN = 15):: Text
> CHARACTER(LEN = 15) :: Caption
>i = 0
>j = 0
>Text = "Hello All"//CHAR(0)
> Caption = "gfortran"//CHAR(0)
> CALL MBox(i, j, Caption, Text)
>END SUBROUTINE FortranSub
>--------------File
>csub.c----------------------------------------------
>#include <windows.h>
>#include <stdio.h>
>void fortransub_();
>void mbox_(int *hWnd, long int *uTape, char *lpCaption, char *lpText);
>int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
> LPSTR lpCmdLine, int nCmdShow)
>{
> fortransub_();
> return 0;
>}
>void mbox_(int *hWnd, long int *uTape, char *lpCaption, char *lpText)
>{
> MessageBox(*hWnd, lpText, lpCaption, *uTape);
>}
>_____________________________________________________________________________
>------------ .bat
>file--------------------------------------------------
>path=D:\gfortran\bin
>set C_INCLUDE_PATH = D:\gfortran\include
>set LIBRARY_PATH=D:\gfortran\lib
> gfortran -c myfirst1.f95
> gcc -I D:\gfortran\include -c csub.c
>gcc myfirst1.o csub.o -o D:/gfortran/Output/myfirst1.exe -mwindows
>echo off
>if errorlevel 1 goto osh
>echo TERMINATED WITH CODE 0
>goto con
>:osh
>echo TERMINATED WITH CODE 1
>:con
>PAUSE
>___________________________________________________________________________
> Alex
Gary Scott
> Interesting. I come here wondering how to phrase my note asking if
> there is a way to make f77, f95 or gfortran to use the Win32 API ...
> and here is an answer waiting for me. I notice some don't like it,
> BUT, I'm looking for ANY solution that will let me pop up and use I/O
> under Windows XP rather than drop to DOS and use a program in the
> command line environment. When ya gotta have it, ya ain't chosey.
> Thanks.
Well, the premiere Fortran for interfacing with Win32 is Intel Visual
Fortran. It has everything you need and nearly everything (I haven't
found anything missing yet but I probably just haven't run across them)
you need to produce libraries for "foreign" compilers/languages.
James Van Buskirk
news:rtv2o3tuncuagbc9b...@4ax.com...
> Interesting. I come here wondering how to phrase my note asking if
> there is a way to make f77, f95 or gfortran to use the Win32 API ...
> and here is an answer waiting for me. I notice some don't like it,
> BUT, I'm looking for ANY solution that will let me pop up and use I/O
> under Windows XP rather than drop to DOS and use a program in the
> command line environment. When ya gotta have it, ya ain't chosey.
> Thanks.
Using gfortran you can call Win32 API on 64-bit Windows. It is not
possible under 32-bit Windows because of bugs in gfortran. There is
a workaround in 32-bit Windows using g95, and the bug fix for
gfortran is probably easy if the person who is capable of fixing it
knew there was a problem. Actually there are two problems, one on
the Fortran side and one deeper in gcc...
wind
"James Van Buskirk" <not_...@comcast.net> wrote in message
news:-OqdnZ2SP4elABza...@comcast.com...
> Using gfortran you can call Win32 API on 64-bit Windows.
>
Is it possible to post a simple example? thanx.
PS: Sorry not to provide a valid email address because I am afraid of
spammer.
--
Posted via a free Usenet account from http://www.teranews.com
Richard L Walker
into the window?
On Mon, 7 Jan 2008 09:38:44 -0500, "wind" <no-...@no-email.com>
wrote:
James Van Buskirk
news:47822d96$0$26009$8826...@free.teranews.com...
> "James Van Buskirk" <not_...@comcast.net> wrote in message
> news:-OqdnZ2SP4elABza...@comcast.com...
>> Using gfortran you can call Win32 API on 64-bit Windows.
> Is it possible to post a simple example? thanx.
I already have, but I decided to take this opportunity to fix some
bugs and stuff in the examples posted earlier. Now we have:
http://home.comcast.net/~kmbtib/Fortran_stuff/hello1.f90
http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin1.f90
There are still some annoyances: you have to nullify a pointer
and then pass it rather than passing NULL(), a function seemed
to be missing, and -subsystem windows (or however it's spelled)
doesn't do anything useful, but it's much more difficult to get
anything to work in 32-bit Windows.