Long ago, I wrote a script for doing "hex editor" style displays of &binvar variable contents to custom windows:



It was possible to do this with very little compromise: only null and mIRC control code characters had to be replaced before performing the screen writes. Which was easy:

Code:
breplace &smdebvarline 0 255 2 255 3 255 9 255 15 255 22 255 27 255 29 255 31 255 32 255

As UTF became more prominent in mIRC, however, I began noticing instances where unwanted UTF decoding would occur because of the random nature of the bytes I was writing. My temporary solution to that problem was to simply do this...

Code:
/window -CDk0nz -t1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,18 @Debugger Terminal 12

...coupled with inserting a $chr(9) between each byte in the &binvar I was going to write, before writing it. The result: the UTF decoding was foiled (and ergo the screen capture above, which is from mIRC 6.35 with breplace + tabbing to foil UTF).

But then came mIRC 7.x. Now even tabs don't stop UTF decoding.

Tabs + invalid characters breplace'd with ASCII 255:


Tabs + invalid characters breplace'd with ASCII 46 (just for comparison):


mIRC appears to be "seeing right through" my tabs and attempting to decode UTF anyway.

Is there any way to prevent this, so I can have my "hex dumps" back? Or has UTF finally won and made pure 8 bit screen writes impossible?