Silverfrost Forums

Welcome to our forums

DLL is missing while building EXE in Visual Studio 2015 IDE

7 Jan 2018 5:35 #21075

Dear There, I am facing this error while building an EXE in Visual Studio 2015 (VS2015) IDE by including the DLL ('MyDLL.DLL') reference. Both DLL creation and EXE building are done in VS2015 IDE using our FTN95 plugins. The EXE file ('SaiDllMain.EXE') is generated successfully but it shows the following error:

*SaiDllMain.exe - System Error * This program can't start because MyDLL.DLL is missing from your computer. Try reinstalling the program to fix this problem

On the other hand, if I build the EXE file, using normal command line options (compiler+linker) commands. The following linker command is used.

SLINK.EXE -out:SaiDllMain.EXE firstdll.obj MyDLL.DLL

This option has created the EXE file and it is running correctly and showing the results as coded.

Please note that the MyDLL.DLL is generated using the VS2015 IDE only, in both cases .

I am not able to understand what is the issue with VS2015 IDE. May I request your help to understand. Thanking you in advance.

7 Jan 2018 5:40 #21076

One more info.

I have added the MyDLL.DLL reference in the VS2015 IDE already.

8 Jan 2018 7:50 #21080

Moorthy

If you have created a 'solution' with two projects, one for the executable and one for the DLL, then I am not sure that you need a separate reference to the DLLs. You can make the executable dependent on the DLL and Visual Studio should sort out the reference.

Otherwise you may be able to fix the problem by copying the DLL to the output folder for the executable. This could be done as a 'post build' action in the project settings.

9 Jan 2018 6:46 (Edited: 9 Jan 2018 8:58) #21094

Dear Paul

Yes. I have used it in a single solution with two projects. One for DLL and another one for EXE. So, as you said, VS automatically sorted the DLL and compiled. Thank you very much for your suggestions.

But I am not able to get what I intended to develop. Please excuse for the detailed illustration of the problem here. I am not sure whether the same subject was discussed in our forum earlier.

Objective: What I am trying to build is nothing but the Reusable DLL Libraries with some Values to be supplied to the DLL library function and the results should be stored in the common area, where the Main Program can get it for further use.

Problem - 1: The Problem here is that I am not able to pass a value through our global MODULE into DLL.

I am showing the DLL code, Main EXE code and the output while running as given below.

To demonstrate I have used the following Codes.

The DLL Library routine code MyDll.f95:

!  --------------------------------------------------
!  Silverfrost FTN95 for Microsoft Visual Studio
!  Free Format FTN95 Source File
!  --------------------------------------------------

module  xyz
integer :: ii
end module xyz

program calldll
use xyz
integer:: val=1
print*, 'Dll Program calldll Started..'
print*,'common value ii received at calldll=',ii
print*, 'initialise val=',val
 val=ii
print*,'Val assigned in calldll prog.. =',val
call printsub(val)
print*, 'control returned back to main'
print*, 'Ending dll program calldll'
end program calldll

subroutine printsub(rval)
  use xyz
  integer,optional:: rval

   print*, 'Gotinside to subroutine'
   print*,'Received value =',rval
   print*,'module ii =',ii
   rval=rval*5
   print*, 'Printing the result=',rval
   print*, 'returning back to program calldll' 
end subroutine

The Main Executable Program Code SaiMainDll.f95:

module  xyz
integer :: ii

end module xyz
program SaiMainDll
use xyz
!!include MyDll
implicit none

!!integer iy
print*, 'This is Main Program...'
print*, 'Calling the Dll subroutine library'
print*, 'Assigning value here in MasterProgram as 12'
print*, 'The idea is ii value will be received in DLL'
ii=12
call calldll()
!call printsub(ii)
print*, 'Control received back to Main...'
print*, 'Printing at Main'
end program SaiMainDll

While executing the Main EXE file SaiMainDll.exe, following are the output obtained:

D:\A02\C03\Proj01\DllRef\dll-01\OverallSoln\MainExe\Debug\Win32>MainExe.exe This is Main Program... Calling the Dll subroutine library Assigning value here in MasterProgram as 12 The idea is ii value will be received in DLL Dll Program calldll Started.. common value ii received at calldll= 0 initialise val= 1 Val assigned in calldll prog.. = 0 Gotinside to subroutine Received value = 0 module ii = 0 Printing the result= 0 returning back to program calldll control returned back to main Ending dll program calldll

The results are not correct. Ideally the value for ii = 12 should be passed into the DLL (MyDll.f95) calldll() and it will inturn pass into the subroutine printsub(rval) which should display result as 12x5=60.

Where is the problem here? Why I am not able to get the value ii=12 into the MyDll.f95 in DLL library

