Hard Light Productions Forums
General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: jr2 on October 08, 2018, 08:27:56 pm
-
What it says on the tin. FSO probes the dlls before first load to see what architecture they are and throws an error message if it's a mismatch.
-
Not possible since the DLLs are loaded before FSO itself is run... unless you're going to change how the libraries are linked which seems like a waste of effort.
-
Why are you having issues with this?
Knossos handles different platforms automatically and the nightly builds (but not 3.8 unfortunately) include every required DLL so extracting that will also not cause issues if you use wxLauncher.
-
This can become an issue if you're using wxLauncher and try to use both 32 and 64bit builds. Since wxLauncher expects all builds to be in the same directory, the DLLs conflict.
Maybe we can make wxLauncher check if the DLLs match the bitness of the selected executable? That would solve that problem at least.
Another problem that some people have run into is that copying the SDL2.dll from FSO to wxLauncher (to fix the joystick UUID issue) can cause the same error if it's the 64bit SDL2.dll since wxL itself is 32bit. Though once again that's much harder to solve and seems to be much rarer.
-
That seems like a lot of work for a use-case that we definitely do not want to encourage.
-
It's not really an issue for wxLauncher if users extract all files within the download package which apparently is not a reasonable expectation...
-
I don't have issues with this, but I keep reading cases where this happens (I'm guessing dozens over the last 6 months or so). For every case we hear about, how many more go unreported? There has to be a way to prevent this. I mean, Knossos is great, but not everyone is going to use it (yet).
There isn't a way to combine 32 and 64 bit dlls so that the appropriate part loads, is there? (I'm assuming not).
-
It would be a huge amount of work to add the ability to have 32- and 64-bit builds in the same directory. It is not worth the effort to implement this feature.
-
How about a useful error message?
-
The error message is produced by Windows before FSO is run. The only way to produce a proper error message would be having wxLauncher check the DLLs and the exe to detect this case before it launches FSO.