Category Archives: English

Problems starting Steam on Linux

I recently installed Steam onto my Linux laptop. You know, to play games and such. Well, actually, just to try that one game which I knew was running in DOSBox. It’s that kind of game. Old. Should work on Linux, right? I mean, it’s DOSBox. Well — it didn’t — and Steam would not start either.

The problem

Trying to start Steam resulted in nothing. Tried several times. Nothing. Trying to start it from a terminal produced some error messages. That’s a good tip. If you have problem starting a program in Linux, try to start it in a terminal. It usually produce some information instead of dying silently.

$ steam 
 Running Steam on centos 7 64-bit
 STEAM_RUNTIME is enabled automatically
 Installing breakpad exception handler for appid(steam)/version(0_client)
 /home/torh/.local/share/Steam/ubuntu12_32/steam: symbol lookup error: /lib/ undefined symbol: xcb_send_request_with_fds
 mv: cannot stat ‘/home/torh/.steam/registry.vdf’: No such file or directory
 Installing bootstrap /home/torh/.local/share/Steam/bootstrap.tar.xz
 Reset complete!
 Restarting Steam by request…
 Running Steam on centos 7 64-bit
 STEAM_RUNTIME has been set by the user to: /home/torh/.local/share/Steam/ubuntu12_32/steam-runtime
 Installing breakpad exception handler for appid(steam)/version(0_client)
 /home/torh/.local/share/Steam/ubuntu12_32/steam: symbol lookup error: /lib/ undefined symbol: xcb_send_request_with_fds

The Solution

So I did a quick Google search, and instead of ending up on this blog post (like you did), I ended up at a GitHub issue where a post from 2017 gave me this answer. And guess what? It works! Just run this command from terminal, and after that it should work as normal.


In my case Steam started updating itself. So I guess the package available for CentOS isn’t kept up-to-date. And why would they, if Steam updates itself anyway.

The Question

Why on earth this hasn’t been fixed yet beats me. Actually, the Github issue says that it’s fixed, so I guess we are back to the point that the package in CentOS isn’t updated.

And why a game which “only” needs DOSBox isn’t supported on Linux is also a bit strange. I could always download it on a Windows machine and copy the files and see what happens.

Anyway. This was more about getting Steam running and less about me trying to play a game from my childhood years.

Knights of the Sky – Part 1

This post was written 4-5 years ago, back in October 2014, but for some reason never left the draft folder. Well, here it is. Maybe this will give me the necessary incentive to produce a part 2 in the near future.

I’ve recently become interested in doing some small programming projects. Mainly using C and assembly language. For some reason low-level programming and embedded systems appeal to me.

For fun, I decided to poke into the code of Knights of the Sky, the PC-version. A game which has given me hours of fun when I was young. Being a 16-bit DOS based game I thought it would be a relative easy task. The actual source code isn’t publicly available to my knowledge, so for this I had to look from the outside and in using different tools like hex editor and disassembly.

How the game is assembled

The game is split into several executables, none of which I was able to start directly from Dosbox. Neither was I able to disassemble them into anything useful. A quick peek using a hex editor reveals that they are compressed with the LZ91 algorithm. This isn’t a problem, the internet is full of tools which can uncompress them and make executables which can be dissassembled.

Notice the timestamp of the files

Splitting the files make some sense. Some because of the memory limit in early DOS era, but also because not all of the files are used. It all depends on the choices you make during setup, like sound and graphic options. Several of the executables have similar names, like CGRAPHIC.EXE, EGRAPHIC.EXE, MGRAPHIC.EXE and TGRAPHIC.EXE, and only one of them is used during game play. Same goes for sound.

Playing Knight of the Sky

To start the game the player would have to start KNIGHTS.COM, a basic binary executable which is loaded directly into memory location 0100h. This file acts as a loader which kicks off a chain of other executables.

Knights of the Sky code execution
My interpetation of the execution flow.

SU.EXE is the setup where the player can choose input (keyboard, mouse and/or joystick), sound and graphics options. This is passed along to DS.EXE which, and I’m guessing now, is the part responsible for the stack and the memory layout (remembering the choices made, etc). After SU.EXE, DS.EXE is run between every executable until the player exits the game.

Copy protection

ID.EXE is the game “copy protection” scheme, where you are presented with an image and have to choose the right option. This is found in the game manual. Remember those?

If the player selects wrong she or he is only able to play a training session. Again, I would guess that the result of this “copy protection” is also stored somewhere in memroy. MISC.EXE is also loaded into memory (overlay, not executed) by KNIGHTS.COM. This seems to be the code responsible for handling the game port (joustick). In my copy of the game this executable has a creation date of 1989, while the rest of the files are compiled in 1990.

