Blog ElCodiguero
15 may 2024 OldGames

Drain Drome: Broken forever?


I was able to get in touch with the people at, which seemed to list a different release than the one which can be found anywhere else.

Unfortunately, apart from containing a non-corrupted SAVERS.CMP, it is the same archive of unrelated files, no game is present.

After a few exchanges via Mastodon, the conclusion seems to be that this is a completely fake release, probably done to get “upload credits” on the BBS/FTP servers of the era, or by someone trying to prove their way in to a scene group. And since these are the only existant references to the game, it reaffirms my belief that there was never a game named “Drain Drome”.

End of update :)

If you browse old game collections, or “Abandonware” websites, you may find the game “Drain Drome”.

This is supposed to be a game released in 1995 by KingSoft. However, it is currently not possible to find a working copy of the game, as it seems every website has the same copy, which is broken beyond repair.

There is only one screenshot of the game, or rather, only one of the Abandonware sites shows what should be a screenshot of the game:

Screenshot of Drain Drome?

However, a reverse image search shows the screenshot is actually from the game Drainer, released for the MSX platform by Fun Project in 1987. The names are similar enough, could “Drain Drome” be a port to DOS?

I’m writing this piece in hopes somebody who knows more about the game would eventually read it, although I know very well the possibilities are very slim. At the very least, doing some research on this game led me to play a bit with Python and the format of ZIP files, so I consider it a success.

Game package

In all “abandonware” sites I searched, and also in a few game compilation packages (some of which can be found at the Internet Archive), you can download a copy of the game which is usually named as either “Drain Drome (1995)(KingSoft)” or “Drain Drome DOS EN”, and is about 2MB in size.

The compressed package contains the following files:

Both files can be decompressed without issues, generating a directory with the following contents:

Of those, the actual game packages are DRAIN.000 and DRAIN.001 (two zip files), and INSTALL.EXE is a batch file converted to EXE which simply runs PKUNZIP.EXE on DRAIN.000 and DRAIN.001. The fact that is a converted batch file can be seen easily using the strings command on it in a terminal.

The rest of the files are “scene” crap files from different groups, completely unrelated to the actual game. If anything, it serves as proof that when too many people is involved in something, it usually doesn’t end well…


Running dosbox on the directory which contains the files allows us to run the install program. As mentioned, the program is a batch file converted to EXE which simply runs PKUNZIP on each of the “DRAIN” files. It insists on being called with a source and destination drives, as follows:

install c: c:

This should extract the game files to C:\DRAIN, but the installer just creates the directory and ends, without any errors.

Running PKUNZIP on each of the files shows that DRAIN.000 can be correctly decompressed, but DRAIN.001 is corrupt. Any program trying to open it complains about it not having a “central directory” structure, for example:

$ unzip DRAIN.001
Archive:  DRAIN.001
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of DRAIN.001 or, and cannot find DRAIN.001.ZIP, period.

Brief detour: ZIP file structure

In a ZIP archive, each “member” (file inside the zip) is formed by a header and its compressed data.

The header contains details about the file, like the file name, its compressed size, its decompressed size, its modification date, etc. The data itself is the compressed data and has no structure: it begins after the header and ends after the number of bytes the header says it should contain.

After the compressed data for a member, we immediately find the header for the next one. Or, if it was the last one, the central directory structure.

This structure is what the programs which deal with zip files use. It contains the full list of members of the archive and their attributes, so programs can just go straight to the end of the ZIP file to list the members without having to scan the entire archive.

Recovering DRAIN.001

We can refer to dreams.nfo to find out that the “release” is supposed to be just two files, so we can assume the problem is not that we’re missing a DRAIN.002. But since we don’t have the central directory which goes at the end of the ZIP file, it seems this file got truncated at some point, and what we have is an incomplete file.

No generic program will touch that broken ZIP, but since all the information we need to recover the members (at least those which didn’t get truncated) is present, we can try to write a program to walk through the file and extract them. This is what some “recovery” software does, but it’s easy enough to code a script to do the same.

