Improve replacing xinput1_3 with xinput9_1

[Jan200101]

The previous logic compared the whole argument, which may be a path, to a string literal.
This checks if the argument ends with the string literal instead.

[RoyalBlue1]

Code looks good. This seems to be a bit unnecessary since the dll is loaded from the game and the string will never change, but the readability changes are quite nice

[p0358]

But I still believe that overall it'd be better to replace the whole LoadLibrary fragment with patching the source string, but welp. I guess an advantage here is that a hook already exists anyway

[Jan200101]

@p0358 would this work for you?

{
	HMODULE moduleAddress;

	LPCSTR lpLibFileNameEnd = lpLibFileName + strlen(lpLibFileName);
	LPCSTR lpLibName = lpLibFileNameEnd - strlen(XINPUT1_3_DLL);

	// replace xinput dll with one that has ASLR
	if (lpLibFileName <= lpLibName && !strncmp(lpLibName, XINPUT1_3_DLL, strlen(XINPUT1_3_DLL) + 1))
	{
		lpLibFileName = "XInput9_1_0.dll";
	}

	moduleAddress = _LoadLibraryExA(lpLibFileName, hFile, dwFlags);

	if (moduleAddress)
		CallLoadLibraryACallbacks(lpLibFileName, moduleAddress);

	return moduleAddress;
}

It would also fix the issue of xinput 1_3 callbacks being called, but 9_1 being passed.

[p0358]

It would also fix the issue of xinput 1_3 callbacks being called, but 9_1 being passed.

Yeah it's good for that thing, though it didn't address either of my earlier comments xd But it turns out strlen on static string does get optimized with /O2, so I guess only the first one would stand (and it doesn't with a const variable so eh). So I guess it either has to stay a macro or be replaced to the literal in all cases

Idk then, someone else should also share their opinion on whether to keep the macro, move it inside of the func or replace with three string literals

Anyway I guess the rest is fine. You do get rid of the error on missing dll now, but it wasn't a fatal failure originally to begin with, and the DLL is always there on Vista+ under normal circumstances, so that also should be just fine

[GeckoEidechse]

Is there a good way to test this. Like how can I see what DLLs are loaded to verify that this works correctly? ^^"

[Jan200101]

Is there a good way to test this. Like how can I see what DLLs are loaded to verify that this works correctly? ^^"

Use a controller, I guess?
Process Monitor should be able to show you what DLLs are loaded.
Alternatively, x64dbg

[GeckoEidechse]

So based on @Jan200101's comment I found ListDLLs and used that

Before PR:

NorthstarLauncher.exe pid: 22440
Command line: "C:\Program Files (x86)\Steam\steamapps\common\Titanfall2/NorthstarLauncher.exe"  -profile=R2Northstar

Base                Size      Path
0x00000000e70d0000  0x185000  C:\Program Files (x86)\Steam\steamapps\common\Titanfall2\NorthstarLauncher.exe
...
0x00000000a3f50000  0x7000    C:\Windows\SYSTEM32\XInput9_1_0.dll
0x00000000a7770000  0x11000   C:\Windows\SYSTEM32\XInput1_4.dll
...

With PR:

NorthstarLauncher.exe pid: 18568
Command line: "C:\Program Files (x86)\Steam\steamapps\common\Titanfall2/NorthstarLauncher.exe"  -profile=R2Northstar

Base                Size      Path
0x0000000067670000  0x184000  C:\Program Files (x86)\Steam\steamapps\common\Titanfall2\NorthstarLauncher.exe
...
0x00000000a3f50000  0x7000    C:\Windows\SYSTEM32\XInput9_1_0.dll
0x00000000a7770000  0x11000   C:\Windows\SYSTEM32\XInput1_4.dll
...

No clue why xinput1_4 is in there but the behaviour with the PR didn't change so I consider this tested successfully ^^