DLL binds working on some computers but not others

Legacy UDK Programming and UnrealScript
1

I have a very frustrating issue.

I have a DDL file that I am using in my game via DllBind. It works fine on some computers, but not on others (it shows a warning in the logs saying: “Warning, Class MyGame.MyClass can’t bind to DLL…”).

When i use the sample DLL provided in the documentation that works on all computers. But the one I compile myself only works on some. This makes me think it’s something about the way I’m compiling it. I’m using Visual Studio 2017. Just a basic c++ project, exporting at 32 bit.

Does anyone have experience compiling dll’s for their game that might know why my dll is working fine on some systems, but not on others?

1 Like
2

only thing i can think of that makes any sense is your dll is 32 bit and they must be starting a 64 bit game.

only time i have seen this warning

“Warning, Class MyGame.MyClass can’t bind to DLL…”).

is when the above happens

3

Unfortunately I am seeing this difference on two machines running the exact same version of the game. Works fine on one computer, then not on the other. Both running windows 10.

One other thing I’ve noticed: On the machine where the dll binds fine when running the game, if I run a dedicated server from that same executable, the dll bind fails.

4

The dlls per location have others on which they depend. That’s the only thing I can think of.

5

Wow, i have did that bunch and never seen that message. I tested a ton of code that way starting a dedicated server then starting a game from the same exe and joining the dedicated server from the game and all on the same machine. My dll binds have never failed, unless i try to start a 64 bit game.

Your dll are you just moving ints and floats and strings back and forth? This is all that is in our dll

dllimport final function int OpenHDFile(string fileName, string openMode); 
dllimport final function CloseHDFile(); 
dllimport final function string ReadStringFromFile(); 
dllimport final function int WriteStringToFile(string outStr); 
dllimport final function string ReadSecureStringFromFile(); 
dllimport final function int WriteSecureStringToFile(string outStr); 
dllimport final function int ReadIntFromFile(out int newInt); 
dllimport final function int WriteIntToFile(int outInt); 
dllimport final function int ReadFloatFromFile(out float newFloat); 
dllimport final function int WriteFloatToFile(float outFloat);

Then we have a read and write for paintball colors. That is all our dll does and it covers pretty much anything you need to save,

6

Oops, that is actually incorrect about the dll not binding if running as a dedicated server.

However I still have the issue of the dll working on one computer and not on another (which i can reproduce on two dev machines). I also see instances of logs from players where i see the binding issue.

It must be something in the way I’m compiling the file in visual studio.

Do you know what version of VS you are using? Are there any specific settings you’re using?

Using the (already compiled) dll from the example in the UDK docs works fine on both machines. It’s only when I compile it myself where it only works on one.

This is the test code I’m using from the example (just to test this issue):

// TestDLL.cpp : Defines the exported functions for the DLL application.

#include "stdafx.h"
#include <stdio.h>

extern "C"
{
	struct FVector
	{
		float x, y, z;
	};

	__declspec(dllexport) void CallDLL1(wchar_t* s)
	{
		MessageBox(0, s, L"Inside the DLL: CallDLL1", MB_OK);
		// reverse the out parameter string
		int len = wcslen(s);
		for(int i=0; i<len>>1;i++)
		{
			wchar_t temp = s[i];
			s[i] = s[len-i-1];
			s[len-i-1] = temp;
		}
	}

	__declspec(dllexport) FVector* CallDLL2(float x, float y, float z)
	{
		static FVector result;	// declared static so that the struct's memory is still valid after the function returns.
		result.x = x;
		result.y = y;
		result.z = z;
		return &result;
	}

	__declspec(dllexport) bool CallDLL3(wchar_t* s, int i[2], float* f, FVector* V)
	{
		wchar_t temp[1024];
		swprintf_s(temp, 1024, L"string: %s, i: {%d,%d}, float: %f, V was (%f,%f,%f)", s, i[0], i[1], *f, V->x, V->y, V->z);
		V->x = (float)i[0];
		V->y = (float)i[1];
		V->z = (*f);
		return (MessageBox(0, temp, L"Inside the DLL: CallDLL3", MB_OKCANCEL) == IDOK);
	}
}
7

Update:

I figured it out. It was because I was compiling the dll as Debug. I switched it to Release and now it works fine.

As per the UDK docs:

  • You should compile your DLL in Release mode if you intend to distribute it to others, otherwise you will likely have problems as the debug version of the C runtime will be unavailable.
1 Like
8

Sweet you figured it out :slight_smile:

9

Great thoughts I also realized that I was wrong about this!