Since MikroTik has abandoned this great app and refuses to fix anything, while forcing to use their new half-baked product, will try to do some fixes and improvements on my own. Nothing radical, just some little polishing, because such work requires using disassembler, analyzing the code on a low level and patching it, it's not very easy and even a small change takes a lot of time. I'm not super-experienced with that, but decided to try some things.
So, below is the first custom version, that fixes a multiyear bug with grouping of thousands for numbers from 10^9 and larger. This occurs in 'Interfaces' and 'Firewall' windows for packet counters, and instead of 1 234 567 890 WinBox was showing 1234 567 890. The original conversion code was fully replaced by my own code, and it works correctly with all numbers up to the highest value limit (2^64 - 1).
Result:
Even though it's a very small change, it took almost 2 days to figure out and fix it. Probably, advanced hackers could do this for 2 hours or even quicker 
Also, modified version info:
Obviously, digital signature of the file is not valid anymore.
Download: winbox64_ESR_1.zip (761.3 KB)
Description for advanced users
The original function, that was converting numbers is located at address 0x46BEFC (offset in .exe file is 0x0006B323). It was implemented in a very weird way. First, they are comparing a number with 999. If it's not greater, they convert it as is using sprintf function. If a number is larger, then they compare it with 999 999. In case it's not greater they divide it by 1000 and pass 2 numbers (quotient and remainder) to sprintf function, that adds space between them using format string. In case a number is greater than 999 999, they also divide it by 1 000 000 and pass 3 numbers to sprintf function. But this third number (most significant part) is left as is and not grouped. So, they simply don't care about larger numbers and maximum 3 groups can be displayed. Won't comment this implementation...
My own conversion code works simpler and just divides the number by 10 to extract every digit. At the same time it counts, how many digits were processed and adds a space after each 3 converted digits.
The code is below (x64 assembler):
lea r13, [rsp+30h] // Load string buffer (address was taken from the original code)
add r13, 27 // Add offset, because conversion is done from end to start
mov byte ptr [r13], 0 // Null-character
mov r11, 4 // Digits counter for grouping (+1 for the first iteration)
mov rax, r9 // Number is located in R9
mov r9, 10 // Divider
@ConvCycle:
dec r11 // Decrease digits counter for grouping
jnz @SkipGroup
mov r11, 3 // If 3 symbols moved to buffer,
dec r13
mov byte ptr [r13], $20 // then add 'Space' character
@SkipGroup:
mov rdx, 0
div r9 // Divide by 10, RAX - quotient, RDX - remainder
add rdx, $30 // Convert to digit character
dec r13
mov byte ptr [r13], dl // Move character to buffer
test rax, rax // Check if a number is fully converted
ja @ConvCycle
cmp byte ptr [r8], 0 // R8 contains sign
je @End
dec r13
mov byte ptr [r13], '-'
@End:
jmp 0x46BFB1 // Continue to the original code
nop
nop
...
This assembly code was converted into machine code and placed instead of original code. It's smaller than original code, so all remaining bytes were filled with NOP instruction (0x90). You may check .exe by yourself in some HEX editor or disassembler.
If you have any ideas to fix some issues, feel free to share, but I can't guarantee to fix them.
in the todo list should anywyay - before or later - be done, and three years sounds like an appropriate time to go throu the first 2641 items.
