Mostly we code...sometimes we write. Every once in a while, we podcast.

What's in A Name

What's in A Name

Sharing code between projects is great! It's nice when you can take portions of your software and divide them up in a way that makes useful pieces reusable in new projects, while also making it easy to update and maintain older software that you're no longer actively looking at. Shared Objects, known as DLLs on Windows, are just really nice.


As long as you know what you're sharing, of course.


Like a friend who has never known the words "social boundaries", sometimes things get shared a little too much. Versions get mixed up, things don't line up, the thing you thought you were using wasn't what you're actually using, the list goes on. In short, DLL Hell is pretty hot. But even Hell has rules!


Every operating system has their own rules for loading shared objects, and Windows is no exception. In short, there's a list of places where the OS is expected to look for DLLs, all with varying levels of priority. Windows is rather nice in that, by default, the most local DLL always gets priority, with no added RPATHs{DY}LD_LIBRARY_PATH adjustments, or install_name_tool tomfoolery needed. This rule is actually how lots of mods work; projects like OpenSauce will use a referenced library name like d3d9.dll to inject custom code in between the game and the real library to allow for unofficial modding support.


On Windows, there's not much to see here. In Wine, there's a bit of a gap that programs have fallen into, and at least one game on Steam has joined the club recently!


Duck Game is an incredibly popular multiplayer game involving ducks1. (Surprised?) Duck Game is written in C# and uses the XNA framework for graphics/audio/input support. Wine and wine-mono handle this via FNA, a FOSS reimplementation of XNA, and for the most part, all is well. However, Duck Game (along with many XNA games on Windows) access DirectInputin custom joystick code, as XNA only supports gamepads with XInput support. In concept this is harmless; many games are known to use both XInput and DirectInput on Windows to support both Xbox controllers as well as controllers from other vendors (PlayStation controllers come to mind).


There's just one problem: The DirectInput code exists in a separate DLL (smart!), but the name of that DLL?


DInput.dll.


You know when movie studios come out with a remake and it has the exact same name as the original movie? Oh hey, did you see "Ghostbusters"? No no, not that "Lion King", the other "Planet of the Apes"! Anyway now that we've cleared that up let's move on...


There are two DirectInput DLLs on Windows, one being dinput.dll and the other being dinput8.dll (the latter being the "newer" version). Naturally, Wine reimplements these as built-in DLLs, and thus exist as special libraries like dinput.dll.so. So what happens when a dinput.dll exists but isn't the "right" dinput.dll? Lots of confusion! We see that the game is loading "DInput.dll", so cool, we have our own dinput.dll, wait, why does this look different, I am confused, something is wrong, forget it I'm going to go take a nap now, here's a FileNotFoundException for you.


Thankfully Wine is very flexible and allows for overriding certain DLLs on a case-by-case basis, so at the moment the way you launch Duck Game on Steam is by using the following launch option:


WINEDLLOVERRIDES="dinput=n" %command% -nothreading


"dinput=n" means "Just use DInput.dll without using the built-in version," so Wine will load Duck Game's DInput.dll without being clever, at which point it will go over to dinput8.dll, which is the actual DirectInput library we care about, and all will be right in the world.


You might be wondering how we're going to solve this problem. The truth is, we don't know yet! This problem has come up many times in Wine's long history, with this bug report being the most prominent one, so at the moment Duck Game is simply the latest entry in a very interesting problem. There are lots of possible approaches, with varying levels of danger involved... we could assume a DLL next to the exe should always be native, but what if it's a mod DLL that loads the OS' version later? And what if the native DLL actually isn't what you want in the first place? And how do we deal with the many other types of DLLs that games, mods, and even drivers ship with?


... Did it just get hot in here, or is it just me?


1 I didn't know where to put this in the post, so I just wanted to let you know that there's a dedicated Quack button in the game. That's it, this is the whole footnote.

The following comments are owned by whoever posted them. We are not responsible for them in any way.

CodeWeavers or its third-party tools process personal data (e.g. browsing data or IP addresses) and use cookies or other identifiers, which are necessary for its functioning and required to achieve the purposes illustrated in our Privacy Policy. You accept the use of cookies or other identifiers by clicking the Acknowledge button.
Please Wait...
eyJjb3VudHJ5IjoiVVMiLCJsYW5nIjoiZW4iLCJjYXJ0IjowLCJ0enMiOi01LCJjZG4iOiJodHRwczpcL1wvbWVkaWEuY29kZXdlYXZlcnMuY29tXC9wdWJcL2Nyb3Nzb3Zlclwvd2Vic2l0ZSIsImNkbnRzIjoxNzA4NjEzODE4LCJjc3JmX3Rva2VuIjoicFFMcktWQ1g2VGNOMkxrWiIsImdkcHIiOjB9