Poverty Inspired Me to Fix a 'Wine Can't Do This' Timeout

Morgan Ufuoma — Tue, 06 Oct 2026 21:55:23 +0000

A wise man once said, “if the young man is hungry, he should go to the forest and hunt the elephant. If he kills the elephant, the hunger ends, and if the elephant kills him, the hunger ends.”

My Monday poverty motivation led me to brave the waters of quantitative trading using algorithmic bots. As a Nigerian, familiar with unsteady power supply, I asked early: “how can I achieve 100% runtime even if I don’t get light for a week?” The answer led me to a VPS (Virtual Private Server).

Ladies and gentlemen, tell me why the cheapest monthly subscription for a Windows OS is $50. My entire trading equity is $100, and I’m not even sure I have an edge yet. Scratch that. I’m sure I don’t currently have an edge.

In search of the cheapest option I could get on the market, I stumbled on Linux on Contabo for $51/year.

The problem: MetaTrader 5 is Windows-only, and I had to run it under Wine. And I had to run it Headlessly. Headlessly, in this case, simply meant it would run without a GUI. No pictures.

To further complicate things, every forum thread said the same thing: don’t bother, MetaQuotes’ proprietary IPC layer can’t be emulated, use Windows Server or a Docker wrapper instead. Windows was already off the table, but what about Docker? My setup was an 8GB RAM, 75GB NVMe VPS. A proper multi-container Docker setup (three isolated broker instances, each with its own Wine runtime, virtual framebuffer, image layers, and logs) would have swallowed 20GB or more before I’d logged a single tick. On a 75GB disk, that’s not infrastructure, that’s a tax. Docker was out.

I had to do the impossible. I had already paid for the VPS. There was no way I was wasting $51. I would actually cry.

So I spent the last seven days trying to crack it, how to run MetaTrader 5 headlessly, and it almost cost me my head. I read as much as I could, gave up, went to AI, used every model available, and the only thing growing on my VPS was the number of orphaned processes. Until we went binary. Well, not me, technically. It was an agent that tunnelled into the VPS. But yes, we had to go binary to find where it was failing, and we finally found a fix.

Okay. Jokes aside, here’s what actually happened.

The setup

I was migrating a legacy multi-broker trading system off a fragile Windows-wrapper architecture and onto a hermetic, systemd-supervised Linux stack. Three isolated Wine prefixes, one per broker connection, each running its own MetaTrader 5 terminal alongside an embedded Windows Python instance that hosted a small bridge service. That bridge exposed MetaTrader5 to my native Linux Python stack over localhost TCP, since a Windows PE binary obviously can’t be imported straight into Linux Python.

The challenge

Before I even got to the real blocker, I had to fight through a full stack of Wine-on-Ubuntu-24.04 failures:

A setup script that accidentally killed itself, because pkill -9 wine matched the word “wine” inside its own filename (setup_vps_wine_mt5.sh).

winedbg popping a modal crash dialog on a headless server, silently hanging every unattended restart until I explicitly disabled it.

A stale X11 lock file (/tmp/.X99-lock) breaking Xvfb on every crash recovery.

MT5 refusing to boot past a “Windows 10 build is end-of-life” warning dialog, which I fixed by patching the Wine prefix’s registry to report a newer build number.

A config file that silently failed to authenticate. Turned out cat << EOF writes UTF-8 without a BOM, but MT5’s config loader needs UTF-16LE with a BOM, and bash/Wine’s CRLF handling was inserting duplicate carriage returns that corrupted every key.

MT5 ignoring my Program Files config entirely once it had booted once, because it caches a copy in a hash-named roaming profile folder and reads from there instead.

NumPy 2.2.2 crashing the whole Python process on import, because Wine’s ucrtbase.dll doesn’t implement a C99 intrinsic NumPy now depends on.

Every one of these was individually solvable. None of them were the real problem.

Boss fight

Once all of that was cleared, I hit this:

>>> import MetaTrader5 as mt5
>>> mt5.initialize()
# ... 30 seconds of dead silence ...
False
>>> mt5.last_error()
(-10005, 'IPC timeout')

Every resource I found agreed, and they all agreed on roughly the same theory. Wine’s Named Pipes were starved under load. The terminal’s message pump was choking behind some modal dialog. The whole thing was stuck in a kernel-level wait so deep not even Ctrl+C could reach it. It sounded sophisticated. It sounded plausible. It sounded like exactly the kind of low-level nonsense Wine would get wrong.

