On the one hand side, many people here complain about the bad quality of .0 stable routerOS releases. So tested, working code seems to be a priority.
Then on the other hand side, you are asking for automatically, AI-generated tooling where the "engineering resources excuse doesn't hold water anymore".
How do you want to bring the two points together? I do not see how AI generated software with zero engineering resources put into testing will lead to stable, reliably working software releases.
Yep, that was my line. But you're confusing "using AI to assist engineers" with "letting AI blindly push untested code."
I see it this way: if devs start using AI as a force multiplier for the tedious grunt work, they magically gain the "engineering resources" needed to actually test things.
Because right now, human devs are pushing stable .0 builds while completely ignoring critical bugs that were clearly reported by the community in the RC/Beta threads.
Hell, at this point, I'd settle for them using an AI just to read the beta threads and act as QA to say, "Yo, this is bad, you didn't fix the bug they reported last week, don't release stable."
What does that matter? I'd imagine the UI team is working on CMR in WinBox4. I'm sure MikroTik use AI already as @normis said here before.
It takes humans to review/response/plan/etc, and humans to test/verify... so the "don't hold water anymore" is bullshit. It still the same resource allocation choices, as it always was. You can just release stuff quicker. MikroTik made a choice, which they could change at any point... but be ain't free to maintain both WB3 and WB4.
Is it?
I'd like the entire UI team to be working on improving WinBox4 and working on the controller features, bug fixed (like drag-and-drop, my "fixed units", someone else WB4 bugs, etc. Your asking them pull someone and their existing AI subscription from WinBox4 to work on WinBox3. Which only prolongs any of the horrible bugs WB4 has from being fixed. So the complaints about it, will continue even longer than just being fixed.
Something seems to have been lost in translation. Please.
I literally said "don't fix WB3". I am not asking MikroTik to pull devs off WB4 to perform necromancy on WB3.
I'm pointing out that the excuse of "they don't have the resources to add a few data types to WB3" is ridiculous in 2026.
If it's truly that difficult for them, then leave it broken.
But don't use that as a shield to deflect from the fact that the WB4 replacement they are pouring all those resources into is bloated and still missing the mark.
They may end up doing that, as I have said. But I can totally see not wanting maintain two codebases forever.
And, still that person was not doing nothing, so that work stops while they work on WB3. The same QA folk now have two different apps to test, so each be half tested. Unless they wanted to add engineers/QA to support the loud voices on an Internet forum.
So it's not a X days once, it on-going work: every release, every protocol change.
I'm looking at the WinBox 3 changelog from 2019 to late 2025, and I'm just not seeing this massive, ongoing protocol maintenance burden you're talking about.
2019.07 What’s new in v3.19:
*) fixed problem where Winbox could not login into RouterOS v6.45 (or later) router;
*) fixed DHCP lease sorting by “last seen” column;
2019.10 What’s new in v3.20:
*) allow to filter by IPv6 addresses and prefixes;
*) build 64-bit Winbox as well (https://mt.lv/FeuQe);
*) do not leave files locked on computer when uploading files to router;
*) fixed problem where some fields were not shown for read only users;
*) fixed Winbox crash when copying multiple files between routers;
*) make Ctrl+A work in script fields and other multiline fields;
*) make DLL hijacking attack not work: Winbox will not look at the directory it resides in, when looking for system DLLs;
*) on update, Winbox will check that code is signed by MikroTik and not somebody else;
*) removed Drag and Drop support on 64-bit Winbox in Wine;
*) show system note at login;
2020.02 What’s new in v3.21:
*) added support for HiDPI displays;
*) download WinBox specific files from router only into AppData folder and not anywhere else (CVE-2020-5720);
*) enabled Drag and Drop support on 64-bit WinBox in Wine;
*) font size can be increased/decreased under “Settings/Zoom In” or “Zoom Out”;
*) improved MikroTik signature checking on WinBox update;
2020.03 What’s new in v3.22:
*) added 24x24 and 32x32 icon support (RouterOS v6.47 required);
*) added Legacy Mode (disabled by default) to allow using older, less secure connections to RouterOS older than v6.43;
*) added scroll bar support in item property windows;
*) added support for super low DPI - 72, accessible by Zoom Out;
*) fixed Log window drawing on HiDPI displays;
*) fixed Zoom In/Zoom Out setting persistence after window is closed;
*) made table row height 15px by default;
*) use monospace font for big pop-up messages;
2020.04 What’s new in v3.23:
*) added support for Ctrl+C and Ctrl+A shortcuts in read-only fields;
*) always use fixed width font in terminal window;
*) do not resize inner windows when main window is resized;
*) fixed default configuration approval window disappearing when using “Show Script” button;
*) fixed main window size saving between sessions;
*) improved large table loading speed in RouterOS v7;
2020.05 What’s new in v3.24:
*) fixed WinBox crash when viewing firewall rule with src/dst-address-type configured;
*) fixed checkbox group disabled state inheritance;
*) fixed dates and times in interface link up/down properties (RouterOS v6.47 required);
*) fixed system comment message display;
*) fixed vertical font alignment in optional fields;
*) fixed window size inheritance from the previous session;
*) keep advanced and simple mode table settings separately;
*) make WinBox upgrade work with wine 5.0 or newer;
*) properly show popup windows on top;
2020.08 What’s new in v3.25:
*) added “Find Next - F3” tooltip for Find field;
*) added support for CTRL+ and CTRL- keyboard shortcuts for Zoom in and Zoom out;
*) added support for DNS names in address type fields;
*) do not scroll to first log entry when minimizing WinBox if Log window was open;
*) fixed crash when an active Terminal window was opened when WinBox was minimized;
*) fixed crash when opening session with Health window open;
*) fixed multiple “peer” parameter presence when editing an IPsec policy;
*) fixed secure connection establishment after trying to connect to legacy mode devices;
*) fixed session file size increase with each WinBox usage;
*) improved window resizing and scaling behavior on systems that include high DPI monitors;
*) show disabled item icons in gray;
2020.09 What’s new in v3.26:
*) fixed CAPsMAN service failure when viewing Radios table;
*) fixed Hotspot service failure when viewing Hosts table;
*) support Ctrl++ & Ctrl± on keypad for quick access to Zoom In/Zoom Out;
2020.09 What’s new in v3.27:
*) fixed content drawing of read-only tables (introduced in v3.26);
2021.06 What’s new in v3.28:
*) added support for “contains” and “contains not” filtering in IPv4 address ranges;
*) allow to modify DHCPv6 server binding settings;
*) do not show newly created elements as invalid (in red);
*) expand table flag column to show all possible flags;
*) fixed IPv6 prefix column sorting in tables;
*) fixed WinBox crash after saving current session;
*) fixed WinBox crash when accessing v7 routes with VRF set;
*) fixed WinBox crash when some opened element was removed;
*) fixed WinBox disconnect when large text was pasted into terminal window;
*) fixed problem where optional field disappeared if window was maximized;
*) fixed table row selection with keyboard to match Windows behavior;
*) keep inner maximized window maximized when changing WinBox window size;
*) show missing Security Profile field in WiFi simple mode;
2021.08 What’s new in v3.29:
*) added “Windows” menu for list of all currently opened windows;
*) added separate “Show Columns” window for list of visible columns;
*) allow changing column order by using drag and drop;
*) made “Terminal” window titles unique;
2021.09 What’s new in v3.30:
*) added support for mouse wheel scroll in field & table show columns windows;
*) double click on word in “Terminal” now automatically selects and copies it to clipboard;
*) fixed WinBox disconnect when selecting entries in QuickSet’s “WiFi Clients” table;
*) fixed crash when all inner windows were closed;
*) fixed crash when opening some of interfaces;
*) fixed glitches while resizing column widths or reordering table entries;
*) fixed visual glitch when showing table filters and categories;
*) fixed visual glitches when scrolling “Terminal” window and Zoom In or Zoom Out is used;
*) made Ctrl++ & Ctrl± still work if focus is on checkbox;
*) made Ctrl+C and Enter right after text selection in “Terminal” window work as copy to clipboard;
*) made Ctrl+D pass-through to “Terminal”, so it is possible to terminate inner telnet or SSH sessions;
*) made Ctrl+V work as paste from clipboard;
*) made double click in “Torch” window work again;
*) properly show “I” flag for invalid entries;
*) use router’s time when filling default time in “Scheduler” items;
2021.09 What’s new in v3.31:
*) ask to close all WinBox instances before WinBox upgrade, otherwise upgrade will fail;
*) fixed table to properly show and hide columns and remember its widths;
*) made MAC-telnet work if SSH or telnet was used before;
*) update file path after changing its location with drag&drop;
2021.12 What’s new in v3.32:
*) added “Auto Reconnect” feature;
*) added fast selection of column checkboxes in “Columns” window by simply typing column name without spaces;
*) added support for “Tools->Telnet/SSH” extra parameters;
*) alert if there was error executing “Cancel” action;
*) fixed MAC connection in new window;
*) fixed WinBox when started by Windows “runas” tool with different user;
*) fixed crash on “Netwatch” entry “host” field;
*) fixed crash when table window was closed before its “Columns” window;
*) fixed delayed session window open with “Change Password Now” prompt;
*) fixed filter type “contains” for network fields;
*) fixed focus marker in checkboxes;
*) fixed graphs with values higher than 2^31;
*) fixed large text paste in “Terminal” window;
*) fixed some fields with empty IPv6 value;
*) fixed tables with max entry count feature;
*) fixed time value fields in “Scheduler” menu;
*) keep terminal lines intact when resizing “Terminal” window;
*) properly show all fields which depend on other field;
*) release “Safe Mode” with info message, when other user took it;
*) restore “Managed” table when toggling “Advanced” mode;
*) sort “Columns” window alphabetically;
*) use router’s time in graphs;
*) use router’s time in last link up/down fields;
2022.02 What’s new in v3.33:
*) added support for hex type fields;
*) enabled “Stop” button on auto start actions;
*) fixed error messages for start, stop and cancel actions;
*) fixed skin when opening in new window;
*) fixed time zone offset support for some fields;
*) improved interface name sorting;
*) properly display all packets captured by sniffer;
2022.02 What’s new in v3.34:
*) fixed WinBox crash on startup (introduced in v3.33);
2022.02 What’s new in v3.35:
*) fixed F4 and F7 keys in Terminal;
*) fixed automatic reconnect issues for RoMON;
*) fixed crash when connecting in new window (introduced in v3.33);
*) show correct data rate for file upload/download;
2022.06 What’s new in v3.36:
*) do not set hidden field values as empty when adding new item;
*) fixed Graphing and Quickset graphs;
*) fixed default value for disabled wireless EAP methods field;
*) fixed issue with showing non-existing values;
*) fixed managed list category grouping when value is IP with port;
*) fixed missing icon for submenus that are hidden by skin;
*) fixed neighbour table filter “all” storage;
*) fixed saving and restoring of filter comboboxes;
*) fixed skin behavior for “Add” buttons with dropdown;
*) fixed value updating when it is changed and disabled;
*) fixed values with required “&” prefix;
*) fixed wifiwave2 frequency field;
*) show error when not enough space to complete file upload;
2022.07 What’s new in v3.37:
*) do not update interface window layout all the time;
*) do not send value for empty multi-option field;
) fixed VPLS “cisco-id” field with “&” prefix (introduced v3.36);
) fixed ability to set options that can be hidden;
) fixed floating point field’s negative value in -0. format;
2023.05 What’s new in v3.38:
*) fixed connecting to wireless network from QuickSet when there was no password specified;
*) fixed date and time value representation in the User Manager;
*) fixed skin file reading;
2023.07 What’s new in v3.39:
Important note!!!
Upgrade from older WinBox versions might not work due to the new digital signature. Manual WinBox upgrade is required.
*) added support for QR code field;
2023.10 What’s new in v3.40:
Important note!!!
Upgrade from older WinBox versions will not work. Manual WinBox upgrade is required.
*) fit BTH QR code into default settings window;
*) fixed WinBox upgrade procedure (introduced in v3.39);
2024.07 What’s new in v3.41:
*) added support for new internal WinBox protocol fields;
2025.05 What’s new in v3.42:
*) added support for the Files menu in future RouterOS versions;
*) added some widget features for future RouterOS versions;
*) fixed crash when dragging the “#” column by disabling its movement;
*) fixed date fields to support year up to 2106;
*) terminal: ignore legacy shift-out (SO) character;
2025.10 What's new in v3.43:
*) update support for new field types (used by future RouterOS versions);
*) fix possible crash when restoring session config;
It's not me have to convince. And they also are have not added UI features on WinBox3 for almost a decade. The CMR I'd imagine is going to add more UI element that don't exist on WinBox3, and since I see all these reports of bugs in WB4... point still true those get delayed.
. They actual meant 2026.
why not 2116 ?
Integer Time "starts" in 1970, and the seconds rollover back to 0 in 2038. The next time that happens be 2106.
Which is "ancient" way of handling it. So called "epoch" was somehow "variable" on DEC alpha machines due to the two distinct BIOS types (SRM vs. ARC) having different "beginning of time". So handling different reference time for the time counter is in linux kernel and C library for at least 30 years. Handling 32-bit counter overflow in 2038 is just another example of handling different "beginning of time", although dynamically (because the "beginning of time" can change during kernel running as opposed to taking the right constant value during boot).
The more modern way of handling it is to use 64-bit time counters and in some of modern linux distributions there are system libraries with "t64" in their name ... which indicates use of 64-bit time counters. And using 64-bit time counters moves the problem of counter overflowing well into the future (a few million years, give or take a few seconds).
I'm sure it's not just a few million, but a lot of Billions!
...but it doesn't matter anymore...
As they have the sources for both versions, they can likely ask AI "please add the same datatype and logon protocol support we just added to WinBox 4.5 also to the latest WinBox 3 version" and it will do a flawless job. It of course still requires work of an employee, but not coding work.
As outsiders we can do the same thing with just the binaries (as has been shown) but it is less reliable.
Exactly this. Better than any prompt when AI has a implementation reference. "Here are the relecant changes for wb4, please backport to wb3". Very simplified. If random strangers are able to patch WB3 binary, it has to be a breeze to do when you have the source code.
I don't want to insult someone but programmers who write such quality code probably really don't have the capacity to maintain a legacy code base.
WinBox3 being "retired" is a product management decision... no point on arguing what/if AI could do or how hard it is, or the potential prompts. MikroTik decides if the company wants to commit to maintaining compatibility, since it not just "an employee" getting code that works... its support, docs, and importantly testing too that are effected. At this point, that decision is WB3 ends. It's not that hard/easy... it's a business decision.
Well, the patched WB3s have some attributes that don't work. If MikroTik released a WinBox that wasn't perfect... there be support cases, complaints on forum... So it's not a free lunch, AI or not.
My bet is they have more substantial changes plan in how WinBox gets data from RouterOS, that might be more radically different. For example,
- WinBox protocol uses EC-SRP encryption, and requires a user/password as only auth mechanism. It uses SHA1 internally, so its NOT particular hardened for the dark ages of security we're going be seeing.
- Adding newer auth schemes like more-direct 2FA support, Passkey (really just mTLS certs wrapped in protocol), fine-grain access tokens, or any other auth scheme... that be new UI in two places.
- IDK the exact internals on the UI parts of winbox, yet. But high-level RouterOS provide much of the UI structures.... so if routeros could know all clients were at min WinBox version and always be Qt-based, it could be further streamlined to be more efficient to provide Qt the QML metadata it needs...
- Related, some of the data needed for WinBox3, may use space, that could be saved or optimized. Potentially slightly reducing NPK size.
So yes if they added new things, they could be implemented on WinBox3. But no escaping it double work on an on-going basis. And make fixing the bigger thing harder or slower.
That makes zero sense architecturally. RouterOS is a backend; it doesn't care what UI framework the client uses.
Under the hood, the WinBox protocol is just a custom binary TLV (Type-Length-Value) structure. The router sends raw data and a generic schema (integers, strings, booleans, lists). It is 100% on the client to parse that and draw the UI. WB3 translates those TLVs to Win32, WB4 to Qt, WebFig to HTML, and the mobile apps to native elements.
The router sends data, not rendering instructions. If RouterOS started bloating the binary stream with Qt-specific QML metadata, it would instantly break WebFig and the mobile apps.
Forcing a small router to generate frontend rendering code is the exact opposite of "efficient".
At the risk of only exemplifying the meme I complained about, and perhaps over-reacted to 
...
Mostly right. But it's far more complex than that, since there a few layers around them.
I had agents look at this in past since I built btest and --via mac-telnet in my tikoci/centrs project I'm working on. Most of what I know about winbox-ipc ("WinBox protocol", or M2 which what I call the various MikroTik TLV schemes) is in GitHub tikoci/m2ir that captures existing research on WinBox protocol I've collected for past year for my various tools: m2ir/profiles/winbox-ipc at main · tikoci/m2ir · GitHub
Based on this whole WB3 fiasco, I started some AI agents doing another pass on my "WinBox protocol scheme"...using more tools, like REA/Ghagi and my tikoci/quickchr (which recently added --freeze option to allow a gdb on CHR for agents).
I have some credits to use before they expire, so likely have a better story on the new protocol changes soon. I have zero interest in patching WB3, but anyone doing that should at least ask there agent too look the tikoci/m2ir as it's structured evidence for everything that's known about WinBox protocol. It will be updated this weekend with more recent details.
I never said render anything, "align" the API with client is what I meant. So think stuff like delta updating, so only changed attributes are sent over the wire. Or, UDP-based scheme to stream.
Or any number more major changes including perhaps newer routers don't even support the winbox protocol altogether. The WinBox4 client keep existing support, but gain a new protocol for new routers versions, which would may not support "legacy winbox protocol". If the plan was to eventually deprecate the TLV-schemes... deprecating WB3 makes more sense.
e.g. some WB4 complaints are not strictly tied to renders. e.g. things like how large lists and slow updates likely are tied to how the TLVs provided. While Qt rendering may be marginally slower than native Windows GDI in WB3. A more efficient wire-protocol likely overcome whatever marginal difference in native Windows GDI, and Qt's rendering layer.
I'm suggesting that be bigger changes may be afoot.