Location of data files my Fortran DLL shall read

[cmc]

Hi,

I'm using Visual Studio Enterprise 2017 v15.8.9 and Intel Parallel Studio XE Composer Edition for Fortran Windows v2016. I have created a DLL which I am calling from VBA. The DLL requires input from various .dat-files. Today I have to locate these .dat-files in the following folder in order for the DLL to be able to read them: C:\Users\"me"\Documents. I have tried locating them in the same folder as the Visual Studio project and where the DLL is located, but with no luck. So my question is, how can I decide the path for where the DLL shall be looking for these files?

\Carl

[Arjen_Markus]

By default a file is opened in the working directory of the process. I do not think it makes any difference whether the code is contained in a DLL or in the executable program itself. If you want another directory, it should be part of the file name.

[cmc]

Is it not possible to specify something in one of the categories in the attached picture?

[Arjen_Markus]

You can specify a working directory for a debuggable item - but that means a program (or actually a process), not a DLL.

Maybe there are solutions like that, but think of it: a DLL is meant to be useable by any number of programs. If the DLL has its own implicit ideas about where to find files, wouldn't that clutter the dependency relations?

[cmc]

Yes, I see your point. But I'm thinking that the DLL should by default search for these files in the same folder as where the DLL is located. That is not the case. These files must be located in C:\Users\"me"\Documents, otherwise the DLL cannot find them. That seems odd to me...

[Greg_T_]

As Arjen indicated in R#2, could you pass the full file name including the full path to the DLL routine to specify the directory and file name?  When calling our DLLs from either Fortran or C# I pass the full directory path with the file name so that the DLL can open the desired file from any directory location.

[jimdempseyatthecove]

I haven't used this function, but you might experiment with using GetModuleFileNameA function to get the fully qualified path of the DLL. This will require you to obtain a handle to the DLL of interest (Use GetModuleHandleA).

Jim Dempsey

[gib]

cmc, it would seem very odd to me to have input files located in the same place as any DLLs the program uses.  It seems much more logical that the program should look for input files in the program's launch directory.

[Steve_Lionel]

As others have said, the default directory will be the one where the EXE is located (excel.exe, etc.) Consider that a single EXE may load a dozen or more different DLLs - it can't be possible for them to affect file load locations.

I agree with gib that trying to use the DLL location as a file default is just asking for trouble. I will note regarding Jim's reply that one does not use the A suffix when calling these Windows API routines, just GetModuleHandle and GetModuleFileName.  But don't do this.

[jimdempseyatthecove]

Arjen, Steve,

I am making a guess here that cmc intends to distribute his DLL, together with some sort of setup data files, and that he wished to use an install script that permits the user to install to an arbitrary location (and modify PATH to include the path to his DLL). If the installer also sets an environment variable to state the full path to the DLL, this would be one way to resolve the issue. I agree that user produced data files should not be placed in a folder in the PATH statement. Setup files located there may be OK.

Fortran USE KERLEL32 should have the generic interfaces without the A suffix.... but some of the Windows API are not in the KERNEL32 module... so, if you must write your own interface, use a similar argumented function call as a guide to write your own generic interface that calls the A suffixed functions.

Jim Dempsey

[Steve_Lionel]

Before I left Intel, I added thousands of new entries to KERNEL32 (and IFWINTY). If you find any that are missing, let Intel know. (I ran out of time before doing significant updates on other modules.) The two API routines you mention have been in KERNEL32 "forever". You're certainly right that if you're writing your own interface, you need to be aware of any suffix on the global name.

[cmc]

Thanks for all the input guys. Much appreciated! I think I will simply make a function that includes the entire path in the file name.