Problem: 2 My intention of using MODULE in MyDll.f95 is to get the access to the COMMON storage data from the main Program. At the same time, I have to use that MOD file in Module path of SaiMainDll.f95, so that i can pass the value to ii as 12. As per our FTN95 standards, the MODULE should be used at one place. So, If I remove the MODULE definition in SaiMainDll.f95, I get the following Access Violation Error as given below:

9 Jan 2018 7:01 #21095

Continuing here, as part of the message was not posted.

This error comes when executing the program.

Error: Access Violation The instruction at address 0040113d attempted to write to location 00401c10 in file SaiMainDll.f95 at line 20

The line 20 is ii=12.

Why this problem happens here. ?

My idea is to develop reusable libraries in FTN95 as stated above. Is there any simple alternative way of doing this available? Please advise.

Thanks for your time.

9 Jan 2018 7:25 #21096

Moorthy

I will aim to take a look at this in a few days time if no one else is able to help you.

9 Jan 2018 8:55 #21098

Thank you very much Paul, for the quick reply. I await your suggestions too. I await response from Forum too

Thanks in advance.

9 Jan 2018 7:47 #21099

The EXE and the DLL contain separate copies of the module. Changing the variable in one copy does not affect the variable of the same name in the other copy. To see that this is the case, add the following diagnostic statement to the source codes, build as before and run.

print *,'Location of ii in PROG/DLL  ',loc(ii)

You will see that there are two separate instances of the variable II, one in the EXE and the other in the DLL. They have separate addresses.

If you want to implement data sharing, you will need help from the linker to make that happen -- the data segment has to be marked SHAREABLE. Of course, when you use this feature in other than a toy program, you will need to give careful consideration to preserving data integrity and will need to follow proper data sharing and updating protocols.

10 Jan 2018 5:21 #21100

Thanks much mecej4.

Ideally, i want to use the single data set which is SHAREABLE here with one Module definition only. but how to do this?. I am not finding any key word 'SHAREABLE' in our FTN95 manual. If you illustrate with a small sample code, it will help me to correct my understanding.

will need to follow proper data sharing and updating protocols.

If you elaborate about the updating protocols, it will help.

On the other hand, as I said, my interest is to develop a Reusable DLL libraries, where this data abstraction is enabled. For e.g. the function published out of the DLL, must use the same dataset from its main program, where it is called from. So that data duplication/memory duplication can be avoided, during the processing inside the DLL functions. How this can be done. Do you have any illustrative examples with you?. If not, please explain, where I will try to code.

Thanks in advance,

10 Jan 2018 11:34 #21105

There appear to be problems with sharing data with a .dll.

Perhaps you should consider a .lib static library, that is available with 32-bit slink. It does not have all the benefits of using .dll , but does have an easier data sharing capability.

When using 64-bit, you can load all the .obj files using tree names. This can be achieved by using a (long) list of link commands in a file, then: slink64 @load_commands.txt

10 Jan 2018 12:27 #21106

Thanks John, I prefer using .DLL rather than lib, while agreeing with you that .lib has certain limitations in data sharing. .DLL reference libs give a lot of comfort of accessing the published methods out of the DLL, as when you type a dot, then all the published functions will be listed out in IDE, and very easy for using and coding as well.

I agree with you the compilation steps using slink64. But I believe, the 64-bit also, same data sharing issues still exist in .DLL using our MODULE options. Is there any way out to solve this issue.

As mecej4 pointed out, the variable ii takes two different address in Main and as well in DLL code and the Main is not able to pass on the value to DLL routine. Somewhat this data should be made SHAREABLE. Thats where it lies. Any thoughts and ideas?

10 Jan 2018 1:05 #21108

In the next release of SLINK64 you will have the option to create static libraries.

FTN95 does not have the ability to mark data as 'external'. Also the linkers SLINK and SLINK64 can be used to link subprograms and not (to my knowledge) data. In other words, there is no direct way to share data.

Normally data is passed via subprogram arguments. If there is a large amount of data then it could be packed into an array so that only the base address needs to be passed.

Otherwise you could use an ALLOCATE statement with the parameter SHARENAME=. This is currently available for x86 and is now in the process of being ported to x64.

10 Jan 2018 5:07 #21114

Paul, Thank you, I have received 3 alternatives from you, John and mecej4. Many thanks to all of you.

They are:

  1. Use static libraries .lib
  2. Pass address of the data from LOC intrinsic function and use it at the target receiving function at DLL.
  3. Make data shareable using ALLOCATE with SHARENAME=..

This also reveals that we have more to go in x64. Advance thanks to the improvements on its way.

Let me try these existing options.

Thanking you once again.

Please login to reply.