It is faster than Mikrotik signed 3.x?
There are no any performance-related changes, so it can't be faster than the original. But it's undoubtedly faster than v4. The only guess is that your OS probably affects somehow.
I'm not planning to change interface currently, but regarding unsupported fields it's in progress. Without any ETA however.
The fault in strange. Does it happen at some specific moment, or immediately after the app launch? Please, attach ntdll file from your OS (C:\WINDOWS\SYSTEM32\ntdll.dll), I'll take a look, which function fails.
Probably it's CFG. I'm using indirect calls in some places.
It should be possible to apply such theme without affecting other apps installed on windows by creating windows portable app with some tool that intercepts windows registry api calls and uses separate/portable registry file instead system (like Enigma Virtual Box) and apply to that registry same dark theme that is used in Wine.
Of course it's possible. I will consider it in future, but I don't promise anything.
Hey @teslasystems
Can I make a suggestion?
Edit the first post and include links there to any subsequent versions of ESR as they are released.
You might want to include a link to the reply where the new version was released, along with the date and time.
Yes, of course. I wanted to do this a long time ago, but postponed each time.
Nice trick: r00t
BTW. Unleaded fuel pushed me to change a car ![]()
Sorry, I wasn't working on it last months. 7.25 is not yet released even in beta (and I can't get alpha, because it's password-protected now). In past, there was already a case, when alpha was incompatible with WinBox 3, but it was fixed in some beta, so let's see if they fix it first. If not, I'll see, what I can do.
I'm happy enough with WinBox4, and generally use a Mac... But I'm waiting to see how the robots go about 7.25... when it gets promoted to a channel, in some future WinBox3 "ESR"/etc . Can patching the assembler still work be my open question?
e.g. I doubt the changing one jump is the whole story, since that's likely some protocol version check or similar (or at least that be my guess). A more "classic" approach be some thunking layer (e.g. C lib bindings), or perhaps some "proxy" of winbox protocol to keep it compatible with "older" winbox protocol used by WinBox3. To me, it's been fascinating that the AI agent's approach here has been patching assembler. I can see why since it's localized to one file, verse needing some build environment ... but I'm curious how for patching assembly "scales". Since I'm pretty sure there enough #WinBox3ForLife folks with access to a decent model.
Not 100 % sure what do you mean, but I wasn't using AI at all for this ESR. I'm analyzing the app behavior manually and wrote a patcher, that modifies the original executable.
My bad @telsasystems. The according markdown release notes, and lack some public repo... combined to give me a certain "vibe". Comments still same... it does appear MikroTik is changing winbox protocol, so still curious what you come up with. Even if I'm not a "customer" ![]()
Any plans to fix "Shm Size" field in containers? Thanks!
Well, the main problem currently is that it's incompatible with 7.25. So, without fixing it first, other plans don't have much sense. For now, I solved 4 obstacles, that don't allow to launch the app, but stuck with fifth one. And who knows, how many of them to expect.
But in case I fix version problems, the answer to your question is yes.