Catalog files – think of uncompressed .zip files – just a big buch of different data stored within the same file.

Going back to ID.EXE, there is also a file called ID.CAT, which is basically a container for the images used by this executable. It contains one background image and several logos. One of the logos are presented and the user has to select the correct name which belongs to that particular logo. Creating a program to extract those files was (almost) straight forward after using a hex editor to figure out the internal data structure.

The two first bytes tells how many files are “packed”, immediately followed by the following data structure times the number of the two first bytes. In this case, 18 times. The same structure is used for the other CAT-files in the game as well.

struct fileHeader {
    char name[12];       // Filename with a maximum of 8.3, DOS-style
    unsigned short u1;   // ?? I Have no idea ??
    unsigned int size;   // File size in bytes
    unsigned int offset; // Offset from beginning of file

There are also some files ending with PLN, all of which has the same size (256 bytes) and almost the same content. The name is almost a dead give away that we’re talking about different colors, and swapping one file with another reveals that these are responsible for the color of your plane, seen from the outside (hitting F2 during flight) that is. However they do not seem to impact the landscape in any way. I’ll just assume that PLN is an abbreviation of the word “plane”.

Savegame file

The last file I will mention is the ROSTER.DAT. This is the only file which changes during game play (did someone say save game?). It’s 35K bytes, and since the game supports 10 saved players (no more, no less), it was fairly easy to guess how much “space” each player occupies. The structure of this file has to be well-defined, but I have only scratched the surface so far. Then again, I’m more interested in decoding the graphics and sound then trying to cheat the game. It’s a pain to play without a joystick anyway.

Now that we know where the different files are used and why, we are ready to dive deeper and do some real disassembly. The focus next will be on extracting and viewing images as well as be able to play the music from the game.

Fixing Yongnuo RF-600TX

A few years ago I bought two Yongnuo RF-602 RX receivers and a Yongnuo RF-600 TX transmitter for my Canon flash units. Recently they started misbehaving. Sometimes the flash didn’t fire, sometimes it fired to late. When using the test button however, the transmitter worked fine. What I noticed was that the green light on the front of the transmitter was flashing more or less continuously (when connected to a camera and the camera was on).

The green light is supposed to light up when the shutter button is half-pressed, and I assume it sends a signal to the receivers to wake up the flash. I also suspect that this behaviour, where the green light is on for no apparent reason, is “jamming” the other signal.

If you have this problem, the easiest way to verify is to block all the pins on the hot shoe except the one in the middle, which is transmitting the trigger signal. I used a thin piece of plastic to test this. This silenced the false signal and allowed the real trigger signal to function.
Image by OzAdr1an on Flickr

The more permanent solution is to open up the RF-600TX and remove the wiring to the offending pin. The unit has 3 wires. One for the trigger signal, in my case the wire in the middle, one wire for the base of the hot shoe, let us call it ground, and a third wire going to one of the other pins. This will vary depending if you have the Canon or the Nikon model.

Figure out which wire goes to the center pin, and which goes to the ground. Cut the third wire. Or take a soldering iron and gently remove it, in case you want to reattach it. That is what I did. To figure out what’s what I used a multimeter.

By the way, this might slow down the sync speed. But in my case it never worked with anything higher then 1/160 anyways…

Update: I just thought about this. To wake up the flash unit(s) you can half-press the test button instead of the shutter button. Or just force the flash units from going into sleep mode.

The image in this blog post is from OzAdr1an on Flickr and has been modified.

Disassemble DOS/4GW

A few months ago I started tinkering with an old DOS-based game trying to figure out its internal data structure. Progress was good in the beginning, and I was quickly able to alter the saved game to give myself some advantages.

Long story short, after a while I needed to figure out how the game handled a particular part of the savegame, since I couldn’t figure it out using a hex editor. But since the game was using a DOS extender, also known as DOS/4GW, loading it directly into Ida Pro Free wouldn’t help. It only gave meaningless garbage in return.

The solution

I found the open source DOS extender DOS/32. This has a utility known as SUNSYS Bind Utility which can be used to “Unbind and discard existing Extender/Stub from LE/LX/LC executable” as it says in the documentation.

Place the utility, along with the executable in question, in the same directory and fire up Dosbox (or the real thing) and enter the following command.

SB /U filename.exe

This will produce a unbinded file which can be loaded directly into Ida Pro Free. In my case I ended up with a file ending in .LE, which stands for “Linear Executable”.

Hopefully this can help others who want to peak into old DOS games.