Unfortunately, since we now know the file is truncated, we can immediately conclude that at least one file within the archive will be incomplete and we’ll be unable to recover it, since the data is just not there. But hey, maybe it’s not an important file and we can get a working game anyway, right?

The details about the headers are available at Wikipedia. This is likely to be an old file so we shouldn’t need to worry about any extensions or Zip64 differences.

The following script extracts each member of the file:

#!/usr/bin/env python3
import zlib

def read_field(length, stream):
    byte_list =
    int_value = int.from_bytes(byte_list, "little") # values in the zip file are little-endian
    return int_value, byte_list # return the bytes as an integer, and as bytes

def parse_member(stream):
    # Read fields from the zip header. We don't need most of them so we don't assign
    # the return values of the function.

    # zip header
    read_field(4, stream)
    # minimum version needed to decompress
    read_field(2, stream)
    # general purpose flags
    read_field(2, stream)

    # compression method
    compression_method, _ = read_field(2, stream)
    if compression_method == 8:
        method = "DEFLATE"
    elif compression_method == 0:
        method = "none"
        method = "unknown"

    # file modification time
    read_field(2, stream)
    # file modification date
    read_field(2, stream)
    # CRC32
    read_field(4, stream)

    # file size
    compressed_size, _ = read_field(4, stream)
    uncompressed_size, _ = read_field(4, stream)

    # file name length, used to read the actual name later
    name_length, _ = read_field(2, stream)

    # extra field
    extra_field_length, _ = read_field(2, stream)

    # file name
     _, name = read_field(name_length, stream)
     file_name = ''.join(chr(b) for b in name)

    # skip extra field
    if extra_field_length:

    # read compressed data
    data =

    # try to decompress
    if method == "DEFLATE":
        # -15 is the minimum value allowed for the "wbits" parameter. Just a test I did and that
        # worked. Only values -8 to -15 allow us to use the decompressor on raw data, any other
        # value requires zlib headers to be present
        decompressor = zlib.decompressobj(-15)
        data_decompressed = decompressor.decompress(data)

    elif method == "none":
        data_decompressed = data

    with open(file_name, 'wb') as f:

    print(f"* {file_name} - {size}")

with open("DRAIN.001", 'rb') as zip_data:
    while True:

Please do not consider the above to be a “good” script, as it lacks any kind of protection against malicious files and doesn’t include any error handling. However, as a single-purpose script it does the job and leaves us with a nice set of new files:

The last one, SAVERS.CMP, is the corrupted file. It should be a bit short of 100 KiB, but the actual on-disk size is around 50 KiB.

Still, if we add the above to the file we obtained from DRAIN.000:

We have a bit more than 2 MiB of data, which for a DOS game coming in two floppy-sized ZIPs could be enough to be interesting.

BAT files

Immediately we can see the batch files are pretty much useless, as they look as if they should have been part of an installer process, but are clearly incomplete:

In conclusion: there is no EXE or BAT file in this package which could help start the game.

CMP files

Running file on the CMP files returns the following:

SAVERS.CMP: TSComp archive data

Which doesn’t mean a lot (what is TSComp?) but it says “archive data” and is a format clearly recognized by the program, so maybe it is possible to extract whatever these files contain.

I found the untsc program in GitHub, which in turn links to, which is the software to compress and decompress these files under DOS. I copied the EXE to the game folder and started dosbox.

As most compression utilities, the program works by default in compress mode, but we can pass -d to decompress. I extracted the contents of all of the CMP files in this way:


I left the “known-broken” file for last, and as expected the program failed to extract everything, although it could still extract a few files.


The resulting directory is quite strange, at least compared with what we expected. It contains over 200 files, and it looks more like a dump of a Windows 3.11 system than a game folder:

Regarding the MVEs and TUNs, file shows they are “MS-DOS executable, NE for MS Windows 3.x (3.0) (DLL or font)”. Wikipedia has a few things to say about NE executables, but not that much apart from implying they are a very old executable format for DOS and early Windows.

