Prev: Excell calling dll with 100% CPU usage
Next: Simple Hack TO Get $1500 To Your PayPal Account.
From: Steve Lionel on 19 Jul 2010 15:03
On 7/19/2010 1:45 PM, The Star King wrote:

> Thanks for that, Steve. I've only recently got IVF and didn't notice
> the OpenGL support! I'm now going through the OpenGL code in the
> Samples directory. Are there any OpenGL tutorials you would recommend?
> Preferably specific to Fortran, though that may be asking too much!

I have found that tutorial information on using OpenGL from C translates
very well into Fortran. The major thing to be aware of is that, due to
a choice Microsoft made back in the PowerStation days, the IFOPNGL
declarations of OpenGL routines all have an "f" prefix in their names,
but otherwise map directly onto standard OpenGL functions. The type
names typically have a "T_" prefix. You'll want to have the sources for
ifopngl.f90 and ifopnglt.f90 open for reference.

Many years ago, I bought "OpenGL SuperBible" and found it served me well
in understanding OpenGL programming concepts.

Oh, and forget about using any of the "Aux" routines - Microsoft removed
support for them in VS2008.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
From: The Star King on 19 Jul 2010 16:07
On Jul 19, 8:03 pm, Steve Lionel <steve.lio...(a)intel.invalid> wrote:
> On 7/19/2010 1:45 PM, The Star King wrote:
>
> > Thanks for that, Steve. I've only recently got IVF and didn't notice
> > the OpenGL support! I'm now going through the OpenGL code in the
> > Samples directory. Are there any OpenGL tutorials you would recommend?
> > Preferably specific to Fortran, though that may be asking too much!
>
> I have found that tutorial information on using OpenGL from C translates
> very well into Fortran.  The major thing to be aware of is that, due to
> a choice Microsoft made back in the PowerStation days, the IFOPNGL
> declarations of OpenGL routines all have an "f" prefix in their names,
> but otherwise map directly onto standard OpenGL functions.  The type
> names typically have a "T_" prefix.  You'll want to have the sources for
> ifopngl.f90 and ifopnglt.f90 open for reference.
>
> Many years ago, I bought "OpenGL SuperBible" and found it served me well
> in understanding OpenGL programming concepts.
>
> Oh, and forget about using any of the "Aux" routines - Microsoft removed
> support for them in VS2008.
>
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> For email address, replace "invalid" with "com"
>
> User communities for Intel Software Development Products
>    http://software.intel.com/en-us/forums/
> Intel Software Development Products Support
>    http://software.intel.com/sites/support/
> My Fortran blog
>    http://www.intel.com/software/drfortran

I'd like to thank everyone for their help with this.

I wonder: has anyone tried the approach suggested by James Van Buskirk
to generate windows programs in gfortran (using ISO_C_BINDINGS + !GCC
$)? Does it work? Has anyone prepared a substantial set of interfaces
for the api functions?
From: James Van Buskirk on 19 Jul 2010 16:08
"The Star King" <jfb(a)npl.co.uk> wrote in message
news:35ab2a26-37e5-4002-bd81-8042d299375a(a)g19g2000yqc.googlegroups.com...

> On Jul 19, 5:36 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:

> > I posted an example just a couple of days ago:

> > http://groups.google.com/group/comp.lang.fortran/msg/fd9d74e75d8fcb23...

> Thanks for this advice. Have you tried using this technique for
> Windows Api programming?

In fact the whole point of the example quoted above was to invoke
the Win32 API functions LoadLibrary, GetLastError, and GetProcAddress.

> I think the key thing is the command

> !GCC$ ATTRIBUTES STDCALL

> which i wasn't aware of but which is reminiscent of the Intel Fortran !
> DEC$ command.

Unfortunately the extensions are not identical. ifort doesn't have
the possibility to mix STDCALL with BIND(C). I think that was originally
a consequence of a misunderstanding about how BIND(C) was supposed to
work with CHARACTER arguments and function results, but Intel by now
has cleared up that misunderstanding and conforms to the standard which
to my mind should allow for mixing STDCALL with BIND(C) (see gfortran's
handling of the issue, for example) but they still don't.

As I said before, this problem only arises in 32-bit Windows; in 64-bit
Windows simply using BIND(C) works the same way in both compilers
because there is only one calling convention on that platform. In my
opinion, BIND(C) with no extensions could be made to work even in
32-bit Windows; just compile the module of interface blocks with a
compiler switch that specifies STDCALL. If it's required to compile
a callback function that must be STDCALL, then put that in a file
that has that switch. gfortran bombs when you do this because it
starts compiling calls to intrinsic functions as STDCALL which it
shouldn't do because it should have available to it an explicit
interface that specifies that the calling convention of instrisics
is CDECL, but it's probably way more work than it's worth to fix
that issue...

> (is this a new thing in gcc?). It looks as though I
> would have to write a large module full of interface statements
> (rather like the one Intel Fortran provides). But has anyone already
> written such a module?

As I said, you don't need the whole thing, just the interfaces and
derived types that your program actually uses.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: sturlamolden on 19 Jul 2010 16:47
On 19 Jul, 21:03, Steve Lionel <steve.lio...(a)intel.invalid> wrote:

> I have found that tutorial information on using OpenGL from C translates
> very well into Fortran.  

Given that Irix GL started as a Fortran 77 library on SGI Iris, that
does not come as a huge surprise. E.g. consider the order by which
OpenGL stores buffers and matrices.

From: The Star King on 20 Jul 2010 05:43
On Jul 19, 9:08 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:
> "The Star King" <j...(a)npl.co.uk> wrote in messagenews:35ab2a26-37e5-4002-bd81-8042d299375a(a)g19g2000yqc.googlegroups.com...
>
> > On Jul 19, 5:36 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote:
> > > I posted an example just a couple of days ago:
> > >http://groups.google.com/group/comp.lang.fortran/msg/fd9d74e75d8fcb23....
> > Thanks for this advice. Have you tried using this technique for
> > Windows Api programming?
>
> In fact the whole point of the example quoted above was to invoke
> the Win32 API functions LoadLibrary, GetLastError, and GetProcAddress.
>
> >                          I think the key thing is the command
> > !GCC$ ATTRIBUTES STDCALL
> > which i wasn't aware of but which is reminiscent of the Intel Fortran !
> > DEC$ command.
>
> Unfortunately the extensions are not identical.  ifort doesn't have
> the possibility to mix STDCALL with BIND(C).  I think that was originally
> a consequence of a misunderstanding about how BIND(C) was supposed to
> work with CHARACTER arguments and function results, but Intel by now
> has cleared up that misunderstanding and conforms to the standard which
> to my mind should allow for mixing STDCALL with BIND(C) (see gfortran's
> handling of the issue, for example) but they still don't.
>
> As I said before, this problem only arises in 32-bit Windows; in 64-bit
> Windows simply using BIND(C) works the same way in both compilers
> because there is only one calling convention on that platform.  In my
> opinion, BIND(C) with no extensions could be made to work even in
> 32-bit Windows; just compile the module of interface blocks with a
> compiler switch that specifies STDCALL.  If it's required to compile
> a callback function that must be STDCALL, then put that in a file
> that has that switch.  gfortran bombs when you do this because it
> starts compiling calls to intrinsic functions as STDCALL which it
> shouldn't do because it should have available to it an explicit
> interface that specifies that the calling convention of instrisics
> is CDECL, but it's probably way more work than it's worth to fix
> that issue...
>
> >               (is this a new thing in gcc?). It looks as though I
> > would have to write a large module full of interface statements
> > (rather like the one Intel Fortran provides). But has anyone already
> > written such a module?
>
> As I said, you don't need the whole thing, just the interfaces and
> derived types that your program actually uses.
>
> --
> write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
> 6.0134700243160014d-154/),(/'x'/)); end

James, thanks very much for your reply. Sorry, I didn't realise the
functions you mentioned were win32 functions. However, to get a
program running in a window a little more "magic" is needed. You need
to prepare a WinMain function and at least one callback function for
Windows to call. These are generally written in C as

int WINAPI WinMain (HINSTANCE hinstance, HINSTANCED hPrevInstance,
PSTR szCmdLine, int iCmdShow);
LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM
lParam);

This means that the Fortran program will not have a main "program"
declaration. How can gfortran cope with this?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Excell calling dll with 100% CPU usage
Next: Simple Hack TO Get $1500 To Your PayPal Account.