forums.silverfrost.com

[KennyT]

...and at run time, it insists that the DLL should be in the c:\ root folder, rather than searching in the "current" folder.

Anyone got any ideas where to start when trying to solve this?

K

[ebarbero]

.NET or win32 project? do you use !dec$ attributes dllimport:: ???
_________________
http://www.cadec-online.com/

[KennyT]

I'm working in Win32. The DLL is an "unmanaged" wrapper for a .NET project.

I don't use "!dec$ attributes dllimport::" (I can't see any help on it either?)

K

[ebarbero]

[KennyT]

Perhaps I didn't explain the problem clearly enough!

I am building my application using win32. The third party application is written in .NET. Their programmer has supplied an "un-managed" wrapper for some of their functionality such that I can use the STDCALL technique to call them via my own set of wrappers, e.g.

[ebarbero]

I am sorry I misinterpreted your question.

It is really odd to ask for the dll to be in c:, but perhaps you can modify the path variable to point in the directory you have the dll. Would that solve the problem?
_________________
http://www.cadec-online.com/

[KennyT]

Some more information about how the third party app calls the DLL functions...

It appears that the DLL exports are "resolved" at runtime, rather than link time. Some test source they sent me has the folllowing call:

HINSTANCE hinstLib = LoadLibrary(TEXT("API.NativeExports.dll"));

Do we have the equivalent ability in FTN95?

edit: This extract from the FTN95 help pages sounds "interesting"!

[PaulLaidler]

I have never heard of anyone trying to access a .NET dll assembly from a Win32 executable before so I don't know if this can be done. Certainly, for me, you are working in uncharted waters.

The comment that you have picked up from the documentation about VB does not seem to be relevant.

DLL exports are always resolved at runtime. By default (for FTN95) they are resolved when the program is loaded but it is possible to to delay the resolving to the point when the function is called (depending on the commands used with SLINK). However, this does help with your initial problem.

Can you get the dll to work when you put it in the root folder as requested?

You can call LoadLibrary from FTN95 to see if the library is visible and loadable but there is no easy way to use the result of GetProcAddress but, again, this does not appear to be the issue here.

[KennyT]

Hi Paul,

Yes, the DLL works if placed in the root folder. If it's not there, I get the following message:

"The program can't start because \API.NativeExports.dll is missing from your computer. Try reinstalling the program to fix this problem".

"depends" also highlights the DLL as "not found".

I realise I'm a bit "out on a limb"!

As I understand it the 3rd party DLL is an "unmanaged" wrapper around "managed" functions but, as I don't use .NET, I don't really understand what that means!

Are there any other tools that can investigate whether the "\" is embedded in the DLL (ie their fault!) or somewhere that FTN95 or SLINK can have an effect on?

K

edit: I can call "LoadLibrary" and get a return value of 1661534208 (presumably just not being zero indicates success?) with just the local copy of the DLL being present.

2nd edit: Paul, you mention that the resolution of the externals depends on the slink commands used. Here's my link script for my DLL - what could I be doing different?

[KennyT]

Did some more tests...

[PaulLaidler]

If you use

rlo API.NativeExports.dll

in your SLINK script then the program will start running but will probably fail when the program calls a function in the dll.

[KennyT]

Hopefully resolved. The 3rd-party has relinked his DLL and got rid of the "\".

thanks

K