If we ignore the files we already had, and the MVE, TUN, WAV, and BMPs, we end up with less than 20 files, which appear to be an installation of Icon Hear It (, as the only new EXE file we get is IHEARIT.EXE and one of the image files contain the icon for the application.

Conclusion: Does it even exist?

No file in the directory seems to have anything to do with a game, much less something called “Drain Drome”. We may still be missing files, of course, as we we don’t know what is missing from DRAIN.001, and DOS games are small enough that the entire game might be in those missing parts.

However, it seems this release was never packaged properly, and that there was never a complete DRAIN.001 which resulted in a working game. If it were, it just wouldn’t make sense that the only copies available are corrupted in the same way.

The fact that the BAT files are useless is another indication. They seem to have been part of an unfinished unofficial “installer” created by the release groups, but they don’t reference any other executable. If we had the name of a missing file, we could use it as an additional hint.

There is no directory structure for the uncompressed files. Granted, I don’t think we’re supposed to uncompress the CMP files manually, but the end result is a single directory with a bunch of unrelated files.

Finally, the release includes what seems to be part of a Windows install, as well as the setup files for unrelated software. While this is common nowadays as games are packaged for dosbox and sometimes include Windows 3 (or even 98!), this release is from a time where this was not necessary or even desired. The files have modification dates of 1995 and 1996, a time when most people were still running compatible OSes and download times and speeds would have made downloading a 2MB of extra files very annoying.

In conclusion, I believe the game “Drain Drome (1995)(KingSoft)” doesn’t exist.

A game with a similar name might have existed, but the name was different enough that it is not possible to find it with a simple substitution (e.g. “Drain Dome”, or “Rain Drone”, etc). Alternatively, the game might have been released by the scene group before its official publication, with an unofficial or code name.

As for the company which developed it: there is no proof apart from the NFO files that the game is from KingSoft. And there are no games released by the Chinese KingSoft or the German KingSoft GmbH around 1995 which looks like “A SHOOTEM UP GAME IN SVGA”, which is how the NFO files describe the game.

KingSoft GmbH went down in 1995 and was acquired by EA (which killed it in 1996). According to Wikipedia, by 1995 it was a game distributor and not a publisher, but could “Drain Drome” have been an unfinished project? KingSoft did have the Space Pilot game series, but those are quite older than 1995.

I have no proof of the following, but here is what I imagine could have happened:

At some point in 1995, somebody at KingSoft GmbH saw the decline of the company and its impending doom and leaked an unfinished game, maybe a port of Drainer to the PC or a new install of the Space Pilot series. The leak consisted of some early build of the game and a bunch of extra files from a developer workstation.

The scene group rushed to make it public before actually getting it in a working state. Or maybe they just put it in their FTP server while they worked on it, and from there it was copied elsewhere. At some point they noticed one of the files was corrupt, but by then it was too late to stop it from spreading. Or maybe there were no copies made and their FTP server had a problem and files got corrupted.

In any case, the “game” spread enough to become part of listings and “collections” floating around. Abandonware sites just scraped those collections, parsing the name of the package to get name, year, and publisher, but of course never got it to work and thus there are no screenshots or additional information available.

The above is just my imagination, so it may be wildly inaccurate. However, I do believe with 100% certainty that ANY site where the game is listed as “Drain Drome (1995)(Kingsoft)” will have the broken package.

There is only ONE reference I could find of a different package for the game, but I’m unable to find it for download: the game seems to have been part of a release named “DMODE-7” by the group “The Numbers IBM Division”. The files listed there are two ZIP files with different sizes than the one found elsewhere. Maybe, if that release could be found, it would have a working copy of the game?

References & Links

Pages for the game in Abandonware sites

A few links from the Internet Archive

Activa Javascript para para cargar los comentarios, basados en DISQUS

El Blog de ElCodiguero funciona sobre Pelican

Inicio | Blog | Acerca de