I didn’t buy it. Not because I had a better theory, but because theories aren’t evidence, and nobody repeating this one had actually looked. If the terminal runs under Wine, and Python runs under Wine, there’s no physical reason two Windows processes in the same Wine prefix can’t talk to each other reliably. So instead of repeating forum wisdom, I decided to find out exactly what was happening on the wire.

Opening the black box

MetaTrader5’s Python package delegates everything to a compiled extension, _core.cp311-win_amd64.pyd. I used pefile to find its Import Address Table, then used ctypes to hook CreateFileW, WriteFile, and ReadFile in memory, redirecting the extension’s own Win32 calls through my own logging functions before they hit the real API.

(The one genuinely nasty bug here: undeclared ctypes functions on 64-bit Windows default to a 32-bit signed return type, so an address above 0x7FFFFFFF gets sign-extended into a garbage negative pointer and crashes VirtualProtect. Declaring argtypes/restype explicitly on every hooked function fixed it.)

With the hooks live, I ran mt5.initialize() again and watched the actual byte traffic for the first time:

[WriteFile #1] 28 bytes - UTF-16LE string "Python" (client handshake)
[ReadFile]     12 bytes - build number reply (terminal handshake ack)
[WriteFile #2] 8 bytes  - opcode 0x6d (status query)
[ReadFile]     12 bytes - 6d 00 00 00 01 00 00 00 01 00 00 00

Then, every 100ms for 30 seconds straight: the same 0x6d query, the same reply. Wine wasn’t dropping a single packet. This was an internal state machine, stuck.

So much for the starved pipe. So much for the choking message pump. The terminal wasn’t frozen. It was cheerfully replying “I’m still initializing” every single time, three hundred times in a row, while Python just sat there waiting for it to say something else.

Somewhere around hour thirty I also tried the obvious thing. Ctrl+C, more than once, and watched it do absolutely nothing. Not a kernel-level trap, nothing mysterious. _core.pyd was holding the thread in a plain Sleep(100) loop inside compiled C code, never once yielding back to Python long enough for a signal to land. Python wasn’t ignoring me. It genuinely couldn’t hear me.

The dragon on the wall

I disassembled the polling loop in _core.pyd with Capstone. The logic was simple: send opcode 0x6d, read a 12-byte reply, check byte 8 of that reply against a status code. 2 means ready, so return success. 3 means auth failed, so return an error. Otherwise, sleep 100ms and loop until a hardcoded timeout hits and it returns -10005.

The terminal was stuck reporting status 1, “still initializing.” And that’s the deadlock: on a fresh headless boot, the terminal doesn’t consider itself fully synced until a symbol has been subscribed, but subscribing a symbol is something your Python code normally does after initialize() succeeds. The client waits on the terminal. The terminal waits on the client. Nobody moves.

The silver bullet

Rather than patch the signed .pyd file on disk, I left the hook running permanently: whenever a 12-byte reply to opcode 0x6d came back reporting status 1, I rewrote that one byte to 2 before the extension’s own code ever saw it.

Because _core.pyd only gets loaded into memory the moment MetaTrader5 is imported, the whole patch happens before mt5.initialize() is ever called. Locate the module, flip its Import Address Table to writable, swap in the hook, restore the original permissions. Nothing touched on disk, nothing persisted. Just memory, for the life of the process.

def my_ReadFile(handle, buf, count, read, overlapped):
    res = real_ReadFile(handle, buf, count, read, overlapped)
    if handle in pipe_handles and res:
        r_val = read.contents.value if read else 0
        if r_val == 12:
            data = (ctypes.c_uint8 * 12).from_address(buf)
            if data[0] == 0x6d:
                data[8] = 0x02  # force STATUS_INITIALIZING -> STATUS_READY
    return res

mt5.initialize() went from a guaranteed 30-second timeout to returning in 0.02 seconds. No forum thread I found had gotten this far. Most had simply given up and switched platforms.

Here, my grimoire

The system now runs three broker connections concurrently, each in its own isolated Wine prefix, each supervised by systemd with memory/CPU limits and automatic recovery, streaming live tick data into partitioned Parquet files for later analysis. Fully headless, fully automated, no Windows license anywhere in the stack.

The patch, the diagnostic tool used to find it, and a working example of it wired into a real service are open on GitHub: https://github.com/blueTheEnigma/wine-mt5-ipc-patch

DEV Community: Morgan Ufuoma