I make no claim of the usefulness of this page. You have been warned. :-) There is a reason this is in the "nerd points" category, I did what I did for (at the time) practical reasons but also for learning and having my own kind of fun with the terminal. There are surely easier ways to solve the problem in question, but it got the job done for me and was probably quicker still.

Update 2010-08-24: please see additional disclaimer at the end. Read it before the rest. ;-)

So I have a DOS game which, of course, is to be installed by means of a WIN32 executable archive (let's call it foo.exe to protect the innocent or something :-)). I'm also on the amd64 architecture, which possibly makes matters worse. I didn't know it was a Windows application though, so I tried with dosbox first.

$ dosbox foo.exe

and Dosbox says:

This program cannot be run in DOS mode.

OK, then, I tried with Wine:

$ wine foo.exe
err:dosmem:DOSMEM_MapDosLayout Need full access to the first megabyte for DOS mode

Nope… Well I got the tip to adjust a kernel setting:

# echo 0 > /proc/sys/vm/mmap_min_addr

By the way, the default setting in Ubuntu 10.04 is listed in /etc/sysctl.d/10-zeropage.conf (it's 65536), you may want to restore things afterwards for security.

Now I got a little bit farther, I get a little GUI, but when pressing Setup in the application, I get: (with some redaction)

wine: Cannot start DOS application "INSTALL.EXE"
      because vm86 mode is not supported on this platform.

OK… At this point I was guessing that all the files are actually unpacked before execution is attempted. However, it appeared Wine is deleting them after the above failure.

I'm leaving out some trial and error with strace and gdb to hold the files from being deleted, but the essence of it follows. Alternatives I know of that may have worked are virtualization, or modifying Wine, or some file system magic, or whatever. :-) (I actually tried a little shell script that kept waiting for the files to pop up, but it wasn't fast enough.)

So let's pretend I started with strace to find a suitable stopping point to feed gdb:

strace -f -o foo.strace wine foo.exe

gets: (redacted)

...
12131 stat64(...) = 0
12131 unlink(...) = 0
...

Time for gdb then:

gdb --args wine foo.exe

I wanted to stop before the unlink system call is used, so I could go with:

catch syscall stat64

and then I could use the run and continue commands as necessary.

In practice, by mistake in some sense, I caught the unlink system calls first, and then figured I should added the stat64 catch at the last minute. This was probably the best choice to avoid having to go through a lot of continue commands. Again, there was some trial and error to this and some details are left out. Whatever got the job done, basically.

The files were saved in a Wine directory, i.e. …/drive_c/users/$USER/Temp/, so all that remained here was to keep an eye on it and save the files elsewhere. Once I had them I could simply run dosbox in that directory and start the extracted INSTALL.EXE.

Disclaimer

It turns out, a simple unzip would have done the trick. :-) I didn't see it at first from this:

% file foo.exe
foo.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

but basically it was just a ZIP file with some packaging wrapped around it.

Chances are you will have luck with many such "executable archives" if you have either unzip (from the Ubuntu package with the same name) or unrar (either unrar-free, or unrar-nonfree in Ubuntu; the latter may be necessary in some cases). If you don't know how it's packed, open it with ark and it should provide a list that you can go through one by one (not so conveniently, but still). Note that it may list some archive types that you don't have any tools for.

You could also try:

strings foo.exe | grep -i "\(self\|archive\)"

to get some clues. I'm not sure what else to grep for right now.

Examples

If you see the following:

    name="Microsoft.Windows.self"

try unzip.