need a little help calling C

[Brian_Murphy]

I have a DLL I can call from a C program, but not from fortran.  When I build the fortran program, I get unresolved external.

The c prototype for the function is  hasp_status_t HASP_CALLCONV hasp_logout(hasp_handle_t *handle);
hasp_handle_t appears to be unsigned long in C

hasp_status_t appears to be an integer.  It's actually an enum so I think that means it's a regular integer.

HASP_CALLCONV appears to be __stdcall

How do call this from fortran?  I've tried types integer for the return value and c_int32_t for the handle argument, but the linker gives me unresolved external.  I have both the DLL and its corresponding .LIB file which I have included in the visual studio project.

	use, intrinsic :: iso_c_binding 
	implicit none 
	interface
		function hasp_logout(handle) result(retval) bind(C, name="hasp_logout")
			import
			integer(c_int32_t) :: handle
			integer :: retval
		end function
	end interface

[andrew_4619]

SNAP

[Steve_Lionel]

That version does include Visual Studio Shell. 

[Brian_Murphy]

Will a visual studio 2010 .sln work in Visual Studio Shell?

[andrew_4619]

Brian Murphy wrote:

Will a visual studio 2010 .sln work in Visual Studio Shell?

Yes but it gets "upgraded" to a newer level if the VS Shell s later, SLN  is in general is not backwards compatible 

[Steve_Lionel]

As of about VS2012, though, VS doesn't do those "upgrades" and can handle somewhat older solution files.

[andrew_4619]

Steve Lionel (Ret.) (Blackbelt) wrote:

As of about VS2012, though, VS doesn't do those "upgrades" and can handle somewhat older solution files.

Interesting to know that changed, I guess once you get bitten you avoid dogs thereafter and thus never learn about that new breed of non-biting dog.

[Brian_Murphy]

Is this right? VS2010 sln's can be opened and used with today's Shell, but once that's done there's no going back.

[Steve_Lionel]

If this concerns you, make a copy of the .SLN and open that in the newer VS. In my experience the only real change is an identifier in the first line of the file.

[JohnNichols]

Brian Murphy wrote:

Is this right? VS2010 sln's can be opened and used with today's Shell, but once that's done there's no going back.

I have found that once you go from about 2012 to a 2017 there is difficulty going backwards without essentially recreating the sln folder. 

But VS creates project files for 2013 2015 2017 etc so you can keep separate copies. 

Your best bet is to simply move to 2019 -- there are many improvements and access to a lot of features. 

With modern Fortran and access to Steve et. al., there are not many old programs that can not be modernized. 

John

[Brian_Murphy]

The installer for composer 2018 said I had to first install vs2015, so I did. It took me a couple of hours to install everything, but I'm able to build and run the fortran project that calls C, but it's not working correctly just yet. 

A separate problem is the Help button doesn't work.  In visual studio 2010 it would show online help, but in vs2015 it says documentation is only available at software.intel.com and to see the Getting Started Guide from the Help menu, but it's not there.  How do I get vs2015 to access online help?

I have put back the BIND(C) stuff.  But I wonder if I have the STDCALL stuff setup correctly.  Is the following the right way to specify STDCALL?  Do the dummy arguments needs to be specified, too?  Does STDCALL matter for all arguments, or just strings?  The argument feature_id is declared in C as (unsigned long).  What is the right fortran data type equivalent?  Sorry if these questions seem trivial, but I don't know what I'm doing.

		function hasp_login(feature_id, vendor_code, handle) bind(C, name="hasp_login")
            !DEC$ ATTRIBUTES STDCALL :: hasp_login
			import
			integer(c_int32_t) :: feature_id
			integer(c_int32_t) :: handle
			character, dimension(*) :: vendor_code
			integer(c_long) :: hasp_login
		end function

[Steve_Lionel]

This looks right so far, but you haven't (I think) shown us the C prototype for hasp_login. If any of the integer arguments are received by value in C, you will want to add the Fortran VALUE attribute, for example:

integer(c_int32_t), value :: feature_id

STDCALL is a procedure-level attribute. When used by itself (without BIND(C)), it not only changes the calling convention, but also changes defaults for arguments to be by-value, lowercases the routine name and adds the @n suffix. But with BIND(C), it changes only the calling convention (implicitly adding the proper decoration to the name you give in the BIND attribute).

For the documentation, see https://software.intel.com/en-us/articles/download-documentation-intel-compiler-current-and-previous  I am not sure if that works in VS2015, but it may. Why did you go for that old version of VS? 

[Brian_Murphy]

Thanks very much for the reply, Steve.  I installed vs2015 because that was what the Composer 2018 installer said I needed.  When I manage to get my registration problems fixed, and get Composer updated to today's version, I expect to install a newer visual studio.  In the other thread about hasp_login, I will try to utilize what you just said in #32.  

My Subject for this thread and the other one were misleading about how much help I need.  Sorry 'bout that.

[Brian_Murphy]

Ahhhh, I see! Said the blind man.  The VALUE attribute worked magic.  The call to hasp_login now works perfectly.  Thanks for sticking with me on this.

[Brian_Murphy]

I got VS2019 and Intel composer XE 2020 19.1.0055.16 installed.  Then by downloading html help files to my computer, I've got F1 context-sensitive help working for fortran from inside VS2019.  So I'm a happy camper.

According to Add/Remove Programs, I have both Parallel Studio XE 2018 and 2020 co-installed, at 9+ GB each.  I will uninstall 2018 and hope not to break anything.

[JohnNichols]

Brian Murphy wrote:

I got VS2019 and Intel composer XE 2020 19.1.0055.16 installed.  Then by downloading html help files to my computer, I've got F1 context-sensitive help working for fortran from inside VS2019.  So I'm a happy camper.

According to Add/Remove Programs, I have both Parallel Studio XE 2018 and 2020 co-installed, at 9+ GB each.  I will uninstall 2018 and hope not to break anything.

I would leave it - do not break what is not broken

[Brian_Murphy]

Too late, and I broke it.  My fortran .sln's will load in VS2019, but when I try to compile or build or clean, I get "unspecified error".  C language projects still work ok.

So I did a "repair" of fortran composer XE 2020, and it complained I had to close a microsoft database manager application.  After that it's back to normal.  Whew!

[JohnNichols]

Life's a beach and then you drown. 

[Brian_Murphy]

A sensible thing to do after the uninstall would have been to reboot, and that may shut down the lingering database app, which may have been the entire problem.