Wine fun #4

As I mentioned before, I was fooling around with running a game via wine on a remote server. After fixing wine to run the game, it was time to look for improvements in the remote connection.

While it worked via vino / VNC, it wasn't really playable.

VirtualGL and TurboVNC seemed like they could provide a satisfactory experience. My first attempt using TurboVNC as the X11 target for VirtualGL didn't work. It always resulted in a busy loop inside the nvidia closed source OpenGL library.

VirtualGL using the VGL Transport to my fedora 11 laptop, does work however! It's actually quite playable over a Wifi connection. The nice thing about this setup, is that the server is doing all the hard work, hence you could even use an under powered netbook as a game station.

I wonder if there would be much to gain by implementing a more advanced video compression engine in virtualgl. Maybe if I find the time, I might try to hook it up with libavcodec or something along those lines.

Wine fun #3

The icing on the cake has finally arrived!

After reversing large parts of the game code and spending a silly amount of time in a debugger, I was finally able to track down the code path that caused the game to crash on wine.
Once that was clear, it was just a matter of comparing the difference in return values when running the game directly on a windows box.

Since I just hacked up the wine source to return the value I needed, it isn't a proper fix.. but I'm hoping the wine devs can come up with a solution that is acceptable for everyone.

The bug details can be found in Bug 10832

Wine fun #2

Forgot to mention that the quick fix to solve the issue I was having, was to change the device mapping so that it doesn't have one pointing to the root of the filesystem anymore. On default wine makes a mapping for drive Z to the root of the filesystem, hence why it was able to find and open /dev/random. So the easy fix was to change the Z drive mapping in ~/.wine/dosdevices

Now I just have to find out why the game bombs out when pixel shaders are enabled...

Wine fun

Don't ask me how I came to this situation, but I was trying to run a windows game on my home server over a VNC connection. Not exactly an ideal and speedy setup, but cool to see it's possible.

However, for some reason I could start the game with wine when I was at the console of the machine, but whenever I tried to start it over a VNC connection, it got stuck in the connection phase. It first looked like a network issue, but a wireshark trace didn't show anything. It was also hard to explain why it would work locally but not remote, first thought it was due to the network load of the VNC session or some timing issue. So it was time to have a closer look at it.

First up, strace of the process showed it was very slowly reading small amounts of bytes from a certain FD. A look into /proc/<pid>/fd/<num> showed it was trying to read from /dev/random. Now we're getting somewhere.

Interesting thing about /dev/random is that it needs a source for entropy. The available entropy can be viewed from /proc/sys/kernel/random/entropy_avail. Wrote a tiny bash script to continuously display that file, which clearly showed that once the connection stage of the game was reached, the pool drained at exactly the same time as the game froze.. and then whenever the pool refilled, it was quickly drained again. So the problem was, due to working remote on the machine, too little events were generated that contributed to the pool, which blocked the process reading from the random device.

Starting some heavy disk activity, showed that this was indeed the issue, because as soon as I did that, the game continued.

Next step was finding out why wine used /dev/random instead of /dev/urandom. However, a quick grep through the source didn't show any location where this would crop up in my situation. Weird.

Next idea was trying to see what the game was trying to open exactly. Luckily wine has some pretty nice debug infrastructure, so after playing with WINEDEBUG a bit. I found that the game was issuing a CreateFileA() with "/dev/random" as file name, which doesn't work on windows of course. A double check in the game executable shows that it does indeed just that:

.text:0042C150 sub_42C150 proc near
.text:0042C150
.text:0042C150 arg_0 = dword ptr 8
.text:0042C150 arg_4 = dword ptr 0Ch
.text:0042C150
.text:0042C150 push esi
.text:0042C151 push offset aRb ; "rb"
.text:0042C156 push offset aDevRandom ; "/dev/random"
.text:0042C15B call _fopen
.text:0042C160 mov esi, eax
.text:0042C162 add esp, 8
.text:0042C165 test esi, esi
.text:0042C167 jz short loc_42C185
.text:0042C169 push 0 ; size_t
.text:0042C16B push 4 ; int
.text:0042C16D push 0 ; char *
.text:0042C16F push esi ; FILE *
.text:0042C170 call _setvbuf
.text:0042C175 add esp, 10h
.text:0042C178 test eax, eax
.text:0042C17A jz short loc_42C189
.text:0042C17C push esi ; FILE *
.text:0042C17D call _fclose
.text:0042C182 add esp, 4
.text:0042C185
.text:0042C185 loc_42C185:
.text:0042C185 xor eax, eax
.text:0042C187 pop esi
.text:0042C188 retn
.text:0042C189 ; ---------------------------------------------------------------------------
.text:0042C189
.text:0042C189 loc_42C189:
.text:0042C189 mov eax, [esp+arg_4]
.text:0042C18D mov ecx, [esp+arg_0]
.text:0042C191 push edi
.text:0042C192 push esi ; int
.text:0042C193 push eax ; int
.text:0042C194 push 1 ; int
.text:0042C196 push ecx ; void *
.text:0042C197 call sub_436C04
.text:0042C19C push esi ; FILE *
.text:0042C19D mov edi, eax
.text:0042C19F call _fclose
.text:0042C1A4 add esp, 14h
.text:0042C1A7 mov eax, edi
.text:0042C1A9 pop edi
.text:0042C1AA pop esi
.text:0042C1AB retn
.text:0042C1AB sub_42C150 endp

It's still not clear why this is done in the game, might be a check for linux (although the game is only available on windows) or maybe it's some old left over code that they forgot to remove. Who knows.

Anyway seems that the fact that wine supports unix file names transparently has caused issues